Thanks bro. We have a big S2 app where every package uses tiles as the
default result type. Tiles definitions are the name of the game. I too
think dependencies between plug-ins should be mitigated.
Peace,
Scott
On Sat, Sep 6, 2008 at 7:34 PM, Jeromy Evans <
[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
>> I don't understand how the codebehind or convention plug-in could provide
>> the inheritance and layout functionality of tiles. Moreover, we use
>> conventions to tag CSS to tile definitions. Can you elaborate please?
>>
>>
>>
>
> Maybe I misinterpreted your intent.
>
> Codebehind/Convnetion is responsible for selecting a result.
> it'll first check if there's an explicit result (@Result);
> then search for a JSP matching the convention (eg. order-show.jsp or
> whatever);
> then search for a FTL and or VM file matching the convention.
>
> The Tiles plugin could augment this process, so if none of the above are
> matched:
> search for a Tile with a name matching ("prefix.order.show", or whatever).
>
> So it wouldn't replace Tiles; it would just allow for the selection of
> Tiles based on a similar convention.
> Similarly, the UnknownHandler could attempt match a Tile if no action, jsp,
> ftl or vm file is found.
>
> I never looked further into it than that, but I expect the Tiles plugin
> could detect the presence of a convention plugin and augment its behaviour.
> We're not supposed to introduce dependencies between plugins though.
>
>
> None of this affects using tiles within pages. I've just been phasing out
> the use of TilesResult to use result-by-convention selection so I didn't
> have to write the above code. My main purpose for using TilesResult (that
> is, to override the tiles at runtime) hasn't come up on a REST application
> yet.
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
