More intelligent result type for convention plugin.

[Qi Spiker <sp...@gmail.com>]

More intelligent result type could make Convention plugin more
conventional. Here was my some initial thought:

In my personal experience, most of the time, logical result name was
not necessary.

If the result string was "create.jsp", it will be dispatch to
"create.jsp" under same package in "/WEB-INF/content". No need to look
up "create.vm" or other guess work, performance will also increase.

If the result string was "/login.jsp", it will be dispatch to
"/WEB-INF/content/login.jsp" .

If the result string was "redirect:create.jsp", then change result
type to "redirect".

If the result string was "edit.action", it will be chained to
"EditAction" under same namespace.

If the result string was SomeOtherAction.class.toString(), it will be
chained to the SomeOtherAction.

To change default result type of action from chain to other result
type, just prepend result type in result string, for example:
"redirect:edit.action".

This ideas was actually coming from stripes framework, which use
Resolution class to implement this function. In my opinion, the
stripes way was more elegant, you dont need worry about mis-type.

I also created one issue on
https://issues.apache.org/struts/browse/WW-2991 and uploaded my
initial implemention.

I agree this idea goes against some core struts pattern, but I still
feel it useful.

I was refactoring my previous webwork2 based business application to
struts 2 because of the introduction of Convention plugin. My previous
project layout was similar to the default convention of the plugin. To
convert chain result I must add a lot of @Results annotation, which
requires a lot of copy & paste. Using my result type, I could easily
replace chain results like "someotheraction" to
"someotheraction.action" with the help from IDE.

And this result type actually has better performance than default
convention used by the plugin. When the result string was "login.jsp",
it was "login.jsp". There were no need to do additional resource
search on "login.vm", "login.flt", "login.htm"...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: More intelligent result type for convention plugin.

[Qi Spiker <sp...@gmail.com>]

I dont expect this result "rule" goes to complex either.

In my implementation, the default result type for ".jsp" was
"dispatcher", the default result type for ".action" was "chain", this
"rule" covered 90% convention rules in my worked webwork2 projects.
Other than that, the only additional result type supported was
"redirect", which covered 5%. More complex result types (stream result
or parameterised result) still need to use @Result. But we could
reduce the @Result annotation to the minimum.

On Fri, Feb 13, 2009 at 11:46 PM, Musachy Barroso <mu...@gmail.com> wrote:
> The performance improves only when the UnknownHandler is called (no
> action mapping for current url), in the rest of the cases the result
> mappings are built when the application boots.
>
> I don't like the idea as it moves away from logical result names, and
> adds another set of "rules" not conventions, IMO. These rules would
> increase in complexity as people start using it outside the simple use
> cases, like, "how do I add parameters to a redirect?"
>
> my 2 pesos
> musachy
>
> On Fri, Feb 13, 2009 at 10:31 AM, Qi Spiker <sp...@gmail.com> wrote:
>> More intelligent result type could make Convention plugin more
>> conventional. Here was my some initial thought:
>>
>> In my personal experience, most of the time, logical result name was
>> not necessary.
>>
>> If the result string was "create.jsp", it will be dispatch to
>> "create.jsp" under same package in "/WEB-INF/content". No need to look
>> up "create.vm" or other guess work, performance will also increase.
>>
>> If the result string was "/login.jsp", it will be dispatch to
>> "/WEB-INF/content/login.jsp" .
>>
>> If the result string was "redirect:create.jsp", then change result
>> type to "redirect".
>>
>> If the result string was "edit.action", it will be chained to
>> "EditAction" under same namespace.
>>
>> If the result string was SomeOtherAction.class.toString(), it will be
>> chained to the SomeOtherAction.
>>
>> To change default result type of action from chain to other result
>> type, just prepend result type in result string, for example:
>> "redirect:edit.action".
>>
>> This ideas was actually coming from stripes framework, which use
>> Resolution class to implement this function. In my opinion, the
>> stripes way was more elegant, you dont need worry about mis-type.
>>
>> I also created one issue on
>> https://issues.apache.org/struts/browse/WW-2991 and uploaded my
>> initial implemention.
>>
>> I agree this idea goes against some core struts pattern, but I still
>> feel it useful.
>>
>> I was refactoring my previous webwork2 based business application to
>> struts 2 because of the introduction of Convention plugin. My previous
>> project layout was similar to the default convention of the plugin. To
>> convert chain result I must add a lot of @Results annotation, which
>> requires a lot of copy & paste. Using my result type, I could easily
>> replace chain results like "someotheraction" to
>> "someotheraction.action" with the help from IDE.
>>
>> And this result type actually has better performance than default
>> convention used by the plugin. When the result string was "login.jsp",
>> it was "login.jsp". There were no need to do additional resource
>> search on "login.vm", "login.flt", "login.htm"...
>>
>> ---------------------------------------------------------------------
>> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: More intelligent result type for convention plugin.

[Wes Wannemacher <we...@wantii.com>]

On Friday 13 February 2009 10:46:40 Musachy Barroso wrote:
> The performance improves only when the UnknownHandler is called (no
> action mapping for current url), in the rest of the cases the result
> mappings are built when the application boots.
>
> I don't like the idea as it moves away from logical result names, and
> adds another set of "rules" not conventions, IMO. These rules would
> increase in complexity as people start using it outside the simple use
> cases, like, "how do I add parameters to a redirect?"
>

I agree with Musachy that it would be bad to move away from logical result 
names. Qi, I would suggest that you post what you've got as a plugin up on 
google code, then register it in the Plugin Registry. This way we can gauge 
whether or not other users would adopt it. 

Having logical result names adds a level of indirection that can be handy. For 
instance, in your example, you have a logical step that is then evaluated to 
find the details. One place that this could be handy is in the "login" 
scenario... In the beginning, let's assume your app has a global "login" 
result that dispatches to a JSP page, but at some point in the future, you may 
want to have a form snippet returned via AJAX (displayed as a modal dialog). 

-Wes
-- 

Wes Wannemacher
Author - Struts 2 In Practice 
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
http://www.manning.com/wannemacher


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: More intelligent result type for convention plugin.

[Musachy Barroso <mu...@gmail.com>]

The performance improves only when the UnknownHandler is called (no
action mapping for current url), in the rest of the cases the result
mappings are built when the application boots.

I don't like the idea as it moves away from logical result names, and
adds another set of "rules" not conventions, IMO. These rules would
increase in complexity as people start using it outside the simple use
cases, like, "how do I add parameters to a redirect?"

my 2 pesos
musachy

On Fri, Feb 13, 2009 at 10:31 AM, Qi Spiker <sp...@gmail.com> wrote:
> More intelligent result type could make Convention plugin more
> conventional. Here was my some initial thought:
>
> In my personal experience, most of the time, logical result name was
> not necessary.
>
> If the result string was "create.jsp", it will be dispatch to
> "create.jsp" under same package in "/WEB-INF/content". No need to look
> up "create.vm" or other guess work, performance will also increase.
>
> If the result string was "/login.jsp", it will be dispatch to
> "/WEB-INF/content/login.jsp" .
>
> If the result string was "redirect:create.jsp", then change result
> type to "redirect".
>
> If the result string was "edit.action", it will be chained to
> "EditAction" under same namespace.
>
> If the result string was SomeOtherAction.class.toString(), it will be
> chained to the SomeOtherAction.
>
> To change default result type of action from chain to other result
> type, just prepend result type in result string, for example:
> "redirect:edit.action".
>
> This ideas was actually coming from stripes framework, which use
> Resolution class to implement this function. In my opinion, the
> stripes way was more elegant, you dont need worry about mis-type.
>
> I also created one issue on
> https://issues.apache.org/struts/browse/WW-2991 and uploaded my
> initial implemention.
>
> I agree this idea goes against some core struts pattern, but I still
> feel it useful.
>
> I was refactoring my previous webwork2 based business application to
> struts 2 because of the introduction of Convention plugin. My previous
> project layout was similar to the default convention of the plugin. To
> convert chain result I must add a lot of @Results annotation, which
> requires a lot of copy & paste. Using my result type, I could easily
> replace chain results like "someotheraction" to
> "someotheraction.action" with the help from IDE.
>
> And this result type actually has better performance than default
> convention used by the plugin. When the result string was "login.jsp",
> it was "login.jsp". There were no need to do additional resource
> search on "login.vm", "login.flt", "login.htm"...
>
> ---------------------------------------------------------------------
> 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