> 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.
that sounds nice! Using Tiles *standalone* is fine! Btw. have you looked at MyFaces' ViewHandler for JSF? > 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. I guess it is worth to have *core* tiles + *adapters* for Velocity, Tapestry, JSF, Struts, yet another framework > 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? As I said (my personal thoughts): a *core* Tiles version (or call it standalone) is fine. So why not having adapters for other frameworks. In MyFaces we include struts.jar for be able to build our ViewHandler. But this JAR contains *more* than we realy want :-) so I am +1 having tiles *core* as standalone... Regards, Matthias > 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]
