Adam Hardy wrote:
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.
You can certainly do it that way, I just don't think that Result is a
place for business /model logic. Results are used for the resolution of
the view, which is a bridge between the controller and the view.
The model logically belongs elsewhere with MVC 2. In either case, you
have controller/view code calling out to model code. The logic for the
model should be located either in actions or hopefully a services layer
with a little bit of action code for glue. In my case, I'm placing a
call to the business logic it in the JSP (view code). In your case it is
in the Result (controller/view code). In either case, the logic should
be elsewhere and just called from the View or Result.
Therefore, I don't think it is a violation because it is still the
business logic is in a separate location without any logic directly in
the JSPs. The logic resides in the model/service layer and the coupling
is very loose. Rails does it this way as do a number of other
frameworks. I also use this method for form preparation instead of using
the Preparable interface or other methods. This seems more accurate
because the form is only prepared when it is displayed.
Lastly, unless the Results are modified for chaining or the like, you'll
have a hard time having multiple usages like this in a single result. My
solution allows me to invoke any action from the view and have the logic
executed in a different layer and the results available in the JSP. This
is very reusable in my opinion and much simpler to code with less
configuration. Plus, I could wrap that all in a .tag file and make it
even simpler to reuse. The other solutions seem to require a decent
amount of more work.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
