On Tue, 21 Dec 2004 20:25:55 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > I think a separate subproject for Tiles (including the code and the > tags) probably makes the most sense.
+1 > If we don't mind the dependency > back onto Struts, then this could also include the Struts PlugIn that > is currently used to configure it -- although it would probably be > better that this class stay part of Struts so that the Tiles library > could be used stand alone. I'd prefer to see it the first way - Tiles has a (compile-time) dependency on Struts, and includes the plugin to be able to work with Struts. This is analogous to the way Commons Chain has compile-time dependencies on Servlets, Portlets and JSF, enabling it to work in those environments if desired. A Velocity adapter could then also live within Tiles, along with any others that people want to develop. Having the Struts adapter be a part of Tiles doesn't prevent the Tiles library from being used standalone any more than the Servlets, Portlets and JSF adapters for Chain prevent its use outside all of those environments. > In addition, there should be mechanisms to configure the Tiles > definitions even if Struts is not present, via TilesServlet (which I > believe already exists?) and/or a new ServletContextListener > implementation since we're willing to use Servlet 2.3. +1 -- Martin Cooper > Craig > > On Tue, 21 Dec 2004 18:29:43 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > > It has been discussed, I believe, to separate Tiles from Struts, but no > > one seemed to know where it would go. jakarta-commons doesn't want > > taglibs, and for some reason I don't remember, the taglibs project > > wasn't accepted. It would be kinda funny, though, since Tiles used to > > be its own project that was assimilated into Struts when Struts was > > trying to divest iteself of code into commons. > > > > I mentioned the separation of Tiles from their taglibs as I thought I > > heard somewhere of Velocity being able to use Tiles. I could be wrong > > though. > > > > Don > > > > Eddie Bush wrote: > > > Actually, I'd tend to agree with that. It makes more sense than > > > separating Tiles and the Tiles taglibs - don't think you'd use the > > > former without the latter. Maybe ... but I don't. > > > > > > > > > On Tue, 21 Dec 2004 20:35:53 -0500, Deadman, Hal <[EMAIL PROTECTED]> > > > wrote: > > > > > >>Haven't look into this much but it would seem better to have a > > >>completely separate tiles sub-project that struts core would use. Don't > > >>JSF and Spring currently use tiles and have to include struts.jar when > > >>all they really want is tiles? > > >> > > >> > > >>>-----Original Message----- > > >>>From: Don Brown [mailto:[EMAIL PROTECTED] > > >>>Sent: Tuesday, December 21, 2004 7:51 PM > > >>>To: Struts Developers List > > >>>Subject: Extracting taglibs > > >>> > > >>>My basic assumption in approaching taglibs extraction into its own > > >>>subproject is it can reference Struts classes, but Struts classes > > >>>shouldn't reference it. > > >>> > > >>>If that is correct, here are the changes I see happening to extract > > >>>taglibs: > > >>> > > >>>1. Move o.a.s.taglib out into its own subproject src tree > > >>>2. Remove methods in RequestUtils that delegate to TagUtils. They are > > >>>marked as deprecated anyways and explicitly say they will be removed > > >>>after 1.2. > > >>>3. Move properties in o.a.s.taglib.html.Constants that are referred to > > >>>in Struts core code into o.a.s.Globals. (cancel and token keys) > > >>>4. Move o.a.s.taglib.tiles to o.a.s.tiles.taglib This one I'm not > > >> > > >>sure > > >> > > >>>about. Should/can tiles be used w/o its jsp taglibs? If not, then it > > >>>should stay in core w/ tiles. Otherwise, it could be moved out too. > > >>> > > >>>That should be it, as far as I can tell. taglibs are already pretty > > >>>well isolated from the rest of Struts which will make the extraction > > >>>pretty straightforward. > > >>> > > >>>I'd like to get this done before Christmas (25th) if there are no > > >>>objections. > > >>> > > >>>Don > > >>> > > >>> > > >>>--------------------------------------------------------------------- > > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>> > > >> > > >>--------------------------------------------------------------------- > > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
