Re: Taglibs and Tiles Extraction Issues

[David Geary]

Le Dec 26, 2004, à 3:50 AM, Matthias Wessendorf a écrit :
David,
are you thinking about bringing Tiles up to
incubator ? To be a *toplevel* apache project
like Struts itself?
I'd like to see an open-source standalone version of Tiles. A toplevel 
Apache project is one way to do that.

david
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]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]