Adam Hardy wrote:
Is it right to assume that no-one is interested by the idea of
extending the S2 Result to allow extra configuration or classes at
this location in the architecture?
Hi Adam, I haven't been convinced yet that there's a strong argument for
this compared to alternative approaches yet. Or rather that the effort
doesn't seem justified for the amount I'd use it. However one related
use-case I've yet to find a good approach for is when using the REST
plugin and a ContentTypeHandler to determine which result handler is
executed:
For the same result:
- when the requested content type is HTML, a view is returned that
often does need access to additional data (eg. options for a select)
- when the requested content type is XML or JSON, the result does not
need that additional data to be prepared
In this case it makes sense that only the HTML result itself, or the
view components themselves, should perform the additional logic to
prepare the HTML view. The action itself definitely should not be doing
it (but does).
Your proposal may be the best way to solve that but may need some more
thought within that context.
I had quickly coded a Result to do some 'view logic' (i.e. retrieve a
list from the model) and I had assumed I would be able to parameterize
this using extra parameters in <result> but it seems my extra
parameters are ignored - the only one that counts is <result><param
name="location">
Is that correct?
AFAIK, you can define any new parameters for your Result and set them
through struts.xml <param> provided there's a public property for it.
I've definitely used it for custom results extending
StrutsResultSupport. I have a getter and setter in every case.
Adam Hardy on 02/01/08 23:55, wrote:
That was the standard struts 1 approach, IIRC. My grudge with the
other solutions I think also applies to this: it's not a natural
solution, it's another square peg in a round hole.
This is why I'd like to see something in Struts2 that addresses this
fundamental duality of purpose in the HTTP request.
Adam
Brian Pontarelli on 02/01/08 22:50, wrote:
However, this still requires some composition or inheritance to
support multiple actions using the same preparation right?
-bp
Musachy Barroso wrote:
What I do is that I create an "input" map to the input method on
the same
action class for which validation is failing. That method is empty
(from
ActionSupport), and forwards to the page that will show the data.
On this
page I use the normal tags backed by the action. If multiple tags
call the
same method then I "cache" the results on the action. I think your
problem
can easily be solved by making "input" go thru an action, instead of
forwarding to the page straight. (but you already knew this :) )
<redundant-email />
regards musachy
On Dec 31, 2007 11:41 AM, Adam Hardy
<[EMAIL PROTECTED]>
wrote:
Happy New Year everybody.
This issue is mostly due to the validation failure mechanism which
passes
flow direct to the 'input' result without giving a chance to code the
data retrieval needed to get data for dropdowns, associated lists,
etc
etc which the view/JSP will need.
Currently the assorted solutions to this all seem to be forcing
round pegs into square holes. For instance, I could make the
'input' result an
action chain to go onto another action which does the data
reading. Or I
could fetch the data via an <s:action> or a taglib.
The S2 documentation says in various places things like:
"First, we need to change or query the application's state, and
then we
need to present an updated view of the application. The Action class
manages the application's state, and the Result Type manages the
view."
Three or four years ago, this issue with the view was discussed
alot. There was talk of mechanisms termed 'view-controllers' and
concepts such
as 'view logic'.
I'd love to see this accommodated for in S2.
There is a certain amount of coding I can do to achieve my goals
in the
Results, but it may not be the best place for it - the name 'Result'
implies more of a link between the Action and the View, rather than a
place for coding data retrieval.
Essentially I think there is a strong call for a Class or chain of
classes that can be tied to each particular View, whether Tile, JSP,
velocity or whatever.
This is obviously not what Results were designed for. I can do it
currently but the S2 config allows only one class per ResultType - so
effectively I'd need one ResultType per JSP, or some pattern for it.
The sort of operations I'm thinking of:
- retrieving lists, sometimes parameterized (e.g. a list of items
allowed
in a particular category - requires the categoryId)
- caching lists (countries in ApplicationScope, personalized data
in session for example)
- localization of dropdown beans (i.e. country names)
---------------------------------------------------------------------
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]
