David, are you thinking about bringing Tiles up to incubator ? To be a *toplevel* apache project like Struts itself?
And yes... Merry Christmas ;-) Matthias > -----Original Message----- > From: David Geary [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 25, 2004 6:39 PM > To: Struts Developers List > Subject: Re: Taglibs and Tiles Extraction Issues > > > Merry Christmas, btw! > > Le Dec 25, 2004, à 1:35 AM, Don Brown a écrit : > > > I don't know about the other Struts folks, but I think this is would > > be a great addition to Tiles. > > This is not an addition to Tiles, this *is* Tiles. Perhaps I wasn't > clear. I have extracted the Tiles code from Struts 1.1, > including the > taglibs. I have taken that code and added a few enhancements, > including > a Tiles servlet, a JSF view handler and some demos. I have a > standalone > version of Tiles that works without Struts. > > > Initially, the Struts Tiles subproject could host Tiles, > but as more > > adapters get added, and perhaps the Tiles community > enlarges, there > > would be enough interest in hosting the Tiles project somewhere > > outside of Struts. > > It seems to me that now is the time for Tiles to be it's own > project. > Tiles has nothing to do with Struts, other than the fact that it > provides Struts integration. With my version of Tiles, I'd like to > provide integration for other display technologies as well. I'm also > interested in exploring integration with SiteMesh, which is a neat > technology (for page decoration) that compliments Tiles (for page > composition) nicely. None of those goals for Tiles has > anything to do > with Struts. > > I also think that Tiles would get more attention if it were it's own > project instead of a Struts subproject. IMO, Tiles has > stagnated and is > due for a facelift. > > > david > > > > > As for adapters, the Tiles build could follow the pattern > > commons-chain uses to optionally build adapters as jars are > available. > > Let me get the Tiles subproject setup, then we can start > working on > > integrating this code. > > > > Don > > > > > > David Geary wrote: > >> I have extracted a standalone version of Tiles from Struts > 1.1. I've > >> implemented a TilesServlet for using Tiles outside of > Struts and a > >> JSF view handler that forwards to a tile instead of a JSP page. I > >> also have some cool examples. > >> I was on the verge of starting an open source project for > standalone > >> Tiles that would focus on integration with other presentation > >> technologies besides Struts, such as JSF, Velocity, > Tapestry, etc. I > >> want a Tiles version that I can use with JSP only, or with the > >> framework of my choice. And I want Tiles to be integrated > as smoothly > >> as possible with my framework. I don't want to have to > drag Struts > >> around to do that. > >> So, I'm not sure what to do with my code. Do my goals for a > >> standalone Tiles align with the goals for the Tiles > subproject within > >> Struts? > >> david > >> Le Dec 24, 2004, à 3:30 PM, Martin Cooper a écrit : > >>> On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown <[EMAIL PROTECTED]> > >>> wrote: > >>> > >>>> I've made further progress in extracting tiles and taglibs, and > >>>> have run > >>>> into several issues I'd like to get some feedback on. > >>>> > >>>> 1. Tiles depends on TagUtils in taglibs. Tiles' version of > >>>> TagUtils has > >>>> a link to taglib's TagUtils.getScope(). I could copy > this method > >>>> over > >>>> (it is a whole 5 lines), but this raises a larger question of > >>>> subproject > >>>> dependencies and distribution. Will each subproject have its own > >>>> ibiblio entries? Ted suggested, and I agree, that > subprojects will > >>>> be > >>>> bundled with Struts releases ala Linux distributions, > but how do we > >>>> communicate intra-subproject dependencies? > >>> > >>> > >>> The method is short, but it relies on a map that is set up in a > >>> static > >>> initialiser... If we want to make Tiles usable in the absence of > >>> Struts, as some people do, I think we'd have to clone the > code within > >>> Tiles. > >>> > >>> With respect to ibiblio, I think it would make sense to consider > >>> Struts as a group and Struts subprojects as artifacts within that > >>> group (using Maven terminology here ;). > >>> > >>> I think you're asking about inter-subproject dependencies, right? > >>> This > >>> is one of the pieces of the build system I haven't yet found a > >>> solution for that I'm happy with. But I'm not sure if > you're asking > >>> about that, or about communicating the information to users. > >>> > >>>> 2. Mock objects. Currently, Struts contains mocks for > the servlet, > >>>> but > >>>> these classes would be useful for subprojects as well. > I suggest we > >>>> adopt StrutsTestCase, or another test package, as a > subproject or > >>>> dependency > >>> > >>> > >>> I still haven't taken the time to look at StrutsTestCase. > If we used > >>> that for our own testing, I assume, from what you say, > that we could > >>> then ditch the mock objects we have today? (What does > StrutsTestCase > >>> use for its own unit tests?) > >>> > >>>> 3. Cactus. I admit, I never got this working, and now > with taglibs > >>>> and > >>>> tiles unit tests requiring Cactus, I'm not sure how to > migrate that > >>>> build process over, especially as we await the Ant > reorganization > >>>> Martin > >>>> is working on. I'm leaning to committing all my changes > once I got > >>>> all > >>>> the code compiling and let someone more knowledgable > setup cactus > >>>> for > >>>> these two subprojects. > >>> > >>> > >>> It looks like EL "solved" this by copying the build files. > >>> Obviously, this is, um, less than optimal, but until the > new build > >>> is ready, perhaps we should do the same thing. On the > other hand, I > >>> don't think we want to put a lot of effort to making this > all work > >>> when the build system is changing (hopefully next week). > >>> > >>> -- > >>> Martin Cooper > >>> > >>> > >>>> Thanks for the help, > >>>> > >>>> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
