+1
That's pretty much my experience too.
So, with that said, can we move standalone to subproject level or are
we waiting on something?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: jmitchtx
On Aug 25, 2005, at 1:44 AM, Martin Cooper wrote:
On 8/24/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 8/24/05, James Mitchell <[EMAIL PROTECTED]> wrote:
Sorry if I'm piping up late on this.
What's the plans for Tiles? Will we support embedded tiles or will
we simply adapt standalone to work as we do for the commons stuff?
That's definitely a call for the developers invested in 1.3.x, but it
certainly makes the most sense to have one and only one
implementation
around, and just do bindings to it. Such bindings should be very
easy
in this case.
My preference would definitely be to support only one version, with
that version being the one we expect to support in future releases.
So, +1 for supporting Standalone Tiles only.
However, I've got a separate / semi-related question. Given that
we're changing package names anyway, it would be really cool to
abstract away the servlet API specific calling sequences, so that
standalone Tiles could work equally comfortably in a portlet
environment (without needing any portlet->servlet bridgework). The
only API a typical Tiles user will be using is Controller, so this
shouldn't be a huge deal. What do you think?
I'd say go for it. I would be *very* surprised if any more than a tiny
minority of Tiles users have any dependency on the Tiles API at all.
In my experience, the vast majority of Tiles users know little more
than they need to know to define their tiles in the tiles-defs.xml
file.
--
Martin Cooper
If we're ever going to do this to standalone Tiles, pre-1.0 would
seem
like the right time.
Craig
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: jmitchtx
On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
On 8/24/05, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 8/24/05, Wendy Smoak <[EMAIL PROTECTED]> wrote:
From: <[EMAIL PROTECTED]> (on struts-user)
test.jsp has this:
<%@ taglib uri="http://jakarta.apache.org/tiles";
prefix="tiles" %>
Jakarta? That can't be right... there's a problem:
The tld in last night's tiles-core.jar has a JSP 1.1 tld with
that uri,
which is coming from src/conf.
I noticed that tld the other day when I was changing the Maven
build files.
The doc/userGuide/tiles-core.xml file does have the right uri. I
think the
one in src/conf needs to be deleted-- the tld is probably still
supposed to
be generated from the files under doc/userGuide and doc/
stylesheets as part
of the build.
Eventually I'll generate a complete tld with all the
documentation, so that
Maven can create the taglibdoc and tag reference pages... the
one in
src/conf doesn't have any of that.
And what JSP version is Standalone Tiles using? The build files
declare a
dependency on Servlet 2.4 and JSP 2.0. I thought the intent was
for Struts
Classic (which is now at Servlet 2.3) to move to Standalone
Tiles. Is that
going to be possible with the mismatch in dependencies?
I believe the intent was that Standalone Tiles should rely on
Servlets
2.3 and JSP 1.2, as does Struts Classic. I hope that's still the
case,
and that we just need to fix up Tiles to conform to that.
Yes, that was definitely the intent for Standalone Tiles. It
probably
got mixed up during the multiple iterations of cut-n-paste from the
Struts-embedded sources, plus cut-n-paste changes to the build
environment, plus ...
Craig
--
Martin Cooper
--
Wendy
-----------------------------------------------------------------
---
-
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]
