You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Musachy Barroso <mu...@gmail.com> on 2008/01/02 23:08:18 UTC
Re: invent way to get dropdown data in JSP not using actions or taglibs?
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 <ah...@cyberspaceroad.com> 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)
>
>
> Regards
> Adam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: invent way to get dropdown data in JSP not using actions or taglibs?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Jeromy Evans on 10/01/08 01:32, wrote:
>> 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.
Thanks for the answer. I discovered that from the OGNL stacktrace I had
produced. I had a private property with public getters and setters on my Result.
OGNL threw a IllegalAccessException. So I deleted the getters and setters and
made the field public. It seems you don't need the getters and setters for OGNL.
See my next msg for continuation on the thread re architecture.
Thanks
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: invent way to get dropdown data in JSP not using actions or taglibs?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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
Adam
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.
[snip]
>> 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
>>>>> <ah...@cyberspaceroad.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: invent way to get dropdown data in JSP not using actions or taglibs?
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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
>>>> <ah...@cyberspaceroad.com>
>>>> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: invent way to get dropdown data in JSP not using actions or taglibs?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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?
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?
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 <ah...@cyberspaceroad.com>
>>> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: invent way to get dropdown data in JSP not using actions or taglibs?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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 <ah...@cyberspaceroad.com>
>> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: invent way to get dropdown data in JSP not using actions or taglibs?
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 <ah...@cyberspaceroad.com> 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)
>>
>>
>> Regards
>> Adam
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org