struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: invent way to get dropdown data in JSP not using actions or taglibs?
Date Thu, 10 Jan 2008 11:52:21 GMT
I haven't got a solution to demonstrate what I want to do yet, because I'm still 
looking at the current Result mechanism to see how it functions. However you're 
right that it might not be worth the effort - I'm sure I'm not aware of all the 
dependencies that tie into the mechanism. Implications for REST handling and for 
OGNL and theme handling come to mind.

Here's a catalogue of current solutions to the absence of a 'view logic' layer:

* create a 'straight-through' Action mapping using just ActionSupport, and chain 
the input result to it

* fetch data from model in your action and store it in the session

* use taglibs to retrieve data for the dropdowns or lists they render

* use <s:action> taglibs to retrieve the data and place it somewhere accessible

* use Preparable interceptor

* use Tiles interceptors

There were some fixes proposed too, extending Preparable, or implementing a 
FLASH scope to make the process quicker and more efficient.

It's a tribute to the flexibility of the framework that it could be done in so 
many different ways, but the purist and idealist in me thinks of the situation 
where a struts newby is asking what to do in this situation. It would be nice to 
say, 'This is where it goes, job done' rather than have to explain a work-around.

I'd like to see the idea taken on-board, even if it's just put on a back-burner. 
If my speed of development picks up (it can't get much slower at the moment - I 
find myself unintentionally at the wrong end of the learning curve again) then 
I'll definitely put together something myself by way of a demo. At the moment 
though I shall have to make do with an ugly child class extending TilesResult.

Best regards

Jeromy Evans on 10/01/08 01:32, wrote:
> 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.
>> 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 
>>>>> <> 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
>>>>>> 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:
For additional commands, e-mail:

View raw message