Exactly. getters/setters are fluff for this, and I prefer the semantics
of static finals as opposed to storing the possible values in the
message catalog.
In reality it seems like the radio type components could have a bit more
cohesion - let me elaborate. If you are using radio buttons, then you
are absolutely restricting the user to 1 of N available choices. If you
have multiple instances of absolutely bounded choices, then you have
multiple radio groups. The point to take home is radio groups are only
ever used to allow the selection of 1 choice from a known and finite set
of choices.
This aspect is not encapsulated by the radio component. It seems like
this could be implemented with a (sorted) map, and then you could supply
this map object to the radio container. This would alleviate the need to
explicitly set the value on each radio component in the container, and
would also open the door for extra validation (like the selection that
comes it is actually a valid key in the map).
This probably wouldn't be too hard to implement. I'm not at all bashing
the components, I'm just pointing out what seems like a useful and
natural improvement.
Daniel Jue wrote:
I think he wants to bypass the need for a getter and try to directly
retrieve something like a static final, which should have the public
visibility needed. I just assumed prop: would work since you specify
the exact name, instead of having "get" appended.
I guess ognl's special syntax for getting statics was that you specify
the full path to the class that holds the static?
On 8/16/07, Josh Canfield <[EMAIL PROTECTED]> wrote:
I can't test this right now, but my first guess would be that you haven't
implemented a getter method for the value.
do you have a "public String getAGENT_LISTER()" method?
On 8/16/07, Chris Lewis <[EMAIL PROTECTED]> wrote:
But alas, you cannot. If I remember correctly, you're not allowed to use
expansions in parameters (${}). This isn't needed for value as its
expanded anyway, but the bottom line is T5 throws an exception if you do
something like this:
<t:radio value="prop:STATIC_FIELD"/>
or
<t:radio value="${prop:STATIC_FIELD}"/>
or
<t:radio value="STATIC_FIELD"/>
Even if the page class has this field. It throws an exception with the
message:
"Could not convert 'prop:AGENT_LISTER' into a component parameter
binding: Class xxx.Login does not contain a property named
'AGENT_LISTER' (within property expression 'AGENT_LISTER')."
Daniel Jue wrote:
T5 uses Prop, so you should be able to specify it using
${prop:STATIC_MEMBER}
On 8/16/07, Chris Lewis <[EMAIL PROTECTED]> wrote:
Hello,
I'm implementing a form with some radio buttons. My understanding so
far
is that the radio buttons provide a value, and that value is stored in
the containing RadioGroup's value parameter when the form is submitted.
The form has only 2 radio buttons, each representing a string value.
This string value should be a constant in the page class, but I can't
figure out how to grab a constant from the page class in the template.
In T4 this was done with something like:
value="ognl:@com.app.MyPage.STATIC_MEMBER"
How can this be done in T5?
thanks!
chris
---------------------------------------------------------------------
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]
--
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
