Re: Short term plans
Thought are welcome, patches are appreciated. Test cases are ... really nice :-) If there's one thing I've found, persistence (polite persistence) is a very good thing to have as well ;-) John Yu wrote: At 08:31 pm 01-03-03, you wrote: First, David was probably trying to be helpful. (Why reinvent the wheel?) No dispute about that! David's and other committers' dedication of time and energy is much appreciated. But to answer your question, I think the litmus test would be whether there is a working patch annexed. [snipped] Meanwhile, if we have a good suite of tests, and a patch comes along, it will be easier for any of us to commit it (since the tests will help catch any problems). Summing up, is it fair to say that an enhancement request which comes with a patch (and possibly some test cases) will be given relatively higher priority, regardless whether its functionality overlaps with other technologies? (And persistence counts as well.) Shall this be added somewhere on the webpage? -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
Redundant only if you're using the appropriate prerequisites. As a practical matter, not everyone can migrate as quickly as they might like. In the 2.x series, the JSTL argument would have some technical merit. In the 1.x series, it is not applicable to everyone in our target base. Of course, we are all entitled to decide what we each will and won't commit (which is why we like to have multiple committers). Happily, we each are entitled to choose which activities are most productive and the best use of our own volunteer time. If someone comes along who aggressively pursues patches to the elder JSP codebase, we could end up with even more. =:0) -T. David Graham wrote: I personally won't commit any changes that overlap with *standard* technologies like JSTL or JSF when it is finalized. I think it's counterproductive and time consuming to support a redundant code base. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
At 03:15 am 02-03-03, you wrote: My personal preferences on the immediate future are to make Struts 1.2 an evolutionary path for existing 1.0 and 1.1 users, but adopt a release often model of 1.2.x releases like what the Apache HTTPD server does, and what Tomcat 4.1 and 5.0 have adopted -- release a new milestone when you've added a new feature or two, or fixed enough bugs to be worthwhile. (All points taken. I'm wondering if there's a place on Struts website for a Craig's Column to host Craig's writings. :-) Struts' release cycle/release process has been a contentious issue. I can't speak for the others, but I believe it's a general feeling among many Struts users that it's more desirable to shorten Struts' beta release cycle. Many developers have constraints implied by their upper managements or clients beta software can't be included in production systems. Adopting a release often model is much desired. Craig McClanahan -- John Yu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
At 01:36 am 02-03-03, you wrote: The test I use is this: Does the requested feature exist in JSTL? If so, don't duplicate the effort in Struts. This is not just my opinion, it has been discussed among the committers before. I don't think people requesting enhancements or patches realize the amount of effort required to get it into Struts. Committers have to analyze the request, figure out the code to change, code it, test it, build it, and finally commit it. Add those steps up and you've got several hours of work. *I* will not volunteer my time implementing a feature that is already part of a standard taglib. Don't get me wrong. I appreciate your and other committers' work and dedication. And I can understand and empathize with the committers the frustrations of resolving some unthoughtful requests. I brought the issue up because it seems the opinions on this issue vary within the community and would like to find out if there's a general consensus. David regards, -- John Yu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
At 08:31 pm 01-03-03, you wrote: First, David was probably trying to be helpful. (Why reinvent the wheel?) No dispute about that! David's and other committers' dedication of time and energy is much appreciated. But to answer your question, I think the litmus test would be whether there is a working patch annexed. [snipped] Meanwhile, if we have a good suite of tests, and a patch comes along, it will be easier for any of us to commit it (since the tests will help catch any problems). Summing up, is it fair to say that an enhancement request which comes with a patch (and possibly some test cases) will be given relatively higher priority, regardless whether its functionality overlaps with other technologies? (And persistence counts as well.) Shall this be added somewhere on the webpage? -- John Yu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
Summing up, is it fair to say that an enhancement request which comes with a patch (and possibly some test cases) will be given relatively higher priority, regardless whether its functionality overlaps with other technologies? (And persistence counts as well.) I personally won't commit any changes that overlap with *standard* technologies like JSTL or JSF when it is finalized. I think it's counterproductive and time consuming to support a redundant code base. David _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
Thank you for reminding us of that - seems (nearly) everyone (except you, I, and [ probably still ] Craig) wants to do that in 1.2.0 and that was, at the time we decided to make 1.2.x move to an incremental build system, determined to be more than 1.2.0 should entail. open-mouth/ insert-foot/ ... and folks wonder why it takes a year to see a release ... David Graham wrote: The plan is to change the base servlet requirement in 2.0 not 1.2. David -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
Craig R. McClanahan wrote: On Sat, 1 Mar 2003, Ted Husted wrote: Date: Sat, 01 Mar 2003 17:56:04 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Craig R. McClanahan wrote: My personal preferences on the immediate future are to make Struts 1.2 an evolutionary path for existing 1.0 and 1.1 users, but adopt a release often model of 1.2.x releases like what the Apache HTTPD server does, and what Tomcat 4.1 and 5.0 have adopted -- release a new milestone when you've added a new feature or two, or fixed enough bugs to be worthwhile. For 1.2, how about if we finish the Commons-Resources migration, along with whatever api/bug-fixes turn up in the meantime, and call it a release? That by itself would certainly be enough for a 1.2.0, but there's a bunch of other things we've deferred that would make sense in the 1.2.x lifetime. I beleive that was the deal that was struck back some time ago. Not to rain on anyone's parade, but Craig just hit the nail on the head. We went through the debate on that already -- and it was pulling hairs to get consensus. Let's not open it up for discussion again, please. Quick 1.2.0 (bug-fixes) - couple more features in 1.2.x - servlet api change in 2.0. That's how it went, I believe (I think folks can find it on the web site, as a matter of fact [ thanks Ted! ]). -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
At 11:46 am 01-03-03, you wrote: JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 and JSP 1.2, so they are not even an option for a very significant portion of the Struts user community. Thus, it would be irresponsible to abandon our focus on ensuring the quality of the Struts tag libraries -- and this would be true even if Struts was a commercial product instead of an open source package. With respect (too :-), what criteria should/would the (developer) community use to strike a balance, both ensuring the quality and relevance of Struts taglibs (JSP 1.1 dependent) and migrating users gradually to JSTL (JSP 1.2 dependent)? For instance, in a recent feature request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17535 As David, the recently crowned MVC (what an acronym), pointed out the requested feature for bean:message is already available in JSTL fmt:message. Is there an easy litmus test for Struts users to guestimate if an enhancement is worthwhile requesting? regards, -- John Yu Scioworks Technologies e: [EMAIL PROTECTED] w: +(65) 6873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
First, David was probably trying to be helpful. (Why reinvent the wheel?) But to answer your question, I think the litmus test would be whether there is a working patch annexed. All anyone has said is that since the attention of the Committers in their own work is likely to be on other technologies, it is equally likely that the Committers won't be spending their *own* development time *creating* patches. As long as the change has technical merit, and a Committer is willing to take responsbility for the patch, we won't/can't veto something becomes of competition from JSTL/JSF/XLST/Velocity/Tapestry/lord-knows. Meanwhile, if we have a good suite of tests, and a patch comes along, it will be easier for any of us to commit it (since the tests will help catch any problems). -T. John Yu wrote: With respect (too :-), what criteria should/would the (developer) community use to strike a balance, both ensuring the quality and relevance of Struts taglibs (JSP 1.1 dependent) and migrating users gradually to JSTL (JSP 1.2 dependent)? For instance, in a recent feature request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17535 As David, the recently crowned MVC (what an acronym), pointed out the requested feature for bean:message is already available in JSTL fmt:message. Is there an easy litmus test for Struts users to guestimate if an enhancement is worthwhile requesting? regards, -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
Yes, it was James, and I join thanking him, et. all.
The effect is feature creep delaying a release with a limited pool of
resources, for things that some would like to deprecate. Like in Struts
1.2 supporting Tomcat 3.x? That takes time, and limits what can be done
in other areas.
Surely you agree that some tags should slowly move to jakarta.taglib?
And if I can disagree on the stats, my anecdotal evidence is that
projects in development are Tomcat 4.x (JSP and Servlet API).
Else consider adding developers (keep an eye on Matt Raible, Ben
Tomasini, Scot Skyles, Ibatis.com guy, Tiles 201 guy, Stxx guy,
sf.struts people, ... )
Again, my hope is that a quick 1.2 release is Servlet 2.3 and EL.
( Struts 2.0 wish list?: more soapy, and JSP2.0, maven, jelly, and
http://ireport.sourceforge.net/images/screenshot6.gif drag and drop 2
way from jsp to beans, jdk 1.4)
I am now teaching JSP 2.0 in Resin 3/Tomcat 5 in my Struts classe with
this 2.0 syntax:
${ibean['field']}
By the time their 6 month project cycle is ready to deploy, JSP2.0 will
be out.
Just take it into consideration, a faster development cycle, means
making some austerity choices in 1.2. Alternative? Struts 1.2 in
18 months?
.V
Craig R. McClanahan wrote:
On Fri, 28 Feb 2003, David Graham wrote:
Date: Fri, 28 Feb 2003 17:50:08 -0700
From: David Graham [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Short term plans
The taglibs are a heavily used feature. We get a lot of bug reports on them
so the tests are badly needed. There is no doubt that we should use JSTL
but at this point not everyone has that option.
At JavaOne US 2002 (March 2002) I did a survey of the folks that came to
the Struts Community BOF. Over half the people there were developing and
deploying on J2EE 1.2 (i.e. Servlet 2.2 and JSP 1.1) platforms. Yes, it's
almost a year later now, but the situation has not *totally* changed.
JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3
and JSP 1.2, so they are not even an option for a very significant portion
of the Struts user community. Thus, it would be irresponsible to abandon
our focus on ensuring the quality of the Struts tag libraries -- and this
would be true even if Struts was a commercial product instead of an open
source package.
That being said, it's very clear where the future is for view tier
technology. But that's for the future (Struts 1.2 and beyond) -- and,
even for those future Struts versions, users are not always able to
convert their applications instantly. We need to care now, and will
continue to need to care in the future, about the quality of the existing
Struts tag libraries. I'm totally delighted that someone like David has
cared enough to create such a comprehensive test suite for a feature that
is critically important to a very large majority of current, and future,
Struts users.
Thanks David!
David
Craig
With respect, consider how much time struts-devs should spend on tags, I
kind of agree with those that say slowly move them over to taglibs and
separate jar away from core struts, for example if JSTL can do it.
Of course I know, open source means donating contributors kind of get to
work on what they want.
my 2 c.
.V
Karr, David wrote:
-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]
My plans are to finish up html this weekend, and tiles, upload, and
validator by the end of next week. After that I hope to get all the
nested tags done between 3/15 and 3/22, then move on to the struts-el
tags.
The only thing that might delay things is the fact that my contract is
almost up and I'm desperately looking for another job.
Does anyone object or is there a special focus that anyone wants to
get
covered quickly?
Also, are there any volunteers out there wanting to help me get this
stuff nailed?
Sigh.
If your new testing setup is reasonably straightforward, I wouldn't
imagine it could be very difficult for me or someone else to clone them
(and remove some) for the Struts-EL tests. There already is a set of
Cactus tests for Struts-EL which covered more than the original base
Struts tests did, but your new work has very likely jumped well past
that.
In short, if you've finished everything you need to do for bean, logic,
and html, and you have some doors to knock on, then give me what I need
to know and I'll implement the Struts-EL tests (or someone else, if they
wanted to do this). If Aaron has time, he could probably do the same
for the nested tags.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
-
To unsubscribe, e
Re: Short term plans
The plan is to change the base servlet requirement in 2.0 not 1.2.
David
From: Vic Cekvenich [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Short term plans
Date: Sat, 01 Mar 2003 07:37:38 -0500
Yes, it was James, and I join thanking him, et. all.
The effect is feature creep delaying a release with a limited pool of
resources, for things that some would like to deprecate. Like in Struts 1.2
supporting Tomcat 3.x? That takes time, and limits what can be done in
other areas.
Surely you agree that some tags should slowly move to jakarta.taglib?
And if I can disagree on the stats, my anecdotal evidence is that projects
in development are Tomcat 4.x (JSP and Servlet API).
Else consider adding developers (keep an eye on Matt Raible, Ben Tomasini,
Scot Skyles, Ibatis.com guy, Tiles 201 guy, Stxx guy, sf.struts people,
... )
Again, my hope is that a quick 1.2 release is Servlet 2.3 and EL.
( Struts 2.0 wish list?: more soapy, and JSP2.0, maven, jelly, and
http://ireport.sourceforge.net/images/screenshot6.gif drag and drop 2 way
from jsp to beans, jdk 1.4)
I am now teaching JSP 2.0 in Resin 3/Tomcat 5 in my Struts classe with this
2.0 syntax:
${ibean['field']}
By the time their 6 month project cycle is ready to deploy, JSP2.0 will be
out.
Just take it into consideration, a faster development cycle, means making
some austerity choices in 1.2. Alternative? Struts 1.2 in 18 months?
.V
Craig R. McClanahan wrote:
On Fri, 28 Feb 2003, David Graham wrote:
Date: Fri, 28 Feb 2003 17:50:08 -0700
From: David Graham [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Short term plans
The taglibs are a heavily used feature. We get a lot of bug reports on
them
so the tests are badly needed. There is no doubt that we should use JSTL
but at this point not everyone has that option.
At JavaOne US 2002 (March 2002) I did a survey of the folks that came to
the Struts Community BOF. Over half the people there were developing and
deploying on J2EE 1.2 (i.e. Servlet 2.2 and JSP 1.1) platforms. Yes, it's
almost a year later now, but the situation has not *totally* changed.
JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3
and JSP 1.2, so they are not even an option for a very significant portion
of the Struts user community. Thus, it would be irresponsible to abandon
our focus on ensuring the quality of the Struts tag libraries -- and this
would be true even if Struts was a commercial product instead of an open
source package.
That being said, it's very clear where the future is for view tier
technology. But that's for the future (Struts 1.2 and beyond) -- and,
even for those future Struts versions, users are not always able to
convert their applications instantly. We need to care now, and will
continue to need to care in the future, about the quality of the existing
Struts tag libraries. I'm totally delighted that someone like David has
cared enough to create such a comprehensive test suite for a feature that
is critically important to a very large majority of current, and future,
Struts users.
Thanks David!
David
Craig
With respect, consider how much time struts-devs should spend on tags, I
kind of agree with those that say slowly move them over to taglibs and
separate jar away from core struts, for example if JSTL can do it.
Of course I know, open source means donating contributors kind of get to
work on what they want.
my 2 c.
.V
Karr, David wrote:
-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]
My plans are to finish up html this weekend, and tiles, upload, and
validator by the end of next week. After that I hope to get all the
nested tags done between 3/15 and 3/22, then move on to the struts-el
tags.
The only thing that might delay things is the fact that my contract is
almost up and I'm desperately looking for another job.
Does anyone object or is there a special focus that anyone wants to
get
covered quickly?
Also, are there any volunteers out there wanting to help me get this
stuff nailed?
Sigh.
If your new testing setup is reasonably straightforward, I wouldn't
imagine it could be very difficult for me or someone else to clone them
(and remove some) for the Struts-EL tests. There already is a set of
Cactus tests for Struts-EL which covered more than the original base
Struts tests did, but your new work has very likely jumped well past
that.
In short, if you've finished everything you need to do for bean, logic,
and html, and you have some doors to knock on, then give me what I need
to know and I'll implement the Struts-EL tests (or someone else, if
they
wanted to do this). If Aaron has time, he could probably do the same
for the nested tags.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
Re: Short term plans
The test I use is this: Does the requested feature exist in JSTL? If so, don't duplicate the effort in Struts. This is not just my opinion, it has been discussed among the committers before. I don't think people requesting enhancements or patches realize the amount of effort required to get it into Struts. Committers have to analyze the request, figure out the code to change, code it, test it, build it, and finally commit it. Add those steps up and you've got several hours of work. *I* will not volunteer my time implementing a feature that is already part of a standard taglib. David From: John Yu [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Date: Sat, 01 Mar 2003 16:34:07 +0800 At 11:46 am 01-03-03, you wrote: JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 and JSP 1.2, so they are not even an option for a very significant portion of the Struts user community. Thus, it would be irresponsible to abandon our focus on ensuring the quality of the Struts tag libraries -- and this would be true even if Struts was a commercial product instead of an open source package. With respect (too :-), what criteria should/would the (developer) community use to strike a balance, both ensuring the quality and relevance of Struts taglibs (JSP 1.1 dependent) and migrating users gradually to JSTL (JSP 1.2 dependent)? For instance, in a recent feature request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17535 As David, the recently crowned MVC (what an acronym), pointed out the requested feature for bean:message is already available in JSTL fmt:message. Is there an easy litmus test for Struts users to guestimate if an enhancement is worthwhile requesting? regards, -- John Yu Scioworks Technologies e: [EMAIL PROTECTED] w: +(65) 6873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
On Sat, 1 Mar 2003, John Yu wrote: Date: Sat, 01 Mar 2003 16:34:07 +0800 From: John Yu [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans At 11:46 am 01-03-03, you wrote: JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 and JSP 1.2, so they are not even an option for a very significant portion of the Struts user community. Thus, it would be irresponsible to abandon our focus on ensuring the quality of the Struts tag libraries -- and this would be true even if Struts was a commercial product instead of an open source package. With respect (too :-), what criteria should/would the (developer) community use to strike a balance, both ensuring the quality and relevance of Struts taglibs (JSP 1.1 dependent) and migrating users gradually to JSTL (JSP 1.2 dependent)? For instance, in a recent feature request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17535 As David, the recently crowned MVC (what an acronym), pointed out the requested feature for bean:message is already available in JSTL fmt:message. Is there an easy litmus test for Struts users to guestimate if an enhancement is worthwhile requesting? Good question. I think there are multiple perspectives for asking for enhancements, all of them valid. Some examples: * I need it -- This particular feature would help me out right now, without disrupting my entire app by forcing me to upgrade to the latest and greatest. * Lots of people need it -- This particular feature would be generally useful to lots of people using an existing version of Struts (think about how many add-on libraries and tags work fine with 1.0.2 based apps). * I want to work on it -- If we are limited by the number of developers working on Struts and we want those folks working on the future stuff, nothing stops us from adding some more developers that want to continue to enhance the existing tags. NOTE -- this perspective is the most critical for actually getting anything done :-). There's nothing wrong with people operating from any and all of these perspectives simultaneously. In all cases, of course, patches that actually *implement* the new feature (rather than just an enhancement request asking for it) is a lot more likely to get the thing actually done (modulo timing delays when we're trying to get a release out the door). And, if you do that enough times, you're likely to find yourself operating from the third perspective and welcomed as an additional Struts developer -- and people who want to do that would be welcomed. A fourth perspective that is also valid is to be future looking: what do we want a future Struts to look like without being as much concerned about existing users with their day-to-day real life problems. We haven't spent a lot of time (yet) talking about that on the STRUTS-DEV list -- at least partly because I've been afraid we would dive into those (fun) discussions and sort of ignore the fact that 1.1 isn't out the door yet :-). It's certainly time to start articulating our thoughts and desires on this, so we can come to agreement on a coherent roadmap. On the particular issue of the existing Struts tags, at this point I can only state my own interests and plans: * I'm interested in enabling the convenient use of JSTL and JavaServer Faces technologies with an existing and future Struts controller environment. I'm not *personally* going to focus on maintaining and enhancing the existing tag libraries, but it would be ridiculous and counter-productive to suggest that others who want to work on them should not -- I apologize if *I* have ever implied that in my previous comments. * I'm interested in separating the core controller part of Struts (which I personally consider to be the most important part) from the current somewhat tight integration with the JSP tags as the view layer. Organizationally, this might well mean independent releases of the core and appropriate view technology libraries (and perhaps its even time to think about becoming a top-level Apache project like Ant, Avalon, and a few others have done -- but that's for a separate mail thread) * I'm interested in decoupling the controller part of Struts from its current heavy reliance on the Servlet APIs. Among other things, that would enable easy use of Struts in portal servers that will support the emerging portlet API (JSR-168). You've also heard Ted and others talk about the need for a good controller paradigm in the business tier as well as the view tier. We know how to build such a thing :-). * I'm interested in continuing to support Struts users that cannot drop everything and instantly move to the latest and greatest API versions. For example, it's still way way way too early to think about Struts 1.2 being based on Servlet 2.4 and JSP 2.0
Re: Short term plans
Craig R. McClanahan wrote: http://www.geocities.com/fullback_21_csca/index5.htmlhttp://www.geocities.com/fullback_21_csca/index5.htmlhttp://www.geocities.com/fullback_21_csca/index5.html * I'm interested in decoupling the controller part of Struts from its current heavy reliance on the Servlet APIs. Among other things, that would enable easy use of Struts in portal servers that will support the emerging portlet API (JSR-168). You've also heard Ted and others talk about the need for a good controller paradigm in the business tier as well as the view tier. We know how to build such a thing :-). Yes we do! The more I think about it the more I'm convinced that Struts is a primarily a very effective application framework, that just happened to use web apps for its first implementation. We just need to continue to abstract out the HTTP semantics (as we did for Messages) and expose the framework within. Another good example is the pluggable Request Processor. I could easly see this same object model applied to a business architechture. You wouldn't use a HTTP request, but you could pass around a business context for the same purpose (a la Velocity). Likewise for the response and a CommandMapping (err, ActionMapping). I find that the whole command/semaphore thing that Struts uses with the ActionMapping and ActionForwards works just as well on the business layer. Success is success. The business controller can decide *what* to do, and the Struts controller can *map* that to where the JSP lives. (Standard obit, navigator.) The business layer can define what commands it may pass back (success, failure, annualReport) and then its up to the presentation to decide which pages relate to those commands. IMHO, in the end, a lot us will be building business applications using components from the Commons, and then just exposing that application to Struts for the web-layer stuff. Most of the Struts sub-systems, like validation, messaging, workflow, data access, can (and do) live at the business layer. Our business applications won't use the Struts ApplicationResources: Struts will use business layer's ApplicationResources. A key pattern underlying Struts, and most of the other HTTP application frameworks, is the idea of deploying an object-web from a XML document. Right now, our servlet has two major responsibilities. * Process requests * Deploy the object-web The former responsibility is now fulfilled by the Request Processor. It might be interesting to look at abstracting the Deployment Processor into a pluggable object (or even a sub-framework). Right now, there are a lot of people reading in DTDs and deploying object-webs (including us - for Tiles and the Validator). There would seem to be a need for some type of base processor object, with handy extension points, that could be plugged into a servlet as needed. This could also make it a lot easier for teams to plug-in their own configs and deploy their own object webs. I still need to look and see how Cedric does it, but I think the idea of getting XML elements to extend each other is very imporant. We should be able to do with in all of our config files, and open up the capability for other products as well. While there's been some pressure to build more elements into the struts-config, I would argue that we need to go the other way. We need to be able to share things like validations with the businesss layer. Separate config files for discrete components reduces coupling and increases coherence. The real solution here is better tools. The Struts Console already reads struts-config and validator files. It's easy to envision a tool like this that could read in multiple configs and provide a single view to the developer. And there's a bunch a ways we could make something like the Console a very cool way to write these documents (picklists for valid options, dynamic picklists of most often used values, and so forth). The endgame would be if one Common Console could also read Hibernate and OJB configs, and maybe even help us synch DynaBeans with the data beans. Not to mention editing JXUnit files to create unit testing scripts, or, gosh, Ant buildfiles. Back on the homefront, we already fixed a number of design issues in 1.1. Two remaining hotspots seem to be * Uneven use of the action/page/path properties, * Presumption that ActionServet is the one-and-only ActionServlet, and * Action lock-in action/page/path We added the action property to the link tag in 1.1 (head-slap/). This small change makes a *huge* difference in clarifying the original intent of the API. It may also be helpful to add action to ActionForward and deprecate path in favor of page, to agree with the taglibs (and remove the semantic conflict with ActionMapping.path). We might also think about whether ActionMapping.input should be able to indicate another action. (Since many applications use page controllers to seed the
Re: Short term plans
How about we solve the 7 remaining 1.1 bugs first ;-). Dave From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Date: Sat, 01 Mar 2003 17:56:04 -0500 Craig R. McClanahan wrote: My personal preferences on the immediate future are to make Struts 1.2 an evolutionary path for existing 1.0 and 1.1 users, but adopt a release often model of 1.2.x releases like what the Apache HTTPD server does, and what Tomcat 4.1 and 5.0 have adopted -- release a new milestone when you've added a new feature or two, or fixed enough bugs to be worthwhile. For 1.2, how about if we finish the Commons-Resources migration, along with whatever api/bug-fixes turn up in the meantime, and call it a release? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Short term plans
+1 for both -- James Mitchell Web Developer/Struts Evangelist http://jakarta.apache.org/struts/ People demand freedom of speech to make up for the freedom of thought which they avoid. - Soren Aabye Kierkegaard (1813-1855) -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Saturday, March 01, 2003 6:08 PM To: [EMAIL PROTECTED] Subject: Re: Short term plans How about we solve the 7 remaining 1.1 bugs first ;-). Dave From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Date: Sat, 01 Mar 2003 17:56:04 -0500 Craig R. McClanahan wrote: My personal preferences on the immediate future are to make Struts 1.2 an evolutionary path for existing 1.0 and 1.1 users, but adopt a release often model of 1.2.x releases like what the Apache HTTPD server does, and what Tomcat 4.1 and 5.0 have adopted -- release a new milestone when you've added a new feature or two, or fixed enough bugs to be worthwhile. For 1.2, how about if we finish the Commons-Resources migration, along with whatever api/bug-fixes turn up in the meantime, and call it a release? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
On Sat, 1 Mar 2003, Ted Husted wrote: Date: Sat, 01 Mar 2003 17:56:04 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Craig R. McClanahan wrote: My personal preferences on the immediate future are to make Struts 1.2 an evolutionary path for existing 1.0 and 1.1 users, but adopt a release often model of 1.2.x releases like what the Apache HTTPD server does, and what Tomcat 4.1 and 5.0 have adopted -- release a new milestone when you've added a new feature or two, or fixed enough bugs to be worthwhile. For 1.2, how about if we finish the Commons-Resources migration, along with whatever api/bug-fixes turn up in the meantime, and call it a release? That by itself would certainly be enough for a 1.2.0, but there's a bunch of other things we've deferred that would make sense in the 1.2.x lifetime. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
The sentiments are good but the reality is sometimes different. I submitted two sets of logic tags in May 2001 which provided switch/case and if/and/or/else logic. They were basically wrappers for the existing struts logic tags. They were rejected at the time because the JSTL would be providing the same functionality - even though these tags worked in 2.2/1.1 and JSTL required 2.3/1.2. Funnily enough they were even on the TODO list at the time!!! So even though 1) * I wanted it * 2) * Other people wanted it * and 3) * I provided them * - it wasn't enough to get them included in Struts. Another thing was, although these logic tags were rejected the Empty and NotEmpty tags were added to Struts afterwards!! I guess the #1 requirement for anyone submitting to struts is can I get a committer to take any interest? Niall TED But to answer your question, I think the litmus test would be whether TED there is a working patch annexed. TED TED All anyone has said is that since the attention of the Committers in TED their own work is likely to be on other technologies, it is equally likely TED that the Committers won't be spending their *own* development time TED *creating* patches. TED TED As long as the change has technical merit, and a Committer is willing TED to take responsbility for the patch, we won't/can't veto something TED becomes of competition from JSTL/JSF/XLST/Velocity/Tapestry/lord-knows. CRAIG At JavaOne US 2002 (March 2002) I did a survey of the folks that came to CRAIG the Struts Community BOF. Over half the people there were developing and CRAIG deploying on J2EE 1.2 (i.e. Servlet 2.2 and JSP 1.1) platforms. Yes, it's CRAIG almost a year later now, but the situation has not *totally* changed. CRAIG CRAIG JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 CRAIG and JSP 1.2, so they are not even an option for a very significant portion CRAIG of the Struts user community. CRAIG I think there are multiple perspectives for asking for enhancements, CRAIG all of them valid. Some examples: CRAIG CRAIG * I need it -- This particular feature would help me . . . CRAIG CRAIG * Lots of people need it . . .useful to lots of people using an existing version of Struts ... CRAIG CRAIG * I want to work on it . . .nothing stops us from adding some more CRAIGdevelopers that want to continue to enhance the existing tags. CRAIG CRAIG NOTE -- this perspective is the most critical for actually getting anything done :-). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
Sounds great James! Thanks a bunch for doing the tests. David From: James Mitchell [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Short term plans Date: Fri, 28 Feb 2003 16:58:33 -0500 Committers/Developers As most of you know, I've been adding Cactus tests to try and cover (hopefully) all the core taglibs with every conceivable combination of attributes. Considering the hierarchy of how the tags are implemented, someone might say that a lot of these tests are redundant, but I would argue that the more coverage, the better. You never know when you need to take a feature from its super and implement it a different way. If you forget to add the appropriate tests, then you've exposed yourself to potential bugs. (Now, I apologize if that sentence doesn't make it through some mail filters ;) With the tests I'm adding, you're already covered. The only exception are a few EXTREMELY common attributes (prepareEventHandlers() and prepareStyles()). My plans are to finish up html this weekend, and tiles, upload, and validator by the end of next week. After that I hope to get all the nested tags done between 3/15 and 3/22, then move on to the struts-el tags. The only thing that might delay things is the fact that my contract is almost up and I'm desperately looking for another job. Does anyone object or is there a special focus that anyone wants to get covered quickly? Also, are there any volunteers out there wanting to help me get this stuff nailed? -- James Mitchell Web Developer/Struts Evangelist http://jakarta.apache.org/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Short term plans
-Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] My plans are to finish up html this weekend, and tiles, upload, and validator by the end of next week. After that I hope to get all the nested tags done between 3/15 and 3/22, then move on to the struts-el tags. The only thing that might delay things is the fact that my contract is almost up and I'm desperately looking for another job. Does anyone object or is there a special focus that anyone wants to get covered quickly? Also, are there any volunteers out there wanting to help me get this stuff nailed? Sigh. If your new testing setup is reasonably straightforward, I wouldn't imagine it could be very difficult for me or someone else to clone them (and remove some) for the Struts-EL tests. There already is a set of Cactus tests for Struts-EL which covered more than the original base Struts tests did, but your new work has very likely jumped well past that. In short, if you've finished everything you need to do for bean, logic, and html, and you have some doors to knock on, then give me what I need to know and I'll implement the Struts-EL tests (or someone else, if they wanted to do this). If Aaron has time, he could probably do the same for the nested tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
With respect, consider how much time struts-devs should spend on tags, I kind of agree with those that say slowly move them over to taglibs and separate jar away from core struts, for example if JSTL can do it. Of course I know, open source means donating contributors kind of get to work on what they want. my 2 c. .V Karr, David wrote: -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] My plans are to finish up html this weekend, and tiles, upload, and validator by the end of next week. After that I hope to get all the nested tags done between 3/15 and 3/22, then move on to the struts-el tags. The only thing that might delay things is the fact that my contract is almost up and I'm desperately looking for another job. Does anyone object or is there a special focus that anyone wants to get covered quickly? Also, are there any volunteers out there wanting to help me get this stuff nailed? Sigh. If your new testing setup is reasonably straightforward, I wouldn't imagine it could be very difficult for me or someone else to clone them (and remove some) for the Struts-EL tests. There already is a set of Cactus tests for Struts-EL which covered more than the original base Struts tests did, but your new work has very likely jumped well past that. In short, if you've finished everything you need to do for bean, logic, and html, and you have some doors to knock on, then give me what I need to know and I'll implement the Struts-EL tests (or someone else, if they wanted to do this). If Aaron has time, he could probably do the same for the nested tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
The taglibs are a heavily used feature. We get a lot of bug reports on them so the tests are badly needed. There is no doubt that we should use JSTL but at this point not everyone has that option. David With respect, consider how much time struts-devs should spend on tags, I kind of agree with those that say slowly move them over to taglibs and separate jar away from core struts, for example if JSTL can do it. Of course I know, open source means donating contributors kind of get to work on what they want. my 2 c. .V Karr, David wrote: -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] My plans are to finish up html this weekend, and tiles, upload, and validator by the end of next week. After that I hope to get all the nested tags done between 3/15 and 3/22, then move on to the struts-el tags. The only thing that might delay things is the fact that my contract is almost up and I'm desperately looking for another job. Does anyone object or is there a special focus that anyone wants to get covered quickly? Also, are there any volunteers out there wanting to help me get this stuff nailed? Sigh. If your new testing setup is reasonably straightforward, I wouldn't imagine it could be very difficult for me or someone else to clone them (and remove some) for the Struts-EL tests. There already is a set of Cactus tests for Struts-EL which covered more than the original base Struts tests did, but your new work has very likely jumped well past that. In short, if you've finished everything you need to do for bean, logic, and html, and you have some doors to knock on, then give me what I need to know and I'll implement the Struts-EL tests (or someone else, if they wanted to do this). If Aaron has time, he could probably do the same for the nested tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
On Fri, 28 Feb 2003, David Graham wrote: Date: Fri, 28 Feb 2003 17:50:08 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Short term plans The taglibs are a heavily used feature. We get a lot of bug reports on them so the tests are badly needed. There is no doubt that we should use JSTL but at this point not everyone has that option. At JavaOne US 2002 (March 2002) I did a survey of the folks that came to the Struts Community BOF. Over half the people there were developing and deploying on J2EE 1.2 (i.e. Servlet 2.2 and JSP 1.1) platforms. Yes, it's almost a year later now, but the situation has not *totally* changed. JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 and JSP 1.2, so they are not even an option for a very significant portion of the Struts user community. Thus, it would be irresponsible to abandon our focus on ensuring the quality of the Struts tag libraries -- and this would be true even if Struts was a commercial product instead of an open source package. That being said, it's very clear where the future is for view tier technology. But that's for the future (Struts 1.2 and beyond) -- and, even for those future Struts versions, users are not always able to convert their applications instantly. We need to care now, and will continue to need to care in the future, about the quality of the existing Struts tag libraries. I'm totally delighted that someone like David has cared enough to create such a comprehensive test suite for a feature that is critically important to a very large majority of current, and future, Struts users. Thanks David! David Craig With respect, consider how much time struts-devs should spend on tags, I kind of agree with those that say slowly move them over to taglibs and separate jar away from core struts, for example if JSTL can do it. Of course I know, open source means donating contributors kind of get to work on what they want. my 2 c. .V Karr, David wrote: -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] My plans are to finish up html this weekend, and tiles, upload, and validator by the end of next week. After that I hope to get all the nested tags done between 3/15 and 3/22, then move on to the struts-el tags. The only thing that might delay things is the fact that my contract is almost up and I'm desperately looking for another job. Does anyone object or is there a special focus that anyone wants to get covered quickly? Also, are there any volunteers out there wanting to help me get this stuff nailed? Sigh. If your new testing setup is reasonably straightforward, I wouldn't imagine it could be very difficult for me or someone else to clone them (and remove some) for the Struts-EL tests. There already is a set of Cactus tests for Struts-EL which covered more than the original base Struts tests did, but your new work has very likely jumped well past that. In short, if you've finished everything you need to do for bean, logic, and html, and you have some doors to knock on, then give me what I need to know and I'll implement the Struts-EL tests (or someone else, if they wanted to do this). If Aaron has time, he could probably do the same for the nested tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
I seem to be getting a lot of credit for things I didn't do. James Mitchell deserves the tester of the year award. Thanks James! David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Date: Fri, 28 Feb 2003 19:46:27 -0800 (PST) On Fri, 28 Feb 2003, David Graham wrote: Date: Fri, 28 Feb 2003 17:50:08 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Short term plans The taglibs are a heavily used feature. We get a lot of bug reports on them so the tests are badly needed. There is no doubt that we should use JSTL but at this point not everyone has that option. At JavaOne US 2002 (March 2002) I did a survey of the folks that came to the Struts Community BOF. Over half the people there were developing and deploying on J2EE 1.2 (i.e. Servlet 2.2 and JSP 1.1) platforms. Yes, it's almost a year later now, but the situation has not *totally* changed. JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 and JSP 1.2, so they are not even an option for a very significant portion of the Struts user community. Thus, it would be irresponsible to abandon our focus on ensuring the quality of the Struts tag libraries -- and this would be true even if Struts was a commercial product instead of an open source package. That being said, it's very clear where the future is for view tier technology. But that's for the future (Struts 1.2 and beyond) -- and, even for those future Struts versions, users are not always able to convert their applications instantly. We need to care now, and will continue to need to care in the future, about the quality of the existing Struts tag libraries. I'm totally delighted that someone like David has cared enough to create such a comprehensive test suite for a feature that is critically important to a very large majority of current, and future, Struts users. Thanks David! David Craig With respect, consider how much time struts-devs should spend on tags, I kind of agree with those that say slowly move them over to taglibs and separate jar away from core struts, for example if JSTL can do it. Of course I know, open source means donating contributors kind of get to work on what they want. my 2 c. .V Karr, David wrote: -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] My plans are to finish up html this weekend, and tiles, upload, and validator by the end of next week. After that I hope to get all the nested tags done between 3/15 and 3/22, then move on to the struts-el tags. The only thing that might delay things is the fact that my contract is almost up and I'm desperately looking for another job. Does anyone object or is there a special focus that anyone wants to get covered quickly? Also, are there any volunteers out there wanting to help me get this stuff nailed? Sigh. If your new testing setup is reasonably straightforward, I wouldn't imagine it could be very difficult for me or someone else to clone them (and remove some) for the Struts-EL tests. There already is a set of Cactus tests for Struts-EL which covered more than the original base Struts tests did, but your new work has very likely jumped well past that. In short, if you've finished everything you need to do for bean, logic, and html, and you have some doors to knock on, then give me what I need to know and I'll implement the Struts-EL tests (or someone else, if they wanted to do this). If Aaron has time, he could probably do the same for the nested tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SHORT TERM PLANS]
Ted, Take a squizz at the tutorials I put up on my nested extension page. http://www.keyboardmonkey.com/stats (thinking of putting up a support group page for blatant traffic generators anonymous too. You in? :) Starting off with the war file of everything needed with exception of files needed to run struts. Each file is waiting for them with an underscore on the end so all they have to do is rename it to remove the underscore (when the tutorial specifies) and they're in business. This way I saved files from being seen by the compiler until required. The files are empty with exception of package and import declarations, so they still have to code the body logic. After each milestone there's another war file of everything up to that point. This goes on until the end where there's a running war file at the very end to check against the final running version. As for the tutorial's content, a full version of each source page is available at every step as well as the code supplied on the page itself. Making the milestone war files (six in the tute) were a genuine pain in the ass (that's donkey :), but got it under control with some automated scripts to compile, package and deploy all at once for testing an uploading. I've already had some excellent feedback as to people really getting benefit as to the way the tutorial worked (one even said it was about the best online tutorial they've ever taken). So I think that the effort in creating tutorials in such a manner is beneficial. It does add to the development time however. All that other stuff in the blank.war etc... blank.war was how I first started hacking Struts, so I'm +1 on keeping that system alive. Arron. PS: Any tag extensions planned for the Short Term Plans? :) Ted Husted wrote: Martin Cooper wrote: I'm planning on making some other changes to the Struts build process in the near future, and I could certainly roll these in if people think it would be desirable. Here's a different but related issue. For the example applications, I'm wondering if we want to adopt a file system format that allows someone to download and install the WAR, and have all the source code in place, ready for exploration and tweaking. This is the approach I've been taking with my own examples. http://husted.com/struts/resources/struts-simple.zip http://husted.com/scaffolding/dist/logon.zip The source is under WEB-INF (/web-inf/src/java/ ...), and the build process is setup so you can work on it in place, without going through a deployment phase. This would let us offer example, exercise, and documentation WARs, with source, directly from the Web site where people could try them out as pure applications, and take a peek at how things work. If this meshes with Martin's other plans, I could help with the necessary changes. I'm also meaning to relabel struts-simple as a workflow example, since that it what it has become. The new logon example (above) also includes using Velocity templates with the nightly build, but doesn't use the latest version of the new Velocity Tools, which is also compatible with Struts 1.0. http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ I've also been working on a new version of the Struts blank app, if anyone is interested. http://husted.com/scaffolding/dist/blank.zip Basically the same thing, but with slightly different conventions and (more importantly) a build file that includes options for JavaDocs and building a WAR. I also hope to slip in some kind of stub for unit testing soon, based on some other work I'm doing with Vincent. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- 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: [SHORT TERM PLANS]
Arron Bates wrote: PS: Any tag extensions planned for the Short Term Plans? :) I think most of us are waiting on the JSTL. What we have now seems sufficient, especially in a MVC environment, and I would be concerned about doing anything that would heighten the migration path. Though, the JSTL seems relatively firm now, and it might be a good time to think about the migration path, and build any new tags or taglibs along those lines. We should especially look at ways that we can expose the framework objects to the presentation layer, so that they can be accessed by any presentation mechanism -- like the JSTL or Velocity templates, and so forth. Some initial work has been done along these lines with the ContextHelper object, but I'm sure there is more to do. Given mechanisms that expose the framework to tags in a non-proprietary way, then it would also be easier to start placing new libraries in Jakarta Taglibs, where everyone can use them. And, then of course, there is JavaServer Faces, when that comes of age. http://jcp.org/jsr/detail/127.jsp So, personally, I think we need to move the focus away from the Struts taglibs and toward How do we expose the framework to the growing number of standard presentation layer devices, like the JSTL, Velocity Templates, and JavaServer Faces? -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SHORT TERM PLANS]
Take a squizz at the tutorials I put up on my nested extension page. http://www.dictionary.com/cgi-bin/dict.pl?term=squizz :) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SHORT TERM PLANS]
On Sat, 12 Jan 2002, Martin Cooper wrote: Date: Sat, 12 Jan 2002 23:16:29 -0800 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [SHORT TERM PLANS] I know I'm coming in a month late on this, but the holidays are over and now I'm paying attention again... ;-) I guess I missed the original thread suggesting the breakup of the Struts jar file into core and taglibs. I can see the rationale for splitting the taglibs out from the core framework. However, I'm not so sure that all the taglibs should be split out as a single entity. It seems to me that it would make more sense to split out each taglib as its own self-contained entity, in the manner of Jakarta Taglibs. I'm planning on making some other changes to the Struts build process in the near future, and I could certainly roll these in if people think it would be desirable. What do people think? What about the stuff that's shared across multiple taglibs (org.apache.struts.util.*, org.apache.struts.action.*, and so on)? I haven't checked them all, but I'd be surprised if *any* of the tag libraries can stand on their own without needing the proposed struts-core.jar anyway. IMHO, having more smaller pieces makes life harder, not easier -- it's one of the few negatives for using commons-*.jar instead of the old stuff that was all right there waiting for you in struts.jar. -- Martin Cooper Craig - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Saturday, December 15, 2001 8:35 AM Subject: Re: [SHORT TERM PLANS] Ooops, one more. * Adjust the build process so that there is a struts-core.jar and a struts-tags.jar Ted Husted wrote: So to wrap up several outstanding threads, here's what is on my near-term agenda * Commit the initial ContextHelper to ActionServlet. * Commit the InvokeAction class to ActionServet. * Commit a SuperForm base class to action, for discussion purposes. * Develop a smart ActionForward class, that can build a dynamic path at runtime. * Start moving the TODOs over to Bugzilla as enhancements requests. If someone wants to take a good look at Arron's nesting taglib, we should consider that too. I just don't do a lot of work with the tag extensions myself. We should also revisit the base class for exception handling sometime soon. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- 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: [SHORT TERM PLANS]
Craig R. McClanahan wrote: What about the stuff that's shared across multiple taglibs (org.apache.struts.util.*, org.apache.struts.action.*, and so on)? I haven't checked them all, but I'd be surprised if *any* of the tag libraries can stand on their own without needing the proposed struts-core.jar anyway. IMHO, having more smaller pieces makes life harder, not easier -- it's one of the few negatives for using commons-*.jar instead of the old stuff that was all right there waiting for you in struts.jar. True, but I think it's important that we start paving the way for a future where there are several different presentation devices -- JSTL, JavaServer Faces, Velocity templates, the Struts taglibs -- which all have equal access to the framework components. Personally, I still think it would be worthwhile to try and break the build into a struts-core.jar and a struts-taglibs.jar, as the first step of a refactoring. The struts-taglibs.jar may retain a dependency on the struts-core.jar, and maybe that will never go away. But as we work on a migration path for the JSTL, and expand on our support for other devices, like Velocity Templates, it seems helpful to me to start thinking of the taglibs as one of several presentation options supported by Struts. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SHORT TERM PLANS]
These are all good points. One reason I had been thinking about splitting each taglib into its own jar is so that we could put the tld file in there as well, instead of having those files loose. With JSP 1.1, the tld file in a packaged taglib must be named taglib.tld, so it's not possible to package multiple taglibs in the same jar file. (This restriction was lifted in JSP 1.2, but we can't make use of that yet for compatibility reasons.) The end result would be the same number of files as we have today, but we'd have multiple Struts jars instead of one, and no loose tlds. However, you're right that these taglib jars would still be dependent on the core Struts jar. With Ted's comments in mind, perhaps we should leave things as they are until we have a better understanding of what external presentation devices (e.g. Velocity Templates) would need from Struts. At that point, we would be in a better position to think about how to expose functionality from a core library to client libraries, including separate Struts taglibs. (By the way, the other changes to the build process that I referred to are actually additions related to simplifying the release process, and will have very little impact on the way people build Struts today.) -- Martin Cooper - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Sunday, January 13, 2002 1:56 PM Subject: Re: [SHORT TERM PLANS] On Sat, 12 Jan 2002, Martin Cooper wrote: Date: Sat, 12 Jan 2002 23:16:29 -0800 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [SHORT TERM PLANS] I know I'm coming in a month late on this, but the holidays are over and now I'm paying attention again... ;-) I guess I missed the original thread suggesting the breakup of the Struts jar file into core and taglibs. I can see the rationale for splitting the taglibs out from the core framework. However, I'm not so sure that all the taglibs should be split out as a single entity. It seems to me that it would make more sense to split out each taglib as its own self-contained entity, in the manner of Jakarta Taglibs. I'm planning on making some other changes to the Struts build process in the near future, and I could certainly roll these in if people think it would be desirable. What do people think? What about the stuff that's shared across multiple taglibs (org.apache.struts.util.*, org.apache.struts.action.*, and so on)? I haven't checked them all, but I'd be surprised if *any* of the tag libraries can stand on their own without needing the proposed struts-core.jar anyway. IMHO, having more smaller pieces makes life harder, not easier -- it's one of the few negatives for using commons-*.jar instead of the old stuff that was all right there waiting for you in struts.jar. -- Martin Cooper Craig - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Saturday, December 15, 2001 8:35 AM Subject: Re: [SHORT TERM PLANS] Ooops, one more. * Adjust the build process so that there is a struts-core.jar and a struts-tags.jar Ted Husted wrote: So to wrap up several outstanding threads, here's what is on my near-term agenda * Commit the initial ContextHelper to ActionServlet. * Commit the InvokeAction class to ActionServet. * Commit a SuperForm base class to action, for discussion purposes. * Develop a smart ActionForward class, that can build a dynamic path at runtime. * Start moving the TODOs over to Bugzilla as enhancements requests. If someone wants to take a good look at Arron's nesting taglib, we should consider that too. I just don't do a lot of work with the tag extensions myself. We should also revisit the base class for exception handling sometime soon. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- 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: [SHORT TERM PLANS]
Ooops, one more. * Adjust the build process so that there is a struts-core.jar and a struts-tags.jar Ted Husted wrote: So to wrap up several outstanding threads, here's what is on my near-term agenda * Commit the initial ContextHelper to ActionServlet. * Commit the InvokeAction class to ActionServet. * Commit a SuperForm base class to action, for discussion purposes. * Develop a smart ActionForward class, that can build a dynamic path at runtime. * Start moving the TODOs over to Bugzilla as enhancements requests. If someone wants to take a good look at Arron's nesting taglib, we should consider that too. I just don't do a lot of work with the tag extensions myself. We should also revisit the base class for exception handling sometime soon. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
