You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Adam Hardy <ah...@cyberspaceroad.com> on 2007/12/28 13:59:08 UTC
Would like more flexibility in Result
I'm using Tiles2 so I configured the TilesResult for my views.
To set up the lists for dropdowns in those tiles, I am coding my own Result,
rather than relying on a weakly related Action to do it.
My result has to extend TilesResult, but it seems to be an unnecessary
dependency, because really my Result has little to do with Tiles.
Wouldn't it be beneficial if the Results could be chained together like the
interceptors?
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)
- naming the Tile
So I would define my Results globally specifying the Tile (or other view type),
and optionally the caching, the parameter(s) and the localization, and then use
it wherever needed.
This would tie up the view coding with the view itself, and overcome the problem
with validation failure returning flow to the view when the required dropdown
lists are not present.
Does that make sense for future development?
Regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Would like more flexibility in Result
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Brian Pontarelli on 29/12/07 05:34, wrote:
> Adam Hardy wrote:
>> Brian Pontarelli on 28/12/07 18:12, wrote:
>>>> 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.
>>
>> Well I guess I differ from you then in that I would hesitate before
>> allowing anyone on my project to call actions from the JSPs.
>> Admittedly it looks really easy.
> This could be very philosophical debate about code hiding and
> protection. But I'll make it simple and just say that I believe that
> Actions are meant to be invoked by anyone. The world will be invoking
> them from a browser or AJAX and they can monkey around with HTTP
> parameters and much more. I tend to make Actions completely accessible.
> If something needs to be protected, I move it back to my service tier.
>
>>
>> I presume that the interceptors surrounding the action do not get
>> invoked? Or do they? Either way, invoking the actions again seems to
>> fold the architecture back in on itself.
> I would have to assume so since the parameters interceptor is being
> called in order to pass parameters to the Action. As for the folding,
> this is where we can probably agree to disagree. I don't see any
> difference between this model and a JSP taglib. I've just removed the
> need to write a taglib, which is faster and more testable.
>
>> Hence my original message - it seems there's a place for calls to the
>> model in the position where the Results are at the moment.
> How do you configure this? My main point is that this seems like more
> configuration/overhead. I'm heading the opposite direction with no
> configuration and simple handling of as much as possible.
I'm very much in favour of a KISS approach, don't get me wrong. I think I was
not seeing the wood for the trees.
I take your point that perhaps messing with Result is not the way to go, but I
can't appreciate the <s:action> tag.
I'll ditch this thread and reformulate what I'm trying to communicate.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Would like more flexibility in Result
Posted by Brian Pontarelli <br...@pontarelli.com>.
Adam Hardy wrote:
> Brian Pontarelli on 28/12/07 18:12, wrote:
>>> 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.
>
> Well I guess I differ from you then in that I would hesitate before
> allowing anyone on my project to call actions from the JSPs.
> Admittedly it looks really easy.
This could be very philosophical debate about code hiding and
protection. But I'll make it simple and just say that I believe that
Actions are meant to be invoked by anyone. The world will be invoking
them from a browser or AJAX and they can monkey around with HTTP
parameters and much more. I tend to make Actions completely accessible.
If something needs to be protected, I move it back to my service tier.
>
> I presume that the interceptors surrounding the action do not get
> invoked? Or do they? Either way, invoking the actions again seems to
> fold the architecture back in on itself.
I would have to assume so since the parameters interceptor is being
called in order to pass parameters to the Action. As for the folding,
this is where we can probably agree to disagree. I don't see any
difference between this model and a JSP taglib. I've just removed the
need to write a taglib, which is faster and more testable.
> Hence my original message - it seems there's a place for calls to the
> model in the position where the Results are at the moment.
How do you configure this? My main point is that this seems like more
configuration/overhead. I'm heading the opposite direction with no
configuration and simple handling of as much as possible.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Would like more flexibility in Result
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Brian Pontarelli on 28/12/07 18:12, wrote:
>> 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.
Well I guess I differ from you then in that I would hesitate before allowing
anyone on my project to call actions from the JSPs. Admittedly it looks really
easy.
I presume that the interceptors surrounding the action do not get invoked? Or do
they? Either way, invoking the actions again seems to fold the architecture back
in on itself.
Hence my original message - it seems there's a place for calls to the model in
the position where the Results are at the moment.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Would like more flexibility in Result
Posted by Brian Pontarelli <br...@pontarelli.com>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Would like more flexibility in Result
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Would like more flexibility in Result
Posted by Brian Pontarelli <br...@pontarelli.com>.
> 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"/>
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org