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]
