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]
