I'm currently working with Struts2 (inexperienced developer) and I've been searching but I couldn't find how to apply an OGNL expression to a variable stored in context.
The thing is that I need to retrieve a parameter from Context and uppercase it. By now, I've tried to do it this way but sadly with no luck:
<s:property value="#myVar.toUpperCase()" />
As this works with variables stored in the ValueStack (notation without #), I don't really understand why this won't work with anything stored in Context..
I'm able to print the #myVarcontent just fine if I don't append the .toUpperCase() to it.
Also tried this workaround but didn't help:
<s:property value="<s:property value="#myVar"/>.toUpperCase()"/>
So what's the thing I'm missing? How can I apply an OGNL expression to a variable stored in Context?
Your variable most probably isn't a String so there isn't toUpperCase() method in it. The solution is to call toString() before calling toUpperCase().
<s:property value="#myVar.toString().toUpperCase()" />
Update
Actually your problem is here <s:set var="myVar" value="%{#parameters.myVar}"/> since there could be more then one myVar in parameters it will return an array of Strings, so if you want just a single parameter change your expression to #parameters.myVar[0] and then toUpperCase() will work.
<s:set var="myVar" value="%{#parameters.myVar[0]}"/>
<s:property value="#myVar.toUpperCase()" />
OR
<s:set var="myVars" value="%{#parameters.myVar}"/>
<s:property value="#myVars[0].toUpperCase()" />
Related
Why this "value" can not be written as "pricevalue" or other, otherwise input will not convert non-numeric values
In the props element, you are defining the properties your component will attach to. You can call them whatever you want. You need to be clear about a couple of things...
You define the name here in camelCase, but when you call the component in the parent markup, use kebab-case.
methods only run when they are called. If you put your formatting on the downstream side (receiving a value and displaying it), everything will be reactive and all your values should display correctly. It will all just work whenever the source value changes. So do your formatting in a computed, like this...
js
computed: {
formattedPriceValue(){
return Number.parseFloat(this.priceValue).toFixed(2)
}
}
You can also just do it inline...
markup
<input type="number" :value="Number.parseFloat(priceValue).toFixed(2)">
The value you want to emit is probably the unformatted output of Number.parseFloat #change="$emit('price-changed', Number.parseFloat(event.target.value))"
Then, you will live longer if you do your number formatting with the Number functions provided.
Also, why don't you use the new template (multi-line) strings, delimited by a backtick `. They're much cleaner than the line continuation character you're using.
ps. I love seeing the chinese (?) comments in the code. I've copied and pasted them into my code. I hope there's no swearing. Unicode rocks.
In NLog, is there a way to have a variable with a conditional value? I've seen this: https://github.com/NLog/NLog/wiki/When-Layout-Renderer and tried the following:
<variable name="EnvironmentString" value="${when:when='${IsProd}' == 'true':Prod:else:Stage}"/>
but the value is just returned as a literal; the logic is not being processed.
Thanks,
1) Change the syntax to this:
${when:when='${var:IsProd}'=='true':inner=Prod:else=Stage}
Note:
:else= rather than :else:
:inner=
var:IsProd (assuming IsProd is another variable)
2) Move the whole conditional to the final Layout
<target ... layout="other stuff|${when:when='${var:IsProd}'=='true':inner=Prod:else=Stage}|other stuff" ... />
I've not managed to get conditionals working in variables. Perhaps someone else could say why.
This should work.
But it depends how the variable is used.
If you use:
${EnvironmentString}
Then it's evaluated when loading the configuration, and so you could use it for all parameters.
To evaluate it dynamically, use
${var:EnvironmentString}
But please note that ${var} only works if the parameter of the Target/Layout is of type Layout
In our code base we have a mixture of the following:
attribute="${something}", attribute="${something | converter}", etc.
attribute.bind="something", attribute.bind="something | converter"
I find the latter easier to read.
The examples I'm referring to are exactly like the above; i.e., they do not add any additional string content.
I think that it's easier on Aurelia too. Am I correct?
Also, for these specific cases where no actual interpolation is
involved, is there any benefit to the first form? (other than it is
two characters less to type.)
Given the examples you have shown, I would recommend using option 2. It really isn't "easier on Aurelia," but it is more explicit that you are binding the value of that attribute to the property listed.
Original Answer Below
The benefit of the first option is when you have, for example, an attribute that accepts many values but as a single string. The most common example of this is the class attribute. The class attribute accepts multiple classes in a space-separated list:
<div class="foo bar baz"></div>
Imagine we only want to add or remove the class baz from this list based on a prop on our VM someProp while leaving the other classes. To do this using the .bind syntax, we would have to create a property on our VM that has the full list but adds or removes baz as determined by the value of someProp. But using the string interpolated binding, this becomes much simpler:
<div class="foo bar ${someProp ? 'baz' : ''}"></div>
You can imagine how this could be extended with multiple classes being added or removed. You could maybe create a value converter to do this using the .bind syntax, but it might end up with something that wasn't as readable.
I could imagine a value converter being created that might look something like this in use:
<div class.bind="someProp | toggleClass:'baz':'foo':bar'"></div>
I really think this is much less readable than using the string interpolation syntax.
By the way, the value converter I imagined above would look like this:
export class ToggleClassValueConverter {
toView(value, toggledClass, ...otherProps) {
return `${otherProps.join(' ')} ${value ? toggledClass : ''}`;
}
}
The best part is that I'm still using string interpolation in the value converter :-)
After wading through the tabs I'd already opened I found this. Although it's not quite the same thing, and it's a bit old, there's a similar thing talked about on https://github.com/aurelia/templating-binding/issues/24#issuecomment-168112829 by Mr Danyow (emphasis mine)
yep, the symbol for binding behaviors is & (as opposed to | for value converters).
<input type="text" data-original="${name & oneTime}" value.bind="name" />
Here's the standard way to write a one-time binding. This will be a bit more light-weight in terms of parsing and binding:
<input type="text" data-original.one-time="name" value.bind="name" />
I don't know if it applies to the .bind/${name} case as well as the oneTime one in the example, but perhaps if it comes to his attention he can say either way.
Given this isn't a cut and dry answer, I'll be marking Ashley's as the answer as it confirms the legibility question and provides useful information on other use cases should anyone else search on similar terms.
Dojo's dijit html5 tags use an attribte name data-dojo-props. The value is basically a JSON string without quotes around the property names and without the outermost braces.
It looks something like this.
data-dojo-props="prop1:'xyz', prop2:true, prop3: { subprop1: 1, subprop2: 'abc'}"
I'm using C# to write this out from a C# object using JSON.NET and passing in the object pointer. I found settings to leave out the property name quotes, but I can't figure out a graceful way to remove the outside braces.
For now, I'll run the string through a regex to remove them, but was wondering if someone new a better way.
I serialize each top level property separately and make it a global javascript variable. I then reference that variable in data-dojo-props. I admit it's not that elegant.
My concern with your approach above, is if the value of subprop2 contains a quote, you will get a parser error.
<script type="text/javascript">
menuData = {THE SERIALIZED JSON GOES HERE};
</script>
<div data-dojo-type="SomeWidget" data-dojo-props="menuData: menuData"></div>
I would like to learn how to escape dot in GString so groovy (1.8) does not treat it as a part of an variable inside sql.execute. I have the following code:
Map<String, String> dbSettings = [schemaName:"testSchema"];
String myDbPrefix = dbSetting.schemaName + ".";
sql.execute "DELETE FROM ${myDbPrefix}myTable"
And I got this error:
Ignoring groovy.lang.MissingPropertyException: No such property: myTable for class: java.lang.String
Clearly indicating that . was interpreted as part of variable ${myDbPrefix}.
Does escaping the embedded variable help?
sql.execute "DELETE FROM ${Sql.expand myDbPrefix}myTable"
I got hit by this problem today. GStrings get handled by a special way in GroovySQL. It's mentioned in the javadoc. It does automatic parameter binding.
Each value in the GString will become a parameter (?) which gets set as a JDBC prepared statement parameter.
What a surprise!
I'm going to fix the problem in my application by subclassing the Sql class and overriding the GString handling with plain ".toString()" .
Documented in Groovy wiki:
GString Use Cases - GSQL Another use case for GString is GSQL where
parameters can be passed into SQL statements using this same mechanism
which makes for a neat way to integrate Groovy with other languages
like SQL. GroovySql then converts the expressions to ? and uses a JDBC
PreparedStatement and passes the values in, preserving their types.
If you explicitly want to coerce the GString to a String you can use
the toString() method. Groovy can also automatically coerce GStrings
into Strings for you.