I think it is an issue where you think you need to pass a string to
disabled, presumably because you expect to see a <.....
disabled="true"/> out in the HTML.
Well it turns out that the disabled switch expects a boolean switch
rather than pass through text. So that helps a little:
<s:set name="protect" value="%{true}"/>
But in Struts2/WebWork the tags will try to evaluate things by default
so you can drop the curly braces and just write:
<s:set name="protect" value="true"/>
The same syntax sugar is true for your textfield so:
<s:textfield .... disabled="%{protect}"/>
is the same as
<s:textfield .... disabled="protect"/>
The use of the # symbol can get confusing, and its most commonly used
to change the "root" of the context. By default you are on the value
stack where all the actions "getters" are available. If you want to
change that context to page or session, then you need to use the
preceding #session, #page etc. There are other cases when you are
inside if an iterator where the context shifts down to the current
object in the iteration. You want to get out of the loop back to the
main context so you see things like #top.xxx inside the loop.
I wish I knew the hard fast rules for the OGNL syntax magic. My
suggestion is if its just variable names and scalar values then the %
{} is not needed. If you want to assemble a hash in OGNL for a select
or something heavier like that then you will need the %{ }.
-Dusty
On Apr 5, 2008, at 2:54 PM, Richard M wrote:
I've read and re-read the Struts2 guides on OGNL and the Struts2
tags (and
the OGNL web site guide to comparisons).
Problem: I wanted to protect fields on a form if the user was not the
"owner" of the domain object.
My approach was going to be to test that the form was either:
a) empty, so a new instance was being created so fields should not be
protected.
b) the remoteUser was the same as the "owner" of the existing
object, again
no protection needed.
c) Otherwise I wanted to "disable" all of the form fields and just
allow the
data to be viewed.
I looked at the example of the Appfuse userForm.jsp and found an
example
"s:if" statement that appeared like it should be a basis for this to
work.
It was:
<s:if test="ticket.id == null | ticket.owner.username ==
#request['remoteUser']">
<s:set name="protect" value="%{'false'}"/>
</s:if>
<s:else>
<s:set name="protect" value="%{'true'}"/>
</s:else>
...
<s:textfield id="..." disabled="protect"/>
Well this did not work as expected. I tried numerous combinations,
including
disabled="#protect". I never could get it to work right. I've ended up
reverting back to regular JSTL c:if tags, but using these in
combination
with s:if tags appears to not work consistently.
Any ideas on how to do this would be greatly appreciated. I've been
working
with an appfuse/struts-resume app for over five years. For a new app
we are
doing, we decided it was time to move to Maven, Appfuse 2.0, Struts2,
Spring. The code is so much cleaner, but the learning curve on a
couple of
things has really bit me hard!
--
View this message in context:
http://www.nabble.com/Struts2-%22s%3Aif%22-tag-comparisons-and-OGNL-tp16518434s2369p16518434.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
