Re: struts2 conventions plugin - how to override result type

[Ken McWilliams <ke...@gmail.com>]

The right thing to do was override the ConventionsUnknownHandler like you
suggested. Right now the code is pretty ugly, I need to add unit tests to
my TilesUnknownHandler and then I wouldn't mind contributing it.

When the struts2-tiles-plugin is upgraded to account for tiles3 it would be
nice if it would check to see if the conventions plugin is in the class
path and then use then use the tiles result type by default (or if not by
default then as at least as an option).

Currently either the TilesUnknownHandler or the TilesResultType produces a
location of (namespace + "#" + file) and feeds that string as a tiles
definition:

    <definition name="REGEXP:(.*)#(.*)"  extends="/test">
        <put-attribute name="body" value="/WEB-INF/content{1}/{2}"/>
    </definition>

The thing now is to define a convention for locating templates that makes
sense. Someway of dynamically generating tiles definitions from the content
under /WEB-INF.


On Wed, Nov 28, 2012 at 4:33 PM, Ken McWilliams <ke...@gmail.com>wrote:

> Sorry I wrote that before really looking the UnknownHandler, it is the
> right path.
>
> I'll get back with the results, and later I hope to have some questions
> about run time configuration (something I want to try is swapping the order
> of interceptors in a named stack at runtime).
>
>
> On Wed, Nov 28, 2012 at 1:08 PM, Lukasz Lenart <lu...@apache.org>wrote:
>
>> 2012/11/26 Ken McWilliams <ke...@gmail.com>:
>> > I've yet to try this but how do I tie this into conventions.
>>
>> Just add
>> <bean type="....UnknownHandler" class="....MyUnknownHandler"
>> name="myUnknownHandler"/>
>>
>> > My issue is that I am following conventions, there are JSPs located as
>> > views for the action (that is, located where conventions would expect to
>> > find view). My idea is to create a tiles plugin that keeps struts
>> > conventions as near as possible to the way they are. That is the body
>> > content is always assumed to be at
>> > /WEB-INF/content/{package}/{conventions-action-name}.{viewType}
>> >
>> > So conventions will still have a valid result, so the UnknownHandler
>> isn't
>> > ideal because conventions will think there is a valid result, unless
>> there
>> > is some way to update the configuration even if it is to intentionally
>> > break it...
>> >
>> > Is it possible to do something like that with a custom ActionProxy?
>>
>> I don't know, just try and share your code :-)
>>
>>
>> Regards
>> --
>> Łukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>

Re: struts2 conventions plugin - how to override result type

[Lukasz Lenart <lu...@apache.org>]

2012/12/6 Ken McWilliams <ke...@gmail.com>:
> The right thing to do was override the ConventionsUnknownHandler like you
> suggested. Right now the code is pretty ugly, I need to add unit tests to
> my TilesUnknownHandler and then I wouldn't mind contributing it.
>
> When the struts2-tiles-plugin is upgraded to account for tiles3 it would be
> nice if it would check to see if the conventions plugin is in the class
> path and then use then use the tiles result type by default (or if not by
> default then as at least as an option).
>
> Currently either the TilesUnknownHandler or the TilesResultType produces a
> location of (namespace + "#" + file) and feeds that string as a tiles
> definition:
>
>     <definition name="REGEXP:(.*)#(.*)"  extends="/test">
>         <put-attribute name="body" value="/WEB-INF/content{1}/{2}"/>
>     </definition>
>
> The thing now is to define a convention for locating templates that makes
> sense. Someway of dynamically generating tiles definitions from the content
> under /WEB-INF.

If you will be ready, feel free to register an issue with patch attached :-)


Kind regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

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