RE: RE: Tiles Refactorings for 1.1 compatability
Three quick notes: * We should specifically ask on the user list about the timing of Servlet 2.3 / JSP 1.2 dependence. I would expect this to be a bit controversial on that short a time frame. On the other hand, knowing we could interoperate with (and not just integrate with) JSTL (and JSF when done) would be nice. * If the STXX folks are still interested, I'd like to see more formal support for XML processing pipelines be included in a 1.2 time frame. This will help people who want to leverage Struts in a web services hype world, as well as being generally useful. * I'd defer a decision on whether Struts 2.0 advances to Servlet 2.4 and JSP 2.0 or not for a while yet -- to me, it really depends on the adoption rate for J2EE 1.4 and the availability of products that run it. From the Struts perspective, Servlet 2.3-2.4 doesn't buy a lot, but the JSP 1.2-2.0 changes are going to be very very useful. Craig On Thu, 17 Oct 2002, Byrne, Steven wrote: Date: Thu, 17 Oct 2002 14:17:10 -0400 From: Byrne, Steven [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: RE: Tiles Refactorings for 1.1 compatability Here's the draft roadmap that I wrote up. Struts 1.1 * Servlet 2.2 / JSP 1.1 based * tiles validator first class citizens * tiles module aware * validator module aware * Struts-el tag lib at contrib status * [need help here] ??? factored out into jakarta commons * resources factored out into commons-resources? Struts 1.2 January 2003 [duration: 2 months? ] * Servlet 2.3 / JSP 1.2 based * Struts-el tag lib integrated * Support for distributed struts components within a single application (either by just having a list of them or by using some assembling technology) * tiles JSTL aware * 1.1 bug fixes * [need help here] ??? factored out into jakarta commons Struts 2.0 Q2 2003 [duration: ??? months ] * Servlet 2.4 / JSP 2.0 * JSF integration [I'm not sure whether to tie these items in with the above roadmap or not] Struts 1.2 * investigate and prototype alternative module organizations including * arbitrary levels of nesting * locale based structuring * inheritance of elements from base types * struts-config * tiles [already has this, but there may be ways to make it cleaner] * validators * investigate adding identifier namespaces -Original Message- From: Ted Husted [mailto:husted;apache.org] Sent: Thursday, October 17, 2002 5:04 AM To: Struts Developers List Subject: Re: RE: Tiles Refactorings for 1.1 compatability I posted a starter version of the roadmap so we'd have something to patch :0) http://jakarta.apache.org/struts/status.html -Ted. 10/16/2002 4:42:10 PM, Byrne, Steven [EMAIL PROTECTED] wrote: Definitely a big part of what 1.1 is all about is integrating Tiles and Validator into the main Struts distribution. Pulling them back into pseudo-contrib status would not be a good thing. Has anyone estimated the level of effort to make each of them be sub-app aware? I imagine it's non-trival, but not overly large. And, since we have new, eager, smart committers with plenty of energy and motivation, I would think that these changes could be done in a reasonable timeframe, perhaps with a little guidance from the original authors of the respective components. Steve -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: Wednesday, October 16, 2002 1:27 PM To: [EMAIL PROTECTED] Subject: RE: Tiles Refactorings for 1.1 compatability To me, validator and tiles are part of the core. Without them, struts loses much of its utility and importance. David From: Joe Germuska [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: Tiles Refactorings for 1.1 compatability Date: Wed, 16 Oct 2002 14:54:18 -0500 At 12:27 PM -0700 2002/10/16, Martin Cooper wrote: Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Would I veto adding new functionality in a second beta that everyone is waiting for a final release of? I'd have to seriously consider it. Would it seriously mess up the current release cycle to decouple Tiles and Validator from the core as an attempt to simplify the 1.1 release? It seems like there needs to be a middle-ground between the contrib folder
RE: Tiles Refactorings for 1.1 compatability
I'm beginning to think that you and Eddie are reading a different document that the one I'm seeing. I don't see anything in this doc that mentions contrib libraries at all, and regarding Eddie's comment, Tiles is listed under Struts 1.1, not 1.2. Regarding Struts-EL, I fully expect that it will be included as a contrib taglib in the Struts 1.1 release. This is very cool stuff. -- Martin Cooper -Original Message- From: Karr, David [mailto:david.karr;attws.com] Sent: Thursday, October 17, 2002 9:48 AM To: 'Struts Developers List' Subject: RE: Tiles Refactorings for 1.1 compatability -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Thursday, October 17, 2002 9:10 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Ted Husted wrote: I posted a starter version of the roadmap so we'd have something to patch :0) http://jakarta.apache.org/struts/status.html -Ted. Just so I understand, is there a desire to not have Struts-EL in the 1.1 release? I know this document is extremely preliminary, but the omission of it from the phrase about contrib libraries makes me think that's the intent. If that's the case, I take no offense, I just want to be clear on our direction. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: RE: Tiles Refactorings for 1.1 compatability
Here's the draft roadmap that I wrote up.
Struts 1.1
* Servlet 2.2 / JSP 1.1 based
* tiles validator first class citizens
* tiles module aware
* validator module aware
* Struts-el tag lib at contrib status
* [need help here] ??? factored out into jakarta commons
* resources factored out into commons-resources?
Struts 1.2 January 2003 [duration: 2 months? ]
* Servlet 2.3 / JSP 1.2 based
* Struts-el tag lib integrated
* Support for distributed struts components within a single
application
(either by just having a list of them or by using some assembling
technology)
* tiles JSTL aware
* 1.1 bug fixes
* [need help here] ??? factored out into jakarta commons
Struts 2.0 Q2 2003 [duration: ??? months ]
* Servlet 2.4 / JSP 2.0
* JSF integration
[I'm not sure whether to tie these items in with the above roadmap or
not]
Struts 1.2
* investigate and prototype alternative module organizations including
* arbitrary levels of nesting
* locale based structuring
* inheritance of elements from base types
* struts-config
* tiles [already has this, but there may be ways to make it
cleaner]
* validators
* investigate adding identifier namespaces
-Original Message-
From: Ted Husted [mailto:husted;apache.org]
Sent: Thursday, October 17, 2002 5:04 AM
To: Struts Developers List
Subject: Re: RE: Tiles Refactorings for 1.1 compatability
I posted a starter version of the roadmap so we'd have
something to patch :0)
http://jakarta.apache.org/struts/status.html
-Ted.
10/16/2002 4:42:10 PM, Byrne, Steven [EMAIL PROTECTED] wrote:
Definitely a big part of what 1.1 is all about is
integrating Tiles and
Validator into the main Struts distribution. Pulling them back into
pseudo-contrib status would not be a good thing.
Has anyone estimated the level of effort to make each of
them be sub-app
aware? I imagine it's non-trival, but not overly large.
And, since we
have new, eager, smart committers with plenty of energy and
motivation,
I would think that these changes could be done in a reasonable
timeframe, perhaps with a little guidance from the original
authors of
the respective components.
Steve
-Original Message-
From: David Graham [mailto:dgraham1980;hotmail.com]
Sent: Wednesday, October 16, 2002 1:27 PM
To: [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
To me, validator and tiles are part of the core. Without
them, struts loses
much of its utility and importance.
David
From: Joe Germuska [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List
[EMAIL PROTECTED],
'[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
Date: Wed, 16 Oct 2002 14:54:18 -0500
At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:
Now that we have modules in play, would anyone VETO adding
the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that
everyone is
waiting for a final release of? I'd have to seriously
consider it.
Would it seriously mess up the current release cycle to
decouple Tiles and
Validator from the core as an attempt to simplify the 1.1
release? It
seems like there needs to be a middle-ground between the
contrib folder
and the core where useful tools can be developed and
released without
interfering with the core.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes
get glazed,
they go white, their hands tremble As I watch them I
often feel that a
dope peddler is a gentleman compared with the man who
sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-dev-help;jakarta.apache.org
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--
To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Craig R. McClanahan wrote: Three quick notes: * We should specifically ask on the user list about the timing of Servlet 2.3 / JSP 1.2 dependence. I would expect this to be a bit controversial on that short a time frame. On the other hand, knowing we could interoperate with (and not just integrate with) JSTL (and JSF when done) would be nice. +0 * If the STXX folks are still interested, I'd like to see more formal support for XML processing pipelines be included in a 1.2 time frame. This will help people who want to leverage Struts in a web services hype world, as well as being generally useful. +1 Yep - lots of interest there, I think. * I'd defer a decision on whether Struts 2.0 advances to Servlet 2.4 and JSP 2.0 or not for a while yet -- to me, it really depends on the adoption rate for J2EE 1.4 and the availability of products that run it. From the Struts perspective, Servlet 2.3-2.4 doesn't buy a lot, but the JSP 1.2-2.0 changes are going to be very very useful. +1 Yep. Craig -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Alternative is (not at all sure better) is to have soap (similar to way http does) call action, and not have JSP emit XML. Beans are already string properties, easy to make an collection of xml. The JSP people could do JSTL X: Transform (and... as some know I look for way to do transform in browser) to same action. .V Craig R. McClanahan wrote: Three quick notes: * We should specifically ask on the user list about the timing of Servlet 2.3 / JSP 1.2 dependence. I would expect this to be a bit controversial on that short a time frame. On the other hand, knowing we could interoperate with (and not just integrate with) JSTL (and JSF when done) would be nice. * If the STXX folks are still interested, I'd like to see more formal support for XML processing pipelines be included in a 1.2 time frame. This will help people who want to leverage Struts in a web services hype world, as well as being generally useful. * I'd defer a decision on whether Struts 2.0 advances to Servlet 2.4 and JSP 2.0 or not for a while yet -- to me, it really depends on the adoption rate for J2EE 1.4 and the availability of products that run it. From the Struts perspective, Servlet 2.3-2.4 doesn't buy a lot, but the JSP 1.2-2.0 changes are going to be very very useful. Craig On Thu, 17 Oct 2002, Byrne, Steven wrote: Date: Thu, 17 Oct 2002 14:17:10 -0400 From: Byrne, Steven [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: RE: Tiles Refactorings for 1.1 compatability Here's the draft roadmap that I wrote up. Struts 1.1 * Servlet 2.2 / JSP 1.1 based * tiles validator first class citizens * tiles module aware * validator module aware * Struts-el tag lib at contrib status * [need help here] ??? factored out into jakarta commons * resources factored out into commons-resources? Struts 1.2 January 2003 [duration: 2 months? ] * Servlet 2.3 / JSP 1.2 based * Struts-el tag lib integrated * Support for distributed struts components within a single application (either by just having a list of them or by using some assembling technology) * tiles JSTL aware * 1.1 bug fixes * [need help here] ??? factored out into jakarta commons Struts 2.0 Q2 2003 [duration: ??? months ] * Servlet 2.4 / JSP 2.0 * JSF integration [I'm not sure whether to tie these items in with the above roadmap or not] Struts 1.2 * investigate and prototype alternative module organizations including * arbitrary levels of nesting * locale based structuring * inheritance of elements from base types * struts-config * tiles [already has this, but there may be ways to make it cleaner] * validators * investigate adding identifier namespaces -Original Message- From: Ted Husted [mailto:husted;apache.org] Sent: Thursday, October 17, 2002 5:04 AM To: Struts Developers List Subject: Re: RE: Tiles Refactorings for 1.1 compatability I posted a starter version of the roadmap so we'd have something to patch :0) http://jakarta.apache.org/struts/status.html -Ted. 10/16/2002 4:42:10 PM, Byrne, Steven [EMAIL PROTECTED] wrote: Definitely a big part of what 1.1 is all about is integrating Tiles and Validator into the main Struts distribution. Pulling them back into pseudo-contrib status would not be a good thing. Has anyone estimated the level of effort to make each of them be sub-app aware? I imagine it's non-trival, but not overly large. And, since we have new, eager, smart committers with plenty of energy and motivation, I would think that these changes could be done in a reasonable timeframe, perhaps with a little guidance from the original authors of the respective components. Steve -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: Wednesday, October 16, 2002 1:27 PM To: [EMAIL PROTECTED] Subject: RE: Tiles Refactorings for 1.1 compatability To me, validator and tiles are part of the core. Without them, struts loses much of its utility and importance. David From: Joe Germuska [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: Tiles Refactorings for 1.1 compatability Date: Wed, 16 Oct 2002 14:54:18 -0500 At 12:27 PM -0700 2002/10/16, Martin Cooper wrote: Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Would I veto adding new functionality in a second beta that everyone is waiting for a final release of? I'd have to seriously consider it. Would it seriously mess up the current release cycle to decouple Tiles and Validator from
Re: Tiles Refactorings for 1.1 compatability
+1 Ted Husted wrote: Erik, If you'd like to write a section for the UserGuide on using XDoclet with Struts, I'm sure we'd all love to read it =:0) -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
I'm thick-headed and stupid - that's the problem. I was misreading the document earlier. My apologies. Ted stated Remaining ..., but I read in 1.2. shake-head/ I'm sorry. Martin Cooper wrote: I'm beginning to think that you and Eddie are reading a different document that the one I'm seeing. I don't see anything in this doc that mentions contrib libraries at all, and regarding Eddie's comment, Tiles is listed under Struts 1.1, not 1.2. Regarding Struts-EL, I fully expect that it will be included as a contrib taglib in the Struts 1.1 release. This is very cool stuff. -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Byrne, Steven wrote: Here's the draft roadmap that I wrote up. Struts 1.1 * Servlet 2.2 / JSP 1.1 based * tiles validator first class citizens * tiles module aware * validator module aware * Struts-el tag lib at contrib status * [need help here] ??? factored out into jakarta commons * resources factored out into commons-resources? Struts 1.2 January 2003 [duration: 2 months? ] * Servlet 2.3 / JSP 1.2 based -1 * Struts-el tag lib integrated * Support for distributed struts components within a single application (either by just having a list of them or by using some assembling technology) * tiles JSTL aware ? What is the problem with Tiles' JSTL awareness? * 1.1 bug fixes This would be about the only thing here IMHO. * [need help here] ??? factored out into jakarta commons Struts 2.0 Q2 2003 [duration: ??? months ] * Servlet 2.4 / JSP 2.0 -1 - 2.0 will be 2.3 /1.2 * JSF integration Right. [I'm not sure whether to tie these items in with the above roadmap or not] Struts 1.2 * investigate and prototype alternative module organizations including * arbitrary levels of nesting This can be done now. * locale based structuring * inheritance of elements from base types * struts-config * tiles [already has this, but there may be ways to make it cleaner] * validators * investigate adding identifier namespaces The sharing is the thing we're struggling with - more precisely the timing of implementing it. It has been suggested this would happen in 1.2, and I think that's acceptable. I think (personally) 1.2 should focus *only* on how we will give more brains to modules. It should be a *quick* turn-around - throwing in 2.3 / 1.2 will do nothing to aid it's quick delivery, and Craig himself suggested those changes (along iwth JSF) be slated for 2.0. I like his idea. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
It will be a proposal for a common tiles/templates taglib intended to be included in JSTL. But this can't happen before a JSTL2.x release. So, you can continue to use your favorite Tiles framework, we will continue to support it for a long time ;-). Cedric Byrne, Steven wrote: What I meant was essentially tiles-el, which is what I thought this message from Cedric was referring to: Martin Cooper wrote: Meanwhile, David Geary, who was the original author of the template library, went on to develop the Regions library, which he describes in his book, Advanced JavaServer Pages. At one point, there was some discussion of David and Cedric working together to combine the best of Regions and Tiles, but as far as I'm aware, nothing came of that. We, David and me, are in contact. We should soon start working on a common proposal for a next major version of JSTL. -Original Message- From: Karr, David [mailto:david.karr;attws.com] Sent: Thursday, October 17, 2002 11:50 AM To: 'Struts Developers List' Subject: RE: Tiles Refactorings for 1.1 compatability -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Thursday, October 17, 2002 11:29 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Byrne, Steven wrote: Here's the draft roadmap that I wrote up. Struts 1.2 January 2003 [duration: 2 months? ] * tiles JSTL aware ? What is the problem with Tiles' JSTL awareness? At the least, I would assume this refers to the fact that there is no tiles-el library yet. If that's all that means, I don't expect any problem with building a tiles-el sublibrary by the January timeframe (not to mention nested-el, or any other existing sub-libraries). -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Tiles Refactorings for 1.1 compatability
What I meant was essentially tiles-el, which is what I thought this message from Cedric was referring to: Martin Cooper wrote: Meanwhile, David Geary, who was the original author of the template library, went on to develop the Regions library, which he describes in his book, Advanced JavaServer Pages. At one point, there was some discussion of David and Cedric working together to combine the best of Regions and Tiles, but as far as I'm aware, nothing came of that. We, David and me, are in contact. We should soon start working on a common proposal for a next major version of JSTL. -Original Message- From: Karr, David [mailto:david.karr;attws.com] Sent: Thursday, October 17, 2002 11:50 AM To: 'Struts Developers List' Subject: RE: Tiles Refactorings for 1.1 compatability -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Thursday, October 17, 2002 11:29 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Byrne, Steven wrote: Here's the draft roadmap that I wrote up. Struts 1.2 January 2003 [duration: 2 months? ] * tiles JSTL aware ? What is the problem with Tiles' JSTL awareness? At the least, I would assume this refers to the fact that there is no tiles-el library yet. If that's all that means, I don't expect any problem with building a tiles-el sublibrary by the January timeframe (not to mention nested-el, or any other existing sub-libraries). -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Tiles Refactorings for 1.1 compatability
I guess I don't know what that means. The David obviously refers to David Geary, not me, but I don't know what the JSTL reference is for. I would have assumed they would first build something that combines the best of regions and tiles, without incorporating the JSTL EL engine, and that something like regionstiles-el would be implemented separately. -Original Message- From: Byrne, Steven [mailto:sbyrne;dorado.com] Sent: Thursday, October 17, 2002 12:26 PM To: Struts Developers List Subject: RE: Tiles Refactorings for 1.1 compatability What I meant was essentially tiles-el, which is what I thought this message from Cedric was referring to: Martin Cooper wrote: Meanwhile, David Geary, who was the original author of the template library, went on to develop the Regions library, which he describes in his book, Advanced JavaServer Pages. At one point, there was some discussion of David and Cedric working together to combine the best of Regions and Tiles, but as far as I'm aware, nothing came of that. We, David and me, are in contact. We should soon start working on a common proposal for a next major version of JSTL. -Original Message- From: Karr, David [mailto:david.karr;attws.com] Sent: Thursday, October 17, 2002 11:50 AM To: 'Struts Developers List' Subject: RE: Tiles Refactorings for 1.1 compatability -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Thursday, October 17, 2002 11:29 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Byrne, Steven wrote: Here's the draft roadmap that I wrote up. Struts 1.2 January 2003 [duration: 2 months? ] * tiles JSTL aware ? What is the problem with Tiles' JSTL awareness? At the least, I would assume this refers to the fact that there is no tiles-el library yet. If that's all that means, I don't expect any problem with building a tiles-el sublibrary by the January timeframe (not to mention nested-el, or any other existing sub-libraries). -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Byrne, Steven [mailto:sbyrne;dorado.com] Sent: Thursday, October 17, 2002 11:56 AM To: Struts Developers List Subject: RE: Tiles Refactorings for 1.1 compatability I was given to understand that Struts-el needed Servlet 2.3, and so that's why I suggested having it in 1.2. But my main purpose was to create a common definition of what was going to be in each release (and have it track as things change), so it should reflect the shared belief of the developers. David Karr -- care to chime in on whether Struts-el needs Servlet 2.3/JSP 1.2? Yes, Struts-EL needs the JSTL, which needs Servlet 2.3. Thus, Struts-EL can't be integrated into Struts until the release where we require Servlet 2.3. However, there's nothing wrong with it being in the contrib section of the pre-required-Servlet 2.3 release, even if the jar file is distributed next to the struts.jar file in the binary release. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Thursday, October 17, 2002 11:29 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Byrne, Steven wrote: Here's the draft roadmap that I wrote up. Struts 1.2 January 2003 [duration: 2 months? ] * tiles JSTL aware ? What is the problem with Tiles' JSTL awareness? At the least, I would assume this refers to the fact that there is no tiles-el library yet. If that's all that means, I don't expect any problem with building a tiles-el sublibrary by the January timeframe (not to mention nested-el, or any other existing sub-libraries). -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Tiles Refactorings for 1.1 compatability
I was given to understand that Struts-el needed Servlet 2.3, and so that's why I suggested having it in 1.2. But my main purpose was to create a common definition of what was going to be in each release (and have it track as things change), so it should reflect the shared belief of the developers. David Karr -- care to chime in on whether Struts-el needs Servlet 2.3/JSP 1.2? Steve -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Thursday, October 17, 2002 11:29 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Byrne, Steven wrote: Here's the draft roadmap that I wrote up. Struts 1.1 * Servlet 2.2 / JSP 1.1 based * tiles validator first class citizens * tiles module aware * validator module aware * Struts-el tag lib at contrib status * [need help here] ??? factored out into jakarta commons * resources factored out into commons-resources? Struts 1.2 January 2003 [duration: 2 months? ] * Servlet 2.3 / JSP 1.2 based -1 * Struts-el tag lib integrated * Support for distributed struts components within a single application (either by just having a list of them or by using some assembling technology) * tiles JSTL aware ? What is the problem with Tiles' JSTL awareness? * 1.1 bug fixes This would be about the only thing here IMHO. * [need help here] ??? factored out into jakarta commons Struts 2.0 Q2 2003 [duration: ??? months ] * Servlet 2.4 / JSP 2.0 -1 - 2.0 will be 2.3 /1.2 * JSF integration Right. [I'm not sure whether to tie these items in with the above roadmap or not] Struts 1.2 * investigate and prototype alternative module organizations including * arbitrary levels of nesting This can be done now. * locale based structuring * inheritance of elements from base types * struts-config * tiles [already has this, but there may be ways to make it cleaner] * validators * investigate adding identifier namespaces The sharing is the thing we're struggling with - more precisely the timing of implementing it. It has been suggested this would happen in 1.2, and I think that's acceptable. I think (personally) 1.2 should focus *only* on how we will give more brains to modules. It should be a *quick* turn-around - throwing in 2.3 / 1.2 will do nothing to aid it's quick delivery, and Craig himself suggested those changes (along iwth JSF) be slated for 2.0. I like his idea. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: RE: RE: Tiles Refactorings for 1.1 compatability
10/17/2002 4:05:47 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: Three quick notes: * We should specifically ask on the user list about the timing of Servlet 2.3 / JSP 1.2 dependence. I would expect this to be a bit controversial on that short a time frame. On the other hand, knowing we could interoperate with (and not just integrate with) JSTL (and JSF when done) would be nice. -0 I would be concerned about letting that genie out of the bottle until we have a specific usecase for 2.3/1.2. I think focusing on interoperating with JSTL/JSF in 1.2.x but integrating itfor the 2.0.x series, which seems like a fair plan to me. With the platform change, both codebases could proceed simulatneously, so 2.0.x would not have to wait for 1.2.x. If during implementation, 2.3/1.2 support becomes irresistiable for specific reasons, then we can ask around. * If the STXX folks are still interested, I'd like to see more formal support for XML processing pipelines be included in a 1.2 time frame. This will help people who want to leverage Struts in a web services hype world, as well as being generally useful. +1 * I'd defer a decision on whether Struts 2.0 advances to Servlet 2.4 and JSP 2.0 or not for a while yet -- to me, it really depends on the adoption rate for J2EE 1.4 and the availability of products that run it. From the Struts perspective, Servlet 2.3-2.4 doesn't buy a lot, but the JSP 1.2-2.0 changes are going to be very very useful. +1 -T. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
10/17/2002 2:28:38 PM, Eddie Bush [EMAIL PROTECTED] wrote: The sharing is the thing we're struggling with - more precisely the timing of implementing it. It has been suggested this would happen in 1.2, and I think that's acceptable. Whether and when something happens will always depend on whether someone *makes* it happen. As individuals, each of us can say that we plan to work on this or that in some timeframe, but I don't think anyone can foresee what feature will appear in what release until there is code on the table. We can slot the platform requirements for a given code tree (1.2.x vs 2.0.x), but what ends up being implemented will really depends on who has time to do what. The roadmap is a useful tool, but let's not start thinking of it like some type of requirements document. We all have enough of that at our real jobs. Here, we should be doing what we ~want~ to do, not simply what got put up on the whiteboard. -Ted. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
I'll add that to my in my copious free time list :)) But seriously, one of these days I will, and I will have an example application for folks to download as well at some point in the next months timeframe that will illustrate this. I might even have a go at making the struts-documentation.war example have an embedded Lucene index and search interface :) Erik Ted Husted wrote: Erik, If you'd like to write a section for the UserGuide on using XDoclet with Struts, I'm sure we'd all love to read it =:0) -Ted. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Exactly. Though, hopefully, we each will do some things not just because it's a need *we* have. It's only understandable we'd scratch our own itch first, but, provided we have time to implement additional things, I like to think we would do that too. (but remember - we have families we like to see too, and we don't get paid to do this!) Ted Husted wrote: 10/17/2002 2:28:38 PM, Eddie Bush [EMAIL PROTECTED] wrote: The sharing is the thing we're struggling with - more precisely the timing of implementing it. It has been suggested this would happen in 1.2, and I think that's acceptable. Whether and when something happens will always depend on whether someone *makes* it happen. As individuals, each of us can say that we plan to work on this or that in some timeframe, but I don't think anyone can foresee what feature will appear in what release until there is code on the table. We can slot the platform requirements for a given code tree (1.2.x vs 2.0.x), but what ends up being implemented will really depends on who has time to do what. The roadmap is a useful tool, but let's not start thinking of it like some type of requirements document. We all have enough of that at our real jobs. Here, we should be doing what we ~want~ to do, not simply what got put up on the whiteboard. -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
I think what we established for a roadmap yesterday seperated the 2.3 compliance conversion out into something past 1.2. There are a number of things that aren't going to meet everyone's approval wrt 1.1F. Those things, and only those things, as I understand it, would be in 1.2. We need to clean up before we make another mess :-) Craig mentioned lumping the 2.3 compliance conversion and JSF into one release - probably 2.0. Find his bucket post from yesterday :-) So far as servlet spec 2.4 is concerned, I have no clue. What platform will our users be on? We don't want to upgrade ourselves out of a user-base. Yes, many of us will be able to switch - but there will be many forced to stay on 2.3 spec containers too - just like a lot of folks are stuck on 2.2 spec containers now. I don't have awareness enough of what everyone's flexibility is like wrt switching containers to have input on this really though. I would very much like to see David's work incorporated as a first-class citizen. I can't say how handy I find that set of tools! Anyone that has used them understands - anyone who hasn't doesn't. So far as Validator/Tiles are concerned, they will be there in 1.1F, if I have any say about it (speaking with my code, as Ted suggested!). Validator, I believe, is there. If you experience problems with it's module-friendliness just yell. That's mine. I intend to have to fix anything I missed or messed up. I don't think there will be problems with it in that regard though ;-) My suggested order of operation would be: 1.1F - finish what we're doing 1.2 - clean-up wrt modules ... and after that - whatever. It's very important that we clean up our mess though. While I don't anticipate the code-base to change much in 1.2, I do expect to see a lot more functionality in it. Byrne, Steven wrote: What are people's feelings about supporting Servlet 2.2 in post 1.1? Is it time that we can say in 1.2 and beyond that servlet 2.3 is required? I was thinking about the roadmap, and realizing that while a Struts version that was JSF aware was probably a ways off, a version with JSTL incorporated into it (and here I'm thinking about Mr. Karr's work) as a first class citizen would not be as far off, and we may not want to hold up incorporating that technology waiting for JSF integration. That makes me think that it would be a good thing to say that in 1.2 Servlet 2.3 is required. Remember, 1.2 will be a few months out from now, so it doesn't seem that at that time 2.3/JSP 1.2 would be that bad of a thing to say is the lower end of what is supported? Comments? I'm going to write up a draft roadmap tomorrow and send it around for comments. If you want to provide input into it, please speak up now so I can incorporate your ideas. Right now I can think of two basic buckets: 1.2 Servlet 2.3 / JSP 1.2 based (assuming no objections JSTL tag library incorporated as a first class citizen Support for distributed struts components within a single application (either by just having a list of them or by using some assembling technology) 1.1 bugs fixes 2.0 Servlet 2.4 based (?) JSF integration This presumes that 1.1 has Tiles and Validator in place as first class citizens and working properly with sub applications. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Steve :-) I appreciate your effort, but we're *not* going to 2.3 / 1.2 in Struts 1.2! 1.2 is for clean-up only - to solidify modules. One of the goals of 1.2 is still *backward-compatability* with 1.0! We cannot move to 2.3 / 1.2 and maintain this! Byrne, Steven wrote: I was given to understand that Struts-el needed Servlet 2.3, and so that's why I suggested having it in 1.2. But my main purpose was to create a common definition of what was going to be in each release (and have it track as things change), so it should reflect the shared belief of the developers. David Karr -- care to chime in on whether Struts-el needs Servlet 2.3/JSP 1.2? Steve -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Yeah - what he said ;-) Ted Husted wrote: I like Craig's idea of slotting 2.3/1.2 for 2.0.x for now. Let's do some actually work on 1.2.x before committing to a requirements change. If we start to feel hamstrung, we can decide that based on a specific need (keep it agile). -Ted. 10/16/2002 8:06:58 PM, Byrne, Steven [EMAIL PROTECTED] wrote: What are people's feelings about supporting Servlet 2.2 in post 1.1? Is it time that we can say in 1.2 and beyond that servlet 2.3 is required? -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Looks good. Ted Husted wrote: I posted a starter version of the roadmap so we'd have something to patch :0) http://jakarta.apache.org/struts/status.html -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: RE: Tiles Refactorings for 1.1 compatability
I posted a starter version of the roadmap so we'd have something to patch :0)
http://jakarta.apache.org/struts/status.html
-Ted.
10/16/2002 4:42:10 PM, Byrne, Steven [EMAIL PROTECTED] wrote:
Definitely a big part of what 1.1 is all about is integrating Tiles and
Validator into the main Struts distribution. Pulling them back into
pseudo-contrib status would not be a good thing.
Has anyone estimated the level of effort to make each of them be sub-app
aware? I imagine it's non-trival, but not overly large. And, since we
have new, eager, smart committers with plenty of energy and motivation,
I would think that these changes could be done in a reasonable
timeframe, perhaps with a little guidance from the original authors of
the respective components.
Steve
-Original Message-
From: David Graham [mailto:dgraham1980;hotmail.com]
Sent: Wednesday, October 16, 2002 1:27 PM
To: [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
To me, validator and tiles are part of the core. Without
them, struts loses
much of its utility and importance.
David
From: Joe Germuska [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED],
'[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
Date: Wed, 16 Oct 2002 14:54:18 -0500
At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:
Now that we have modules in play, would anyone VETO adding
the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that
everyone is
waiting for a final release of? I'd have to seriously consider it.
Would it seriously mess up the current release cycle to
decouple Tiles and
Validator from the core as an attempt to simplify the 1.1
release? It
seems like there needs to be a middle-ground between the
contrib folder
and the core where useful tools can be developed and
released without
interfering with the core.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes
get glazed,
they go white, their hands tremble As I watch them I
often feel that a
dope peddler is a gentleman compared with the man who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-dev-help;jakarta.apache.org
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--
To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Peter A. J. Pilgrim wrote: As a core contributor for Expresso Framework I find this discussion interesting. In Expresso one of the contributors put together a XML Augmentator that parse several XML configuration files. We integrated Struts 1.0.2 so we do not have a special notation of sub applications, but just the one struts-config file, but we can have several *expresso-struts-config* files. If the expresso-strut config implement the same XML DTD then in theory they can merged together internally in a giant DOM. This is what I think the contribotor ( Mike Rimov, I think) did for Expresso. I am not sure how it solves the modules problem though in pure Struts. I have a little difficult understanding the terminology here. Is a module the same as a subapplication? Yes. I am not sure who started that nomenclature, but I find it more intuative. Plus - sub-apps implies there is a super-app ;-) and there isn't. I can see a might have a little bit work ahead of me, when I start trying to integrate Struts 1.1 with the latest Expresso if I do not under all the sub application issues. For Expresso it will make sense to subapplications to know about the default application (which is in our case Expresso). A sub application should be able to find out about sub applications also loading into the system. But hey may be I am way of base here. TRYING TO KEEP TEXT SHORT, TOO MUCH STRAIN ON MY EYES. You may wait to see what's in 1.2 before you try to incorporate a newer release. I can't say exactly what it will look like, but modules are anticipated to be somewhat more knowledgable about one another in that release. 1.1 is, as Ted noted Wall of China seperatism. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
I don't think anyone is trying to say that Struts isn't useful without Tiles/Validator. They *are* very handy though, IMHO! I'm not sure what our leadership has in mind for deprecating/removing Tiles/Validator in later releases. Right now, the task at hand is 1.1F. As Ted mentioned, ... the die is cast We just need to execute and deliver. Joe Germuska wrote: At 2:26 PM -0600 2002/10/16, David Graham wrote: To me, validator and tiles are part of the core. Without them, struts loses much of its utility and importance. I think that's a bit extreme. Action classes are part of the core; RequestProcessor is part of the core. I've built several Struts apps and barely touched either Tiles or Validator, and haven't missed them. Furthermore, Validator will be mostly obsoleted by Java Server Faces. If committers think it's best to keep them in the core distribution, I'm not going to make a fuss about it. But I think it's selling Struts very short to suggest that it's not very useful or important if you aren't using Validator or Tiles. And if decoupling useful components from a core distribution helps maintain focus and cut a 1.1 release, I would think there's something to be said for that. Joe -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Thursday, October 17, 2002 9:10 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Ted Husted wrote: I posted a starter version of the roadmap so we'd have something to patch :0) http://jakarta.apache.org/struts/status.html -Ted. Just so I understand, is there a desire to not have Struts-EL in the 1.1 release? I know this document is extremely preliminary, but the omission of it from the phrase about contrib libraries makes me think that's the intent. If that's the case, I take no offense, I just want to be clear on our direction. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Actually, looking back at that, I think I disagree with postponing Tiles' update to 1.2. I love the idea of having a roadmap up though ;-) Ted Husted wrote: I posted a starter version of the roadmap so we'd have something to patch :0) http://jakarta.apache.org/struts/status.html -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Eddie Bush wrote: Peter A. J. Pilgrim wrote: As a core contributor for Expresso Framework I find this discussion interesting. --SNIP-- Yes. I am not sure who started that nomenclature, but I find it more intuative. Plus - sub-apps implies there is a super-app ;-) and there isn't. --SNIP For Expresso it will make sense to subapplications to know about the default application (which is in our case Expresso). A sub application should be able to find out about sub applications also loading into the system. But hey may be You may wait to see what's in 1.2 before you try to incorporate a newer release. I can't say exactly what it will look like, but modules are anticipated to be somewhat more knowledgable about one another in that release. 1.1 is, as Ted noted Wall of China seperatism. There are other stuff in 1.1 which make it worth of upgrading. DynaFormBeans for one. Message Exceptions. Validator Frameworks etc. The confusion in ``Modules'' (subapps) is the namespace and location of modules if there are ever extended to nested Modules, and whether Modules can share application configuration messages and actions. -- Peter Pilgrim ServerSide Java Specialist My on-line resume and for interview videos about myself, J2EE Open Source, Struts and Expresso. || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Peter A. J. Pilgrim wrote: Eddie Bush wrote: Peter A. J. Pilgrim wrote: As a core contributor for Expresso Framework I find this discussion interesting. --SNIP-- Yes. I am not sure who started that nomenclature, but I find it more intuative. Plus - sub-apps implies there is a super-app ;-) and there isn't. --SNIP For Expresso it will make sense to subapplications to know about the default application (which is in our case Expresso). A sub application should be able to find out about sub applications also loading into the system. But hey may be You may wait to see what's in 1.2 before you try to incorporate a newer release. I can't say exactly what it will look like, but modules are anticipated to be somewhat more knowledgable about one another in that release. 1.1 is, as Ted noted Wall of China seperatism. There are other stuff in 1.1 which make it worth of upgrading. DynaFormBeans for one. Message Exceptions. Validator Frameworks etc. The confusion in ``Modules'' (subapps) is the namespace and location of modules if there are ever extended to nested Modules, and whether Modules can share application configuration messages and actions. ... and that will be addressed incrementally in 1.2.x -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Multiple struts config files (was RE: Tiles Refactorings for 1.1 compatability)
I would be very interested to hear more. I think the huge configuration files are one of the major problem in using Struts for large projects. Tal Lev-Ami Trivnet Ltd. -Original Message- From: Byrne, Steven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 11:01 PM To: Struts Developers List Subject: Multiple struts config files (was RE: Tiles Refactorings for 1.1 compatability) I developed a system that handles the need for having multiple components of a Struts application (Struts, Tiles, Validator, etc) partitioned in a modular fashion, so that independent groups could work on their component parts without having to worry about what other groups were doing, and yet allow for seamless integration of these components at web application assembly time. It was a requirement that all of this be done without requiring modification to Struts proper, so this is an approach that can be layered on top of a basic Struts implementation. I had wanted to bring this up a week or so ago when Eddie was talking about this topic, but was too busy then. The basic approach is to define a mechanism which allows module authors to work on individual modules using fragments which are then assembled into the final Struts files by Ant. The fragments are XML files which are essentially well-formed versions of the corresponding Struts files. The Ant process uses some style sheet tricks to collect the set of fragments, coalesce the relevant portions of the files into the proper sections (action-mappings, form-beans, etc) in the target XML files (mostly struts-config.xml needed this coalescing). Identifier collisions were avoided by a identifier prefixing scheme where each module would have it's own prefix. If there's interest in examining this approach, I can go into more detail about its operation. It worked well for us, and seems to fit the bill for a way to address the need for modular but not totally independent web applications. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Erik, If you'd like to write a section for the UserGuide on using XDoclet with Struts, I'm sure we'd all love to read it =:0) -Ted. 10/16/2002 8:00:00 PM, Erik Hatcher [EMAIL PROTECTED] wrote: Ted Husted wrote: Using the same element name more than once is really only the tip of the iceberg. We can also delete or rename a form bean from the file and Struts will not catch the problem until runtime. Not in my system! :) XDoclet to the rescue. Form bean definitions are generated completely - move a class to a different package, delete it, rename it, no problem. Heck, we can set validate to true and omit the input property and not catch the problem until validate actually fails. Now this is a problem. Or now specify an input forward that doesn't exist. Again, a problem. We can also specify entries from the Application Resources that don't exist Using my DbResources, this is not a problem per se. No crash, only the resource string returned is the config/locale/key combination requested giving a very visual indication that something is missing. , or ask Actions to find forwards that can't be found. Again, a problem. And this one could be very tough to find with a tool, but Cactus tests (using StrutsTestCase) find these easily. Forms can specify formbean properties that don't exist, True. But we have a starter JSP generator that generates the fields from a form bean using XDoclet. So that issue doesn't crop up until we add a field later, but the problem is minimized. ActionMappings can specify classes that don't exist, and so on. XDoclet *could* take care of this, but I choose not to codify action mappings with @tags, but do it separately. I agree that it would be a Good Thing if someone were to write a utility that vetted the configuration to be sure all the references resolved, but doing a proper job with something like this sounds like a task for 1.1 +. If we ever got into a situation where these problems cropped up often, I'd build something to catch them, but I've not found these to be much of a problem using XDoclet for some of the dirty work, as well as other tricks. Erik p.s. on the topic of Validator - its working nicely for us. We end up writing some custom validations, but for the most part we've not had any problems with it. I saw earlier that the DTD issue I encountered has been fixed - but I worked around it with XDoclet's generation of validation.xml by omitting the DTD from the output. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: RE: Tiles Refactorings for 1.1 compatability
I like Craig's idea of slotting 2.3/1.2 for 2.0.x for now. Let's do some actually work on 1.2.x before committing to a requirements change. If we start to feel hamstrung, we can decide that based on a specific need (keep it agile). -Ted. 10/16/2002 8:06:58 PM, Byrne, Steven [EMAIL PROTECTED] wrote: What are people's feelings about supporting Servlet 2.2 in post 1.1? Is it time that we can say in 1.2 and beyond that servlet 2.3 is required? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
No reason, I think we (you ;-) ) can close this bug with the proposed solution. For the NoOpAction, we can deprecate it and maybe let it extends the ForwardAction. Cedric Eddie Bush wrote: Yes, I've seen that bug. I'll take a look at it. Does anyone have a valid reason why this shouldn't be done? David Graham wrote: Eddie, Can you take a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12309 It relates to tiles and 1.1. I'd like to get your thoughts on it. Sorry, this didn't really answer your question. Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. What are you thoughts to make Tiles more module aware ? Actually there is one common factory for all modules. It is possible to propose a solution with one factory for each modules, but users often want to have a way to define definitions common to all modules, like the definition defining the site main layout. So we surely need to propose a way to achieve this (common definitions + module definitions). I am open to any suggestion. Cedric Eddie Bush wrote: I've been looking over Tiles - specifically at how to make it be 1.1-compliant wrt modules and not trampling on itself cringe/. After doing some greps here and there to try to figure things out, it occurred to me someone might have a diagram of how things are done. I can read UML fairly well, so that would be ideal. Any UML diagrams of Tiles? Thanks! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Cedric Dumoulin wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. Ok - thanks :-) I had to ask! I think I see where things are happening now. I feel I have a lot better understanding of it. Yesterday was the first time I'd really sat down and tried to make heads or tails of the Tiles source code. What are you thoughts to make Tiles more module aware ? Yes, I think they need to go through that phase with everything else. In fact, I would argue that we won't really know what modules mean until we fix everything to work on that basis. Once we have things cleanly seperated, we can look at how they can be further enhanced by maybe chaining the lookups like I was suggesting earlier - but that's in another release ;-) The worst issue I see in Tiles is that it uses the same key (talking application scope here) to load itself, no matter which module does the loading. With such a scenario, if you have Tiles plugged in to the default module, and also use it in a non-default module, you're going to wind up overwriting your config. Actually there is one common factory for all modules. It is possible to propose a solution with one factory for each modules, but users often want to have a way to define definitions common to all modules, like the definition defining the site main layout. So we surely need to propose a way to achieve this (common definitions + module definitions). I am open to any suggestion. Well, for now, as little as I like the lack of sharing that would exist (sharing between default/non-default modules), I think probably the best thing we could do is get modules cleanly seperated from each other. Since we're still finding our feet with respect to exactly what modules mean to folks (ie how are people *really* going to use them?), I think the best route is to get everything cleanly seperated this round - and save any further enhancement (the sharing) for later. Of course, like yourself, I too am open to suggestions :-) Cedric Eddie Bush wrote: I've been looking over Tiles - specifically at how to make it be 1.1-compliant wrt modules and not trampling on itself cringe/. After doing some greps here and there to try to figure things out, it occurred to me someone might have a diagram of how things are done. I can read UML fairly well, so that would be ideal. Any UML diagrams of Tiles? Thanks! -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Ok. Sorry about dragging my feet - I got ... well, my wife changed my mind about what my evening plans were :-) I'll get that in today at some point. Cedric Dumoulin wrote: No reason, I think we (you ;-) ) can close this bug with the proposed solution. For the NoOpAction, we can deprecate it and maybe let it extends the ForwardAction. Cedric Eddie Bush wrote: Yes, I've seen that bug. I'll take a look at it. Does anyone have a valid reason why this shouldn't be done? David Graham wrote: Eddie, Can you take a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12309 It relates to tiles and 1.1. I'd like to get your thoughts on it. Sorry, this didn't really answer your question. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
I don't see SilverRun JD 1.1 - there's something called ModelSphere. Is that it? I like the idea of letting a tool build diagrams ;-) I snagged the demo of ModelSphere. Robert Leland wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. I used SilverRun JD 1.1 to produce the diagrams. It is a free package, not opensource but free. I have Rational Rose 98, and tried other open source tools but they all were either too slow or very buggy or both. I would be happy to update those documents. I could also check in the configuration file for that project but it is 4 MB. -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Odd - I didn't see it on the products page (overlooked?) but it was on the download page. Unfortunately that is not available in a Linux version. I grabbed it anyhoo - I have a Windoze install too. Eddie Bush wrote: I don't see SilverRun JD 1.1 - there's something called ModelSphere. Is that it? I like the idea of letting a tool build diagrams ;-) I snagged the demo of ModelSphere. Robert Leland wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. I used SilverRun JD 1.1 to produce the diagrams. snip/ -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 7:25 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Cedric Dumoulin wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. Ok - thanks :-) I had to ask! I think I see where things are happening now. I feel I have a lot better understanding of it. Yesterday was the first time I'd really sat down and tried to make heads or tails of the Tiles source code. What are you thoughts to make Tiles more module aware ? Yes, I think they need to go through that phase with everything else. In fact, I would argue that we won't really know what modules mean until we fix everything to work on that basis. Once we have things cleanly seperated, we can look at how they can be further enhanced by maybe chaining the lookups like I was suggesting earlier - but that's in another release ;-) The worst issue I see in Tiles is that it uses the same key (talking application scope here) to load itself, no matter which module does the loading. With such a scenario, if you have Tiles plugged in to the default module, and also use it in a non-default module, you're going to wind up overwriting your config. Urck! (A technical term. :) That's not too cool. Actually there is one common factory for all modules. It is possible to propose a solution with one factory for each modules, but users often want to have a way to define definitions common to all modules, like the definition defining the site main layout. So we surely need to propose a way to achieve this (common definitions + module definitions). I am open to any suggestion. Well, for now, as little as I like the lack of sharing that would exist (sharing between default/non-default modules), I think probably the best thing we could do is get modules cleanly seperated from each other. Since we're still finding our feet with respect to exactly what modules mean to folks (ie how are people *really* going to use them?), I think the best route is to get everything cleanly seperated this round - and save any further enhancement (the sharing) for later. Yes, this is spot on. We need to present a consistent approach across the whole of Struts, for the 1.1 release (well, and later too!). Then we can come back and look at the whole sharing and/or hierarchy thing later. -- Martin Cooper Of course, like yourself, I too am open to suggestions :-) Cedric Eddie Bush wrote: I've been looking over Tiles - specifically at how to make it be 1.1-compliant wrt modules and not trampling on itself cringe/. After doing some greps here and there to try to figure things out, it occurred to me someone might have a diagram of how things are done. I can read UML fairly well, so that would be ideal. Any UML diagrams of Tiles? Thanks! -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
Cactus versions What version of cactus should I be using for the latest Struts source from CVS? do I need to build cactus from source too? -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 12:06 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Odd - I didn't see it on the products page (overlooked?) but it was on the download page. Unfortunately that is not available in a Linux version. I grabbed it anyhoo - I have a Windoze install too. Eddie Bush wrote: I don't see SilverRun JD 1.1 - there's something called ModelSphere. Is that it? I like the idea of letting a tool build diagrams ;-) I snagged the demo of ModelSphere. Robert Leland wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. I used SilverRun JD 1.1 to produce the diagrams. snip/ -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
update:RE: Tiles Refactorings for 1.1 compatability
Let me update this. I am able to get everything running
but I had to add a method to one of the Mock Objects to get the Tests to
build.
cvs update shows I have all the latest struts source.
I had to add in MockkServletContext.java:
a method:
public Set getResourcePaths(){
throw new UnssuportedOperationException();
}
to build the tests. Otherwise the build complains
MockServletContext.java should be abstract
-dh
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:15 PM
To: Struts Developers List
Subject: RE: Tiles Refactorings for 1.1 compatability
Cactus versions
What version of cactus should I be using for the latest Struts source
from CVS?
do I need to build cactus from source too?
-Daniel
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 12:06 PM
To: Struts Developers List
Subject: Re: Tiles Refactorings for 1.1 compatability
Odd - I didn't see it on the products page (overlooked?) but it was on
the download page. Unfortunately that is not available in a Linux
version. I grabbed it anyhoo - I have a Windoze install too.
Eddie Bush wrote:
I don't see SilverRun JD 1.1 - there's something called ModelSphere.
Is that it? I like the idea of letting a tool build diagrams ;-)
I snagged the demo of ModelSphere.
Robert Leland wrote:
There is no up to date UML diagram.
The later one is a not up to date reverse engineering of the tiles
package.
I used SilverRun JD 1.1 to produce the diagrams. snip/
-Rob
--
Eddie Bush
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: update:RE: Tiles Refactorings for 1.1 compatability
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 11:02 AM
To: Struts Developers List
Subject: update:RE: Tiles Refactorings for 1.1 compatability
Let me update this. I am able to get everything running
but I had to add a method to one of the Mock Objects to get
the Tests to
build.
cvs update shows I have all the latest struts source.
I had to add in MockkServletContext.java:
a method:
public Set getResourcePaths(){
throw new UnssuportedOperationException();
}
to build the tests. Otherwise the build complains
MockServletContext.java should be abstract
You must be building against a Servlets 2.3 API. The getResourcePaths()
method is new for Servlets 2.3. If you try building against a Servlets 2.2
API, you shouldn't have any problems.
--
Martin Cooper
-dh
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:15 PM
To: Struts Developers List
Subject: RE: Tiles Refactorings for 1.1 compatability
Cactus versions
What version of cactus should I be using for the latest Struts source
from CVS?
do I need to build cactus from source too?
-Daniel
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 12:06 PM
To: Struts Developers List
Subject: Re: Tiles Refactorings for 1.1 compatability
Odd - I didn't see it on the products page (overlooked?)
but it was on
the download page. Unfortunately that is not available in a Linux
version. I grabbed it anyhoo - I have a Windoze install too.
Eddie Bush wrote:
I don't see SilverRun JD 1.1 - there's something called ModelSphere.
Is that it? I like the idea of letting a tool build diagrams ;-)
I snagged the demo of ModelSphere.
Robert Leland wrote:
There is no up to date UML diagram.
The later one is a not up to date reverse engineering of
the tiles
package.
I used SilverRun JD 1.1 to produce the diagrams. snip/
-Rob
--
Eddie Bush
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: update:RE: Tiles Refactorings for 1.1 compatability
Thanks!
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 2:10 PM
To: 'Struts Developers List'
Subject: RE: update:RE: Tiles Refactorings for 1.1 compatability
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 11:02 AM
To: Struts Developers List
Subject: update:RE: Tiles Refactorings for 1.1 compatability
Let me update this. I am able to get everything running
but I had to add a method to one of the Mock Objects to get
the Tests to
build.
cvs update shows I have all the latest struts source.
I had to add in MockkServletContext.java:
a method:
public Set getResourcePaths(){
throw new UnssuportedOperationException();
}
to build the tests. Otherwise the build complains
MockServletContext.java should be abstract
You must be building against a Servlets 2.3 API. The getResourcePaths()
method is new for Servlets 2.3. If you try building against a Servlets 2.2
API, you shouldn't have any problems.
--
Martin Cooper
-dh
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:15 PM
To: Struts Developers List
Subject: RE: Tiles Refactorings for 1.1 compatability
Cactus versions
What version of cactus should I be using for the latest Struts source
from CVS?
do I need to build cactus from source too?
-Daniel
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 12:06 PM
To: Struts Developers List
Subject: Re: Tiles Refactorings for 1.1 compatability
Odd - I didn't see it on the products page (overlooked?)
but it was on
the download page. Unfortunately that is not available in a Linux
version. I grabbed it anyhoo - I have a Windoze install too.
Eddie Bush wrote:
I don't see SilverRun JD 1.1 - there's something called ModelSphere.
Is that it? I like the idea of letting a tool build diagrams ;-)
I snagged the demo of ModelSphere.
Robert Leland wrote:
There is no up to date UML diagram.
The later one is a not up to date reverse engineering of
the tiles
package.
I used SilverRun JD 1.1 to produce the diagrams. snip/
-Rob
--
Eddie Bush
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Ted Husted wrote: From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. Yes - saw that coming. I want to share too, but is it appropriate to do so now and skip the seperatism phase? If each module is, in fact, it's own little world, then that should apply to everything. This goes along with previous arguments I've voiced and been told post 1.1 on. Would it be best to, as I suggested, have Tiles be stupid this release (no chaining/sharing), and then refactor for sharing once we have a better idea of how sub-apps will be used? I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. :-/ Well, there's nothing to stop you from referencing the same physical pages that I can think of - but the definitions would be duplicated I suppose. This could be solved by the same concatenation tricks used for previous versions of Struts. I know it's not ideal - but I don't think 1.1F *is* going to be (IMHO - because of the way I feel they should be implemented) ideal. 1.1.1 or 1.2 - that's where we'll whip it into shape. Is this not the direction we are headed? If not, I'd like to know now. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. Yeah - maybe so. You know (I think) where I stand on the duplication. I don't like it either. The idea I've had impressed upon me (by both Martin and Craig, I believe) is that we should implement 1.1 with each module being in it's own little world - and then follow up with discussions on how we can make them work more ideally. That is the exact impression guiding what I am doing to fix things that are not 1.1 compliant. No matter what we do in the future, we need to have each module not being trampled on by the others, so refactoring to allow each app the ability to use a plugin without affecting the others is (I think) a necessary step. Whether we go one further and implement chaining is an option I would certainly be open to, but I was under the impression this shouldn't be done until later (post 1.1). I hope others will share their feelings. Bear in mind there are folks looking heavily at 1.1 that can't use it because of it's beta status. It's a time/feature trade-off :-) I don't see it being necessary to rework the config instantiation/acquisition beyond 1.1. The thing that will have to change is how the lookups are done. I really think we can break these out into two releases without having to do rework, if that is the way it needs to go. We could go ahead and refactor the lookups now too, if that's the appropriate course, but there's obviously going to be additional delay for doing so. Do we need a proposal maybe? -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
10/16/2002 2:43:57 PM, Eddie Bush [EMAIL PROTECTED] wrote: Do we need a proposal maybe? As a rule, we propose through code, since that's all we can really vote on anyway =:0) My only point is that if I patch the controller to support a delimited list of struts-configs, as we do with Tiles and the Validator, then we have the choice between the Chinese wall approach to modules, or just diving up elements between multiple files. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 11:23 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Would I veto adding new functionality in a second beta that everyone is waiting for a final release of? I'd have to seriously consider it. -- Martin Cooper Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
10/16/2002 2:43:57 PM, Eddie Bush [EMAIL PROTECTED] wrote: :-/ Well, there's nothing to stop you from referencing the same physical pages that I can think of - but the definitions would be duplicated I suppose. This could be solved by the same concatenation tricks used for previous versions of Struts. I believe that, by default, the application-relative paths would become module-relative paths, and I wouldn't be able to refer to a file outside of the module. The definitions essentially act as ActionForwards, so we might want the same type of contextRelative switch for the Tiles path attributes that we have the for ActionForward path attribute. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Modules in Struts 1.1 (was RE: Tiles Refactorings for 1.1 compatability)
On Wed, 16 Oct 2002, Martin Cooper wrote: Date: Wed, 16 Oct 2002 12:36:34 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: Modules in Struts 1.1 (was RE: Tiles Refactorings for 1.1 compata bility) What Eddie said (mostly). ;-) We've gone most of the way down the road with modules the way Craig originally envisioned them, and we're almost there. There are just a few more cleanup tasks to go, such as fixing Tiles to not trip over itself. I would really like to see us finish what we've started, as soon as we can, and then go back and look at the sharing thing once 1.1 is final. Maybe that comes in a 1.2 that doesn't take us so long to complete as 1.1 has taken us. But let's not try to squeeze it in to 1.1, and perhaps later regret that we didn't think through all the issues. +1. I was about to write something pretty similar. -- Martin Cooper Craig -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 11:44 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Ted Husted wrote: From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. Yes - saw that coming. I want to share too, but is it appropriate to do so now and skip the seperatism phase? If each module is, in fact, it's own little world, then that should apply to everything. This goes along with previous arguments I've voiced and been told post 1.1 on. Would it be best to, as I suggested, have Tiles be stupid this release (no chaining/sharing), and then refactor for sharing once we have a better idea of how sub-apps will be used? I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. :-/ Well, there's nothing to stop you from referencing the same physical pages that I can think of - but the definitions would be duplicated I suppose. This could be solved by the same concatenation tricks used for previous versions of Struts. I know it's not ideal - but I don't think 1.1F *is* going to be (IMHO - because of the way I feel they should be implemented) ideal. 1.1.1 or 1.2 - that's where we'll whip it into shape. Is this not the direction we are headed? If not, I'd like to know now. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. Yeah - maybe so. You know (I think) where I stand on the duplication. I don't like it either. The idea I've had impressed upon me (by both Martin and Craig, I believe) is that we should implement 1.1 with each module being in it's own little world - and then follow up with discussions on how we can make them work more ideally. That is the exact impression guiding what I am doing to fix things that are not 1.1 compliant. No matter what we do in the future, we need to have each module not being trampled on by the others, so refactoring to allow each app the ability to use a plugin without affecting the others is (I think) a necessary step. Whether we go one further and implement chaining is an option I would certainly be open to, but I was under the impression this shouldn't be done until later (post 1.1). I hope others will share their feelings. Bear in mind there are folks looking heavily at 1.1 that can't use it because of it's beta status. It's a time/feature trade-off :-) I don't see it being necessary
Re: Modules in Struts 1.1 (was RE: Tiles Refactorings for 1.1 compatability)
Thank God someone has started throwing their votes around. Hop on the other thread please, Craig. I'd like to have everything in one spot. Craig R. McClanahan wrote: On Wed, 16 Oct 2002, Martin Cooper wrote: Date: Wed, 16 Oct 2002 12:36:34 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: Modules in Struts 1.1 (was RE: Tiles Refactorings for 1.1 compata bility) What Eddie said (mostly). ;-) We've gone most of the way down the road with modules the way Craig originally envisioned them, and we're almost there. There are just a few more cleanup tasks to go, such as fixing Tiles to not trip over itself. I would really like to see us finish what we've started, as soon as we can, and then go back and look at the sharing thing once 1.1 is final. Maybe that comes in a 1.2 that doesn't take us so long to complete as 1.1 has taken us. But let's not try to squeeze it in to 1.1, and perhaps later regret that we didn't think through all the issues. +1. I was about to write something pretty similar. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:
Now that we have modules in play, would anyone VETO adding
the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that everyone is
waiting for a final release of? I'd have to seriously consider it.
Would it seriously mess up the current release cycle to decouple
Tiles and Validator from the core as an attempt to simplify the 1.1
release? It seems like there needs to be a middle-ground between
the contrib folder and the core where useful tools can be developed
and released without interfering with the core.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
+1 by a non committee on M.C. vetoing new features. Can you wait till 1.2 Ted? .V Martin Cooper wrote: -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 11:23 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Would I veto adding new functionality in a second beta that everyone is waiting for a final release of? I'd have to seriously consider it. -- Martin Cooper Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
To me, validator and tiles are part of the core. Without them, struts loses
much of its utility and importance.
David
From: Joe Germuska [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED],
'[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
Date: Wed, 16 Oct 2002 14:54:18 -0500
At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:
Now that we have modules in play, would anyone VETO adding
the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that everyone is
waiting for a final release of? I'd have to seriously consider it.
Would it seriously mess up the current release cycle to decouple Tiles and
Validator from the core as an attempt to simplify the 1.1 release? It
seems like there needs to be a middle-ground between the contrib folder
and the core where useful tools can be developed and released without
interfering with the core.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get glazed,
they go white, their hands tremble As I watch them I often feel that a
dope peddler is a gentleman compared with the man who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. The only other thing I meant to say is that if we're going to call Tiles 1.1 compliant, it should have the same contextRelative property we see on the ActionForward. I didn't mean to say that there should be a gobal Tiles config or anything like that. In both cases, I'm just saying we should consistently complete what we started. Beta are for finding oversights and inconsistencies as well as malfunctions. But if everyone is on board for cutting a quick 1.2 release to catch issues we are postponing now, I'm willing to play along (again). My only concern is that post 1.1, we will also want to talk about things like servlet 2.3 support. My concern is that those discussions might become an excuse to postpone finishing what we (only) started here. But with more committers on board, perhaps we can afford to work on more than one code stream now. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
Definitely a big part of what 1.1 is all about is integrating Tiles and
Validator into the main Struts distribution. Pulling them back into
pseudo-contrib status would not be a good thing.
Has anyone estimated the level of effort to make each of them be sub-app
aware? I imagine it's non-trival, but not overly large. And, since we
have new, eager, smart committers with plenty of energy and motivation,
I would think that these changes could be done in a reasonable
timeframe, perhaps with a little guidance from the original authors of
the respective components.
Steve
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:27 PM
To: [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
To me, validator and tiles are part of the core. Without
them, struts loses
much of its utility and importance.
David
From: Joe Germuska [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED],
'[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
Date: Wed, 16 Oct 2002 14:54:18 -0500
At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:
Now that we have modules in play, would anyone VETO adding
the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that
everyone is
waiting for a final release of? I'd have to seriously consider it.
Would it seriously mess up the current release cycle to
decouple Tiles and
Validator from the core as an attempt to simplify the 1.1
release? It
seems like there needs to be a middle-ground between the
contrib folder
and the core where useful tools can be developed and
released without
interfering with the core.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes
get glazed,
they go white, their hands tremble As I watch them I
often feel that a
dope peddler is a gentleman compared with the man who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
I would think that before Ted or anyone can answer the question of whether to wait until 1.2, a clear roadmap of near term future releases, including features and functionality lists for each release, be published. Right now, saying that it's ok to wait until 1.2 is pretty much meaningless without a time estimate based on the amount of content going into 1.2 (or even a definition of what 1.2 is). When I talked with Craig a few months back, he was thinking that the next release of Struts would be focused on incorporating JSF related functionality; I don't know if that's still the case. If it is, that would make for a much more significantly challenging release, and thus would extend the time that people would have to wait for a fully working tiles/validator version of Struts. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. The only other thing I meant to say is that if we're going to call Tiles 1.1 compliant, it should have the same contextRelative property we see on the ActionForward. I didn't mean to say that there should be a gobal Tiles config or anything like that. In both cases, I'm just saying we should consistently complete what we started. Beta are for finding oversights and inconsistencies as well as malfunctions. But if everyone is on board for cutting a quick 1.2 release to catch issues we are postponing now, I'm willing to play along (again). My only concern is that post 1.1, we will also want to talk about things like servlet 2.3 support. My concern is that those discussions might become an excuse to postpone finishing what we (only) started here. But with more committers on board, perhaps we can afford to work on more than one code stream now. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Multiple struts config files (was RE: Tiles Refactorings for 1.1 compatability)
I developed a system that handles the need for having multiple components of a Struts application (Struts, Tiles, Validator, etc) partitioned in a modular fashion, so that independent groups could work on their component parts without having to worry about what other groups were doing, and yet allow for seamless integration of these components at web application assembly time. It was a requirement that all of this be done without requiring modification to Struts proper, so this is an approach that can be layered on top of a basic Struts implementation. I had wanted to bring this up a week or so ago when Eddie was talking about this topic, but was too busy then. The basic approach is to define a mechanism which allows module authors to work on individual modules using fragments which are then assembled into the final Struts files by Ant. The fragments are XML files which are essentially well-formed versions of the corresponding Struts files. The Ant process uses some style sheet tricks to collect the set of fragments, coalesce the relevant portions of the files into the proper sections (action-mappings, form-beans, etc) in the target XML files (mostly struts-config.xml needed this coalescing). Identifier collisions were avoided by a identifier prefixing scheme where each module would have it's own prefix. If there's interest in examining this approach, I can go into more detail about its operation. It worked well for us, and seems to fit the bill for a way to address the need for modular but not totally independent web applications. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Just of the box... Ted, others, what if we just delayed subapps till after?
.V
Byrne, Steven wrote:
Definitely a big part of what 1.1 is all about is integrating Tiles and
Validator into the main Struts distribution. Pulling them back into
pseudo-contrib status would not be a good thing.
Has anyone estimated the level of effort to make each of them be sub-app
aware? I imagine it's non-trival, but not overly large. And, since we
have new, eager, smart committers with plenty of energy and motivation,
I would think that these changes could be done in a reasonable
timeframe, perhaps with a little guidance from the original authors of
the respective components.
Steve
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:27 PM
To: [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
To me, validator and tiles are part of the core. Without
them, struts loses
much of its utility and importance.
David
From: Joe Germuska [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED],
'[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
Date: Wed, 16 Oct 2002 14:54:18 -0500
At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:
Now that we have modules in play, would anyone VETO adding
the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that
everyone is
waiting for a final release of? I'd have to seriously consider it.
Would it seriously mess up the current release cycle to
decouple Tiles and
Validator from the core as an attempt to simplify the 1.1
release? It
seems like there needs to be a middle-ground between the
contrib folder
and the core where useful tools can be developed and
released without
interfering with the core.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes
get glazed,
they go white, their hands tremble As I watch them I
often feel that a
dope peddler is a gentleman compared with the man who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
I think I like your intent, but I fail to see how this would accomplish it. Ted Husted wrote: 10/16/2002 2:43:57 PM, Eddie Bush [EMAIL PROTECTED] wrote: Do we need a proposal maybe? As a rule, we propose through code, since that's all we can really vote on anyway =:0) My only point is that if I patch the controller to support a delimited list of struts-configs, as we do with Tiles and the Validator, then we have the choice between the Chinese wall approach to modules, or just diving up elements between multiple files. -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
JSF is still a moving target, isn't it? Assuming we get the current outstanding issues cleared and cut 1.1F in a reasonable time-frame (tbd), I really don't think it would take long to implement the additional changes required to make modules communicate. It's really an insignificant change the way I view it right now. Maybe I'm being short-sighted. Byrne, Steven wrote: I would think that before Ted or anyone can answer the question of whether to wait until 1.2, a clear roadmap of near term future releases, including features and functionality lists for each release, be published. Right now, saying that it's ok to wait until 1.2 is pretty much meaningless without a time estimate based on the amount of content going into 1.2 (or even a definition of what 1.2 is). When I talked with Craig a few months back, he was thinking that the next release of Struts would be focused on incorporating JSF related functionality; I don't know if that's still the case. If it is, that would make for a much more significantly challenging release, and thus would extend the time that people would have to wait for a fully working tiles/validator version of Struts. Steve -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Multiple struts config files (was RE: Tiles Refactorings for 1.1 compatability)
+1 Choice is good, and this sounds like something we could offer through the Contrib folder or on Struts Sourceforge. 10/16/2002 5:00:58 PM, Byrne, Steven [EMAIL PROTECTED] wrote: I developed a system that handles the need for having multiple components of a Struts application (Struts, Tiles, Validator, etc) partitioned in a modular fashion, so that independent groups could work on their component parts without having to worry about what other groups were doing, and yet allow for seamless integration of these components at web application assembly time. It was a requirement that all of this be done without requiring modification to Struts proper, so this is an approach that can be layered on top of a basic Struts implementation. I had wanted to bring this up a week or so ago when Eddie was talking about this topic, but was too busy then. The basic approach is to define a mechanism which allows module authors to work on individual modules using fragments which are then assembled into the final Struts files by Ant. The fragments are XML files which are essentially well-formed versions of the corresponding Struts files. The Ant process uses some style sheet tricks to collect the set of fragments, coalesce the relevant portions of the files into the proper sections (action-mappings, form-beans, etc) in the target XML files (mostly struts-config.xml needed this coalescing). Identifier collisions were avoided by a identifier prefixing scheme where each module would have it's own prefix. If there's interest in examining this approach, I can go into more detail about its operation. It worked well for us, and seems to fit the bill for a way to address the need for modular but not totally independent web applications. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: Tiles Refactorings for 1.1 compatability
If Steve, or anyone else, would like to start putting together a roadmap for Struts 1.1, 1.2, and 1.2+ (formerly 1.1+), I'll be happy to post it on the site and maintain it. It doesn't have too be XML, I can take it off the list if that's what it takes. -T. 10/16/2002 4:47:29 PM, Byrne, Steven [EMAIL PROTECTED] wrote: I would think that before Ted or anyone can answer the question of whether to wait until 1.2, a clear roadmap of near term future releases, including features and functionality lists for each release, be published. Right now, saying that it's ok to wait until 1.2 is pretty much meaningless without a time estimate based on the amount of content going into 1.2 (or even a definition of what 1.2 is). When I talked with Craig a few months back, he was thinking that the next release of Struts would be focused on incorporating JSF related functionality; I don't know if that's still the case. If it is, that would make for a much more significantly challenging release, and thus would extend the time that people would have to wait for a fully working tiles/validator version of Struts. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. The only other thing I meant to say is that if we're going to call Tiles 1.1 compliant, it should have the same contextRelative property we see on the ActionForward. I didn't mean to say that there should be a gobal Tiles config or anything like that. In both cases, I'm just saying we should consistently complete what we started. Beta are for finding oversights and inconsistencies as well as malfunctions. But if everyone is on board for cutting a quick 1.2 release to catch issues we are postponing now, I'm willing to play along (again). My only concern is that post 1.1, we will also want to talk about things like servlet 2.3 support. My concern is that those discussions might become an excuse to postpone finishing what we (only) started here. But with more committers on board, perhaps we can afford to work on more than one code stream now. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 17:13:19 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 5:01:55 PM, Eddie Bush [EMAIL PROTECTED] wrote: I think it's reasonable we would fix things to be independent now, as Martin and Craig have suggested, and then look at making modules cooperate next. I'm not talking about anyting to do with modules cooperating or not. I'm just saying that the supplemental Struts configuration files (for Validator and Tiles) can be specified as a list, but the main struts-config cannot be. In my experience, many teams just want multiple configuration files, period. This gives people what they want (multiple configs), without giving them something else they might not want (Chinese walls within the application). Don't have time to dive into the substantive technical details today, but in general I'm OK with a strategy of comma-delimited list of struts-config.xml resource files used to configure a single app module (consistent with the Tiles and Validators styles). I presume this just means running as many Digester.parse() calls as you need, and no other fundamental changes, right? Craig Context-relative? Ok, but you have no sharing in that scenario. The contextRelative approach just says interpret this as relative to the application root path - I don't see how that makes sense here, but I'm surely missing something. The purpose of a Tiles Definition is utilimately to include tiles, which means we need to specify a path to the tile. If we can mark some of the paths to be application-relative, then the modules can share tiles. think) what is desirable (what I understood you were after) would be to say oh - this definition extends that one, but *that* one happens to be in a different module. Am I on the wrong page here? I know this is my goal - that's what I'm after. That would be cool, but it doesn't need to be in this release. Both the ActionMappings and the Definitions should support this type of extending in some future release (probably 1.2+). -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: Tiles Refactorings for 1.1 compatability
On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 16:53:48 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: RE: Tiles Refactorings for 1.1 compatability If Steve, or anyone else, would like to start putting together a roadmap for Struts 1.1, 1.2, and 1.2+ (formerly 1.1+), I'll be happy to post it on the site and maintain it. It doesn't have too be XML, I can take it off the list if that's what it takes. IMHO, any rational roadmap for post-1.1 is going to have to lump proposed changes into at least two buckets: * Those that can be implemented on Servlet 2.2 / JSP 1.1, including refactoring of existing functionality (but with a continued emphasis on backwards compatibility). * Those that require updating the minimum platform to Servlet 2.3 / JSP 1.2 (JSTL and JavaServer Faces will both fall into this camp, as would any refactoring that depended on being able to use Filters). My personal interests are in the latter area, but I wouldn't be surprised to see many folks wanting to work on the former. Maybe we can colloquially think about categorizing things in the appropriate buckets, and think about calling them Struts 1.2.x and Struts 2.0.x (with the .x representing milestone releases like Tomcat 4.1 and Apache httpd do it)? -T. Craig 10/16/2002 4:47:29 PM, Byrne, Steven [EMAIL PROTECTED] wrote: I would think that before Ted or anyone can answer the question of whether to wait until 1.2, a clear roadmap of near term future releases, including features and functionality lists for each release, be published. Right now, saying that it's ok to wait until 1.2 is pretty much meaningless without a time estimate based on the amount of content going into 1.2 (or even a definition of what 1.2 is). When I talked with Craig a few months back, he was thinking that the next release of Struts would be focused on incorporating JSF related functionality; I don't know if that's still the case. If it is, that would make for a much more significantly challenging release, and thus would extend the time that people would have to wait for a fully working tiles/validator version of Struts. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. The only other thing I meant to say is that if we're going to call Tiles 1.1 compliant, it should have the same contextRelative property we see on the ActionForward. I didn't mean to say that there should be a gobal Tiles config or anything like that. In both cases, I'm just saying we should consistently complete what we started. Beta are for finding oversights and inconsistencies as well as malfunctions. But if everyone is on board for cutting a quick 1.2 release to catch issues we are postponing now, I'm willing to play along (again). My only concern is that post 1.1, we will also want to talk about things like servlet 2.3 support. My concern is that those discussions might become an excuse to postpone finishing what we (only) started here. But with more committers on board, perhaps we can afford to work on more than one code stream now. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 17:29:35 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 5:22:13 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: Don't have time to dive into the substantive technical details today, but in general I'm OK with a strategy of comma-delimited list of struts-config.xml resource files used to configure a single app module (consistent with the Tiles and Validators styles). I presume this just means running as many Digester.parse() calls as you need, and no other fundamental changes, right? Yes. Sorry if I was obtuse. I really should have just committed the change first, and talked about it afterwards. I guess that why we work by Lazy Consensus =:0) But I'll go ahead and do that next and see if anyone squawks. It's easier to ask for forgiveness than permission :-) -Ted. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 2:13 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 5:01:55 PM, Eddie Bush [EMAIL PROTECTED] wrote: I think it's reasonable we would fix things to be independent now, as Martin and Craig have suggested, and then look at making modules cooperate next. I'm not talking about anyting to do with modules cooperating or not. I'm just saying that the supplemental Struts configuration files (for Validator and Tiles) can be specified as a list, but the main struts-config cannot be. In my experience, many teams just want multiple configuration files, period. This gives people what they want (multiple configs), without giving them something else they might not want (Chinese walls within the application). Well, IMO, the reason Validator does this is more of a workaround than a real solution. The issue is that Struts provides a standard set of validation rules, but the user needs to be able to add their own application specific rules and usage criteria. Again IMO, a better way to solve this kind of problem is to use an 'extends' or 'depends' mechanism to pull one set of criteria in from another. Therefore, personally, I'd prefer not to proliferate the workaround approach across other areas of Struts, and do it the right way instead. -- Martin Cooper Context-relative? Ok, but you have no sharing in that scenario. The contextRelative approach just says interpret this as relative to the application root path - I don't see how that makes sense here, but I'm surely missing something. The purpose of a Tiles Definition is utilimately to include tiles, which means we need to specify a path to the tile. If we can mark some of the paths to be application-relative, then the modules can share tiles. think) what is desirable (what I understood you were after) would be to say oh - this definition extends that one, but *that* one happens to be in a different module. Am I on the wrong page here? I know this is my goal - that's what I'm after. That would be cool, but it doesn't need to be in this release. Both the ActionMappings and the Definitions should support this type of extending in some future release (probably 1.2+). -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Byrne, Steven wrote: Definitely a big part of what 1.1 is all about is integrating Tiles and Validator into the main Struts distribution. Pulling them back into pseudo-contrib status would not be a good thing. Yeah -- I'm -1 taking them out of core too. Has anyone estimated the level of effort to make each of them be sub-app aware? Validator is done. Let me know if there are issues that relate to this (their module-awareness -- I assume you mean the initialization/access are module-friendly. That is done.) This whole stink got raised by me (there goes me putting my stick in motion again!) because I'm embarking on how the same should be done for Tiles. I imagine it's non-trival, but not overly large. And, since we have new, eager, smart committers with plenty of energy and motivation, I would think that these changes could be done in a reasonable timeframe, perhaps with a little guidance from the original authors of the respective components. Yes, I agree - but I think it's necessary that we agree on an implementation. I was hoping we'd all just say make sub-apps stupid this round and we'll give them brains once 1.1 is final. Steve -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 2:22 PM To: Struts Developers List; [EMAIL PROTECTED] Subject: Re: Tiles Refactorings for 1.1 compatability On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 17:13:19 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 5:01:55 PM, Eddie Bush [EMAIL PROTECTED] wrote: I think it's reasonable we would fix things to be independent now, as Martin and Craig have suggested, and then look at making modules cooperate next. I'm not talking about anyting to do with modules cooperating or not. I'm just saying that the supplemental Struts configuration files (for Validator and Tiles) can be specified as a list, but the main struts-config cannot be. In my experience, many teams just want multiple configuration files, period. This gives people what they want (multiple configs), without giving them something else they might not want (Chinese walls within the application). Don't have time to dive into the substantive technical details today, but in general I'm OK with a strategy of comma-delimited list of struts-config.xml resource files used to configure a single app module (consistent with the Tiles and Validators styles). I presume this just means running as many Digester.parse() calls as you need, and no other fundamental changes, right? That's one possibility, but it leaves the door wide open for people to shoot themselves in the foot. Consider a situation with two config files, a.xml and b.xml. Now, a.xml contains an action, actionA, that specifies a form bean named theBean of type FormBeanA, and b.xml contains an action, actionB, that specifies a form bean named theBean of type FormBeanB. If the config entry in web.xml lists a.xml before b.xml, then actionA will fail; in the other order, actionB will fail. An interesting one to debug... At the very least, the config reading code would need to be modified to throw an exception whenever a duplicate entry of any type was encountered. That would alleviate most of the problem, but would still leave the door open for an interesting debugging session if, for example, actionB referenced theBean, but theBean itself was accidentally omitted from b.xml (but still configured through a.xml). -- Martin Cooper Craig Context-relative? Ok, but you have no sharing in that scenario. The contextRelative approach just says interpret this as relative to the application root path - I don't see how that makes sense here, but I'm surely missing something. The purpose of a Tiles Definition is utilimately to include tiles, which means we need to specify a path to the tile. If we can mark some of the paths to be application-relative, then the modules can share tiles. think) what is desirable (what I understood you were after) would be to say oh - this definition extends that one, but *that* one happens to be in a different module. Am I on the wrong page here? I know this is my goal - that's what I'm after. That would be cool, but it doesn't need to be in this release. Both the ActionMappings and the Definitions should support this type of extending in some future release (probably 1.2+). -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
+1 - sounds like a very good solution. Craig R. McClanahan wrote: On Wed, 16 Oct 2002, Ted Husted wrote: From: Ted Husted [EMAIL PROTECTED] If Steve, or anyone else, would like to start putting together a roadmap for Struts 1.1, 1.2, and 1.2+ (formerly 1.1+), I'll be happy to post it on the site and maintain it. It doesn't have too be XML, I can take it off the list if that's what it takes. IMHO, any rational roadmap for post-1.1 is going to have to lump proposed changes into at least two buckets: * Those that can be implemented on Servlet 2.2 / JSP 1.1, including refactoring of existing functionality (but with a continued emphasis on backwards compatibility). * Those that require updating the minimum platform to Servlet 2.3 / JSP 1.2 (JSTL and JavaServer Faces will both fall into this camp, as would any refactoring that depended on being able to use Filters). My personal interests are in the latter area, but I wouldn't be surprised to see many folks wanting to work on the former. Maybe we can colloquially think about categorizing things in the appropriate buckets, and think about calling them Struts 1.2.x and Struts 2.0.x (with the .x representing milestone releases like Tomcat 4.1 and Apache httpd do it)? -T. Craig -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Thanks for your clearification. I think that would be a good solution. I wasn't seeing the trees for the forest :-( Ted Husted wrote: 10/16/2002 5:01:55 PM, Eddie Bush [EMAIL PROTECTED] wrote: I think it's reasonable we would fix things to be independent now, as Martin and Craig have suggested, and then look at making modules cooperate next. I'm not talking about anyting to do with modules cooperating or not. I'm just saying that the supplemental Struts configuration files (for Validator and Tiles) can be specified as a list, but the main struts-config cannot be. In my experience, many teams just want multiple configuration files, period. This gives people what they want (multiple configs), without giving them something else they might not want (Chinese walls within the application). Context-relative? Ok, but you have no sharing in that scenario. The contextRelative approach just says interpret this as relative to the application root path - I don't see how that makes sense here, but I'm surely missing something. The purpose of a Tiles Definition is utilimately to include tiles, which means we need to specify a path to the tile. If we can mark some of the paths to be application-relative, then the modules can share tiles. think) what is desirable (what I understood you were after) would be to say oh - this definition extends that one, but *that* one happens to be in a different module. Am I on the wrong page here? I know this is my goal - that's what I'm after. That would be cool, but it doesn't need to be in this release. Both the ActionMappings and the Definitions should support this type of extending in some future release (probably 1.2+). -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Ted Husted wrote: 10/16/2002 5:22:13 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: Don't have time to dive into the substantive technical details today, but in general I'm OK with a strategy of comma-delimited list of struts-config.xml resource files used to configure a single app module (consistent with the Tiles and Validators styles). I presume this just means running as many Digester.parse() calls as you need, and no other fundamental changes, right? Yes. Sorry if I was obtuse. I really should have just committed the change first, and talked about it afterwards. I guess that why we work by Lazy Consensus =:0) I think I finally see your point on this too. I'm just too thick-headed and open-mouthed. My concern is valid, but as long as I feel fairly sure I'm not going to get a change veto'd - or tear something up - it would best to just implement the change and ask questions later. But I'll go ahead and do that next and see if anyone squawks. -Ted. I think we've all had a turn at being obtuse today, Ted - don't feel like you have a monopoly going ;-) -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Craig R. McClanahan wrote: It's easier to ask for forgiveness than permission :-) I'm learning that - albeit slowly! Craig -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 12:20 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 2:43:57 PM, Eddie Bush [EMAIL PROTECTED] wrote: Do we need a proposal maybe? As a rule, we propose through code, since that's all we can really vote on anyway =:0) I'm not sure I'd consider it a general rule. There have certainly been plenty of times we've discussed a [PROPOSAL] at length before any code changes happened. Depending on the scale/impact of the change, that's sometimes more appropriate. Sometimes it's just a judgement call, too. If you think you might be forced to back out all your changes, you might think differently about committing them first than if your confidence level is high. ;-) -- Martin Cooper My only point is that if I patch the controller to support a delimited list of struts-configs, as we do with Tiles and the Validator, then we have the choice between the Chinese wall approach to modules, or just diving up elements between multiple files. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
On Wed, 16 Oct 2002, Martin Cooper wrote: Date: Wed, 16 Oct 2002 14:43:44 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Tiles Refactorings for 1.1 compatability -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 2:22 PM To: Struts Developers List; [EMAIL PROTECTED] Subject: Re: Tiles Refactorings for 1.1 compatability On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 17:13:19 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 5:01:55 PM, Eddie Bush [EMAIL PROTECTED] wrote: I think it's reasonable we would fix things to be independent now, as Martin and Craig have suggested, and then look at making modules cooperate next. I'm not talking about anyting to do with modules cooperating or not. I'm just saying that the supplemental Struts configuration files (for Validator and Tiles) can be specified as a list, but the main struts-config cannot be. In my experience, many teams just want multiple configuration files, period. This gives people what they want (multiple configs), without giving them something else they might not want (Chinese walls within the application). Don't have time to dive into the substantive technical details today, but in general I'm OK with a strategy of comma-delimited list of struts-config.xml resource files used to configure a single app module (consistent with the Tiles and Validators styles). I presume this just means running as many Digester.parse() calls as you need, and no other fundamental changes, right? That's one possibility, but it leaves the door wide open for people to shoot themselves in the foot. Consider a situation with two config files, a.xml and b.xml. Now, a.xml contains an action, actionA, that specifies a form bean named theBean of type FormBeanA, and b.xml contains an action, actionB, that specifies a form bean named theBean of type FormBeanB. If the config entry in web.xml lists a.xml before b.xml, then actionA will fail; in the other order, actionB will fail. An interesting one to debug... This is semantically equivalent to declaring two actions with the same path in the same file, with equivalent results. At the very least, the config reading code would need to be modified to throw an exception whenever a duplicate entry of any type was encountered. That would alleviate most of the problem, but would still leave the door open for an interesting debugging session if, for example, actionB referenced theBean, but theBean itself was accidentally omitted from b.xml (but still configured through a.xml). We should probably do this anyway to deal with my previous comment. -- Martin Cooper Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:51 PM To: Struts Developers List Subject: RE: Tiles Refactorings for 1.1 compatability On Wed, 16 Oct 2002, Martin Cooper wrote: Date: Wed, 16 Oct 2002 14:43:44 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Tiles Refactorings for 1.1 compatability -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 2:22 PM To: Struts Developers List; [EMAIL PROTECTED] Subject: Re: Tiles Refactorings for 1.1 compatability On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 17:13:19 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 5:01:55 PM, Eddie Bush [EMAIL PROTECTED] wrote: I think it's reasonable we would fix things to be independent now, as Martin and Craig have suggested, and then look at making modules cooperate next. I'm not talking about anyting to do with modules cooperating or not. I'm just saying that the supplemental Struts configuration files (for Validator and Tiles) can be specified as a list, but the main struts-config cannot be. In my experience, many teams just want multiple configuration files, period. This gives people what they want (multiple configs), without giving them something else they might not want (Chinese walls within the application). Don't have time to dive into the substantive technical details today, but in general I'm OK with a strategy of comma-delimited list of struts-config.xml resource files used to configure a single app module (consistent with the Tiles and Validators styles). I presume this just means running as many Digester.parse() calls as you need, and no other fundamental changes, right? That's one possibility, but it leaves the door wide open for people to shoot themselves in the foot. Consider a situation with two config files, a.xml and b.xml. Now, a.xml contains an action, actionA, that specifies a form bean named theBean of type FormBeanA, and b.xml contains an action, actionB, that specifies a form bean named theBean of type FormBeanB. If the config entry in web.xml lists a.xml before b.xml, then actionA will fail; in the other order, actionB will fail. An interesting one to debug... This is semantically equivalent to declaring two actions with the same path in the same file, with equivalent results. That's true. However, I think it's more likely to be a problem when there are multiple files, especially if different people are working on those files. A well-defined naming convention would be a necessity. At the very least, the config reading code would need to be modified to throw an exception whenever a duplicate entry of any type was encountered. That would alleviate most of the problem, but would still leave the door open for an interesting debugging session if, for example, actionB referenced theBean, but theBean itself was accidentally omitted from b.xml (but still configured through a.xml). We should probably do this anyway to deal with my previous comment. Good point. -- Martin Cooper -- Martin Cooper Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
At 2:26 PM -0600 2002/10/16, David Graham wrote:
To me, validator and tiles are part of the core. Without them,
struts loses much of its utility and importance.
I think that's a bit extreme. Action classes are part of the core;
RequestProcessor is part of the core. I've built several Struts apps
and barely touched either Tiles or Validator, and haven't missed
them. Furthermore, Validator will be mostly obsoleted by Java Server
Faces.
If committers think it's best to keep them in the core distribution,
I'm not going to make a fuss about it. But I think it's selling
Struts very short to suggest that it's not very useful or important
if you aren't using Validator or Tiles. And if decoupling useful
components from a core distribution helps maintain focus and cut a
1.1 release, I would think there's something to be said for that.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
I haven't used dyna beans or modules but that doesn't make them not part of
the core struts features. Also, just because some future technology may
make a struts feature obsolete, does not reduce its importance. I stand by
the belief that without tiles and validator (or any other core feature)
struts looses utility. You may not use every feature but many people use
the ones you don't.
Separating tiles and validator is simply not a good idea.
David
From: Joe Germuska [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
Date: Wed, 16 Oct 2002 17:56:22 -0500
At 2:26 PM -0600 2002/10/16, David Graham wrote:
To me, validator and tiles are part of the core. Without them, struts
loses much of its utility and importance.
I think that's a bit extreme. Action classes are part of the core;
RequestProcessor is part of the core. I've built several Struts apps and
barely touched either Tiles or Validator, and haven't missed them.
Furthermore, Validator will be mostly obsoleted by Java Server Faces.
If committers think it's best to keep them in the core distribution, I'm
not going to make a fuss about it. But I think it's selling Struts very
short to suggest that it's not very useful or important if you aren't using
Validator or Tiles. And if decoupling useful components from a core
distribution helps maintain focus and cut a 1.1 release, I would think
there's something to be said for that.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get glazed,
they go white, their hands tremble As I watch them I often feel that a
dope peddler is a gentleman compared with the man who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Get a speedy connection with MSN Broadband. Join now!
http://resourcecenter.msn.com/access/plans/freeactivation.asp
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: Tiles Refactorings for 1.1 compatability
10/16/2002 6:51:23 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: That's one possibility, but it leaves the door wide open for people to shoot themselves in the foot. Consider a situation with two config files, a.xml and b.xml. Now, a.xml contains an action, actionA, that specifies a form bean named theBean of type FormBeanA, and b.xml contains an action, actionB, that specifies a form bean named theBean of type FormBeanB. If the config entry in web.xml lists a.xml before b.xml, then actionA will fail; in the other order, actionB will fail. An interesting one to debug... This is semantically equivalent to declaring two actions with the same path in the same file, with equivalent results. At the very least, the config reading code would need to be modified to throw an exception whenever a duplicate entry of any type was encountered. That would alleviate most of the problem, but would still leave the door open for an interesting debugging session if, for example, actionB referenced theBean, but theBean itself was accidentally omitted from b.xml (but still configured through a.xml). We should probably do this anyway to deal with my previous comment. Using the same element name more than once is really only the tip of the iceberg. We can also delete or rename a form bean from the file and Struts will not catch the problem until runtime. Heck, we can set validate to true and omit the input property and not catch the problem until validate actually fails. Or now specify an input forward that doesn't exist. We can also specify entries from the Application Resources that don't exist, or ask Actions to find forwards that can't be found. Forms can specify formbean properties that don't exist, ActionMappings can specify classes that don't exist, and so on. I agree that it would be a Good Thing if someone were to write a utility that vetted the configuration to be sure all the references resolved, but doing a proper job with something like this sounds like a task for 1.1+. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: Tiles Refactorings for 1.1 compatability
I agree that at this point pulling the Validator and Tiles from the core distribution would be more trouble than keeping them in, but it's important to note that both components have been around since the Struts 0.5 era, and I was using them in production with a late beta of Struts 1.0 years ago. Struts does have an open architechture, and there are many important Struts extensions that aren't kept in our CVS. -Ted. 10/16/2002 7:24:37 PM, David Graham [EMAIL PROTECTED] wrote: I haven't used dyna beans or modules but that doesn't make them not part of the core struts features. Also, just because some future technology may make a struts feature obsolete, does not reduce its importance. I stand by the belief that without tiles and validator (or any other core feature) struts looses utility. You may not use every feature but many people use the ones you don't. Separating tiles and validator is simply not a good idea. David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Ted Husted wrote: Using the same element name more than once is really only the tip of the iceberg. We can also delete or rename a form bean from the file and Struts will not catch the problem until runtime. Not in my system! :) XDoclet to the rescue. Form bean definitions are generated completely - move a class to a different package, delete it, rename it, no problem. Heck, we can set validate to true and omit the input property and not catch the problem until validate actually fails. Now this is a problem. Or now specify an input forward that doesn't exist. Again, a problem. We can also specify entries from the Application Resources that don't exist Using my DbResources, this is not a problem per se. No crash, only the resource string returned is the config/locale/key combination requested giving a very visual indication that something is missing. , or ask Actions to find forwards that can't be found. Again, a problem. And this one could be very tough to find with a tool, but Cactus tests (using StrutsTestCase) find these easily. Forms can specify formbean properties that don't exist, True. But we have a starter JSP generator that generates the fields from a form bean using XDoclet. So that issue doesn't crop up until we add a field later, but the problem is minimized. ActionMappings can specify classes that don't exist, and so on. XDoclet *could* take care of this, but I choose not to codify action mappings with @tags, but do it separately. I agree that it would be a Good Thing if someone were to write a utility that vetted the configuration to be sure all the references resolved, but doing a proper job with something like this sounds like a task for 1.1+. If we ever got into a situation where these problems cropped up often, I'd build something to catch them, but I've not found these to be much of a problem using XDoclet for some of the dirty work, as well as other tricks. Erik p.s. on the topic of Validator - its working nicely for us. We end up writing some custom validations, but for the most part we've not had any problems with it. I saw earlier that the DTD issue I encountered has been fixed - but I worked around it with XDoclet's generation of validation.xml by omitting the DTD from the output. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: Tiles Refactorings for 1.1 compatability
What are people's feelings about supporting Servlet 2.2 in post 1.1? Is it time that we can say in 1.2 and beyond that servlet 2.3 is required? I was thinking about the roadmap, and realizing that while a Struts version that was JSF aware was probably a ways off, a version with JSTL incorporated into it (and here I'm thinking about Mr. Karr's work) as a first class citizen would not be as far off, and we may not want to hold up incorporating that technology waiting for JSF integration. That makes me think that it would be a good thing to say that in 1.2 Servlet 2.3 is required. Remember, 1.2 will be a few months out from now, so it doesn't seem that at that time 2.3/JSP 1.2 would be that bad of a thing to say is the lower end of what is supported? Comments? I'm going to write up a draft roadmap tomorrow and send it around for comments. If you want to provide input into it, please speak up now so I can incorporate your ideas. Right now I can think of two basic buckets: 1.2 Servlet 2.3 / JSP 1.2 based (assuming no objections JSTL tag library incorporated as a first class citizen Support for distributed struts components within a single application (either by just having a list of them or by using some assembling technology) 1.1 bugs fixes 2.0 Servlet 2.4 based (?) JSF integration This presumes that 1.1 has Tiles and Validator in place as first class citizens and working properly with sub applications. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 2:33 PM To: Struts Developers List; [EMAIL PROTECTED] Subject: Re: RE: Tiles Refactorings for 1.1 compatability IMHO, any rational roadmap for post-1.1 is going to have to lump proposed changes into at least two buckets: * Those that can be implemented on Servlet 2.2 / JSP 1.1, including refactoring of existing functionality (but with a continued emphasis on backwards compatibility). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Craig R. McClanahan wrote: On Wed, 16 Oct 2002, Ted Husted wrote: Don't have time to dive into the substantive technical details today, but in general I'm OK with a strategy of comma-delimited list of struts-config.xml resource files used to configure a single app module (consistent with the Tiles and Validators styles). I presume this just means running as many Digester.parse() calls as you need, and no other fundamental changes, right? Craig As a core contributor for Expresso Framework I find this discussion interesting. In Expresso one of the contributors put together a XML Augmentator that parse several XML configuration files. We integrated Struts 1.0.2 so we do not have a special notation of sub applications, but just the one struts-config file, but we can have several *expresso-struts-config* files. If the expresso-strut config implement the same XML DTD then in theory they can merged together internally in a giant DOM. This is what I think the contribotor ( Mike Rimov, I think) did for Expresso. I am not sure how it solves the modules problem though in pure Struts. I have a little difficult understanding the terminology here. Is a module the same as a subapplication? I can see a might have a little bit work ahead of me, when I start trying to integrate Struts 1.1 with the latest Expresso if I do not under all the sub application issues. For Expresso it will make sense to subapplications to know about the default application (which is in our case Expresso). A sub application should be able to find out about sub applications also loading into the system. But hey may be I am way of base here. TRYING TO KEEP TEXT SHORT, TOO MUCH STRAIN ON MY EYES. -- Peter Pilgrim ServerSide Java Specialist My on-line resume and for interview videos about myself, J2EE Open Source, Struts and Expresso. || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tiles Refactorings for 1.1 compatability
I've been looking over Tiles - specifically at how to make it be 1.1-compliant wrt modules and not trampling on itself cringe/. After doing some greps here and there to try to figure things out, it occurred to me someone might have a diagram of how things are done. I can read UML fairly well, so that would be ideal. Any UML diagrams of Tiles? Thanks! -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Eddie, Can you take a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12309 It relates to tiles and 1.1. I'd like to get your thoughts on it. Sorry, this didn't really answer your question. Dave From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Tiles Refactorings for 1.1 compatability Date: Tue, 15 Oct 2002 13:58:54 -0500 I've been looking over Tiles - specifically at how to make it be 1.1-compliant wrt modules and not trampling on itself cringe/. After doing some greps here and there to try to figure things out, it occurred to me someone might have a diagram of how things are done. I can read UML fairly well, so that would be ideal. Any UML diagrams of Tiles? Thanks! -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Yes, I've seen that bug. I'll take a look at it. Does anyone have a valid reason why this shouldn't be done? David Graham wrote: Eddie, Can you take a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12309 It relates to tiles and 1.1. I'd like to get your thoughts on it. Sorry, this didn't really answer your question. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
No, but here's a related practices question: An ActionMapping has a forward property too. If the resource in question is within the same module, is ActionMapping.forward better than using the ForwardAcion. (It's definatley less to write!) -T. 10/15/2002 3:34:29 PM, Eddie Bush [EMAIL PROTECTED] wrote: Yes, I've seen that bug. I'll take a look at it. Does anyone have a valid reason why this shouldn't be done? David Graham wrote: Eddie, Can you take a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12309 It relates to tiles and 1.1. I'd like to get your thoughts on it. Sorry, this didn't really answer your question. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
True - but what about tools ;-) They don't mind writing a little extra :-) I have to admit I tend to use this format myself. I suppose the primary reason I do is that if I ever need to change things (forward-looking) so that the action actually does something, I can just change the class. Of course, for *many* pages, that simple isn't likely to ever happen - and your point is very valid :-) Plus, if I do wind up refactoring, I probably wind up poking in local forwards ... so ... shuts-up/ I think another reason I personally tend toward writing in that format is that it's more consistent with how the others are done. I'll try to get a fix in this evening. Ted Husted wrote: No, but here's a related practices question: An ActionMapping has a forward property too. If the resource in question is within the same module, is ActionMapping.forward better than using the ForwardAcion. (It's definatley less to write!) -T. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
