Re: REST plug-in Tiles
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]
Re: REST plug-in Tiles
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? On Fri, Sep 5, 2008 at 8:41 PM, Jeromy Evans [EMAIL PROTECTED] wrote: stanlick wrote: Does the plug-in support tiles definition names in its search? No. It was discussed briefly once in srtuts-dev that the codebehind plugin tiles plugin together could support tiles naming conventions. eg. if OrderController.show() is invoked then search for a tile called (prefix.order-show). I think that would be generally useful whether used with REST or not. However the main reason I use tiles results is because they're easy to override (eg. by theme and or locale). When I started to look deeper into the this I saw the codebehind or convention plugin could easily do the same when selecting results...so I've start to ween myself off tiles results and try to head towards zero configuration by following the convention. I've found I still need a lot of @Result annotations though so its not there yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plug-in Tiles
[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]
REST plug-in Tiles
Does the plug-in support tiles definition names in its search? -- View this message in context: http://www.nabble.com/REST-plug-in---Tiles-tp19339428p19339428.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST plug-in Tiles
stanlick wrote: Does the plug-in support tiles definition names in its search? No. It was discussed briefly once in srtuts-dev that the codebehind plugin tiles plugin together could support tiles naming conventions. eg. if OrderController.show() is invoked then search for a tile called (prefix.order-show). I think that would be generally useful whether used with REST or not. However the main reason I use tiles results is because they're easy to override (eg. by theme and or locale). When I started to look deeper into the this I saw the codebehind or convention plugin could easily do the same when selecting results...so I've start to ween myself off tiles results and try to head towards zero configuration by following the convention. I've found I still need a lot of @Result annotations though so its not there yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
