Brian Pontarelli on 28/12/07 16:09, wrote:
My requirements specify a mechanism that allows for:
- caching of lists (countries again in ApplicationScope for example)
- parameterization (e.g. a list of codes allowed in a particular
category - requires the categoryId)
- localization of dropdown beans (i.e. country names)
I handle the country and other types of lists and drop downs using the
action tag and it works nicely. In fact, I've been using the action tag
a lot more lately rather than using custom tags or any other type of
classes because the mechanism is already there and works nicely.
My usage is like this:
<s:action id="jc" namespace="/jcatapult" name="countries">
<s:param name="preferredCodes" value="{'US'}"/>
<s:param name="includeBlank" value="true"/>
</s:action>
<s:select list="%{#jc.countries}"
key="user.contactInfo.addresses[\"work\"].country" required="true"/>
it would be violating the spirit of my architecture if I did that, I think.
Doing model II architecture, the idea is to keep the JSPs clear where possible
of non-presentation tags, and, trying not to over-exaggerate, calling the
actions from the JSPs is one stage removed from those SQL taglibs, which are
/verboten/ where I come from.
In an ideal world I would be happiest to retrieve dropdown lists in my Actions,
but there is a clear separation between the Actions and the JSPs, whose dropdown
list requirements don't map one-to-one to the Actions.
So I turned to Results to achieve my goal, and it's OK as it is, inheriting from
TilesResult, but it's cludgey.
Regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
