[SHORT TERM PLANS]

[Ted Husted]

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:   
For additional commands, e-mail: 

Short term plans

[James Mitchell]

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]

Re: [SHORT TERM PLANS]

[Ted Husted]

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:   
> For additional commands, e-mail: 

-- 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:   
For additional commands, e-mail: 

Re: [SHORT TERM PLANS]

[Martin Cooper]

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?

--
Martin Cooper


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

Re: [SHORT TERM PLANS]

[Ted Husted]

I'm definately +1 on a core Strut JAR. 

I'm alo +1 on a struts-template.jar. We might consider moving this to
contrib, since many people are migrating to Tiles. I could help with
that if it matters, or just update the documentation when we are
through.

I'm +0 on either putting the others (bean, html, logic) into a
struts-taglibs.jar, since in practice it's unusual to use one without at
least one of the other two, and this cuts down on the number of jars we
need to talk about :) Taken together, they do form a kind of component
unto themselves.

I'm also +0 on having separate struts-bean.jar, struts-html.jar, and
struts-logic.jar, since (1) this is how Taglibs does it and (2) there is
then a 1:1 correlation between the jar and tld. You end up with a lot of
JARs in the lib, but then this is Java, and that's the Java way.

So on the latter two, I'm good with either case.

-Ted.


Martin Cooper wrote:
> 
> 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?
> 
> --
> Martin Cooper

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [SHORT TERM PLANS]

[Ted Husted]

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:   
For additional commands, e-mail: 

Re: [SHORT TERM PLANS]

[Arron Bates]

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]

[Ted Husted]

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]

[Ted Husted]

> 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:   
For additional commands, e-mail: 

Re: [SHORT TERM PLANS]

[Craig R. McClanahan]

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]

[Ted Husted]

"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:   
For additional commands, e-mail: 

Re: [SHORT TERM PLANS]

[Martin Cooper]

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.
> > > 

Re: Short term plans

[David Graham]

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

[Karr, David]

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

[Vic Cekvenich]

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

[David Graham]

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

[Craig R. McClanahan]

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

[David Graham]

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

[John Yu]

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  is already available in JSTL 
. 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

[Ted Husted]

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  is already available in JSTL 
. Is there an easy litmus test for Struts users to 
guestimate if an enhancement is worthwhile requesting?

regards,



--
Ted Husted,
Struts in Action 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Short term plans

[Vic Cekvenich]

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/?pag

Re: Short term plans

[David Graham]

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.


-

Re: Short term plans

[David Graham]

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  is already available in JSTL 
. 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

[Craig R. McClanahan]

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  is already available in JSTL
> . 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 in

Re: Short term plans

[Ted Husted]

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 (). 
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 
contr

Re: Short term plans

[Ted Husted]

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]

Re: Short term plans

[David Graham]

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

[James Mitchell]

+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

[Craig R. McClanahan]

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

[Niall Pemberton]

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
CRAIG>developers 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

[Eddie Bush]

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.



... 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

[Eddie Bush]

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

[John Yu]

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

[John Yu]

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

[John Yu]

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

[David Graham]

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

[Eddie Bush]

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

[Ted Husted]

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]

Comptability of JSR 127 and Struts [Was: SHORT TERM PLANS]

[John Yu]

I'm wondering how JSR-127 will fit with Struts.

While it's beyond my comprehension how JSR-127 will look like and offer, I 
have this gut feeling that there is an architectural impedance. Frankly, 
it's still vague to me what and how JSR-127 tries to achieve and I always 
thought the JSR-127 effort would somehow overlap a lot with Struts.

Can someone shed some light on this? (Martin, I think you mentioned you saw 
the demo in JavaOne. And Craig, I think you are on the expert group?)
--
John


At 10:51 am 13-01-2002 -0500, you wrote:

>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?"

-- 
John Yu   Scioworks Technologies
e: [EMAIL PROTECTED] w: +(65) 873 5989
w: http://www.scioworks.com   m: +(65) 9782 9610

Scioworks Camino - "Rapid WebApp Assembly for Struts"


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comptability of JSR 127 and Struts [Was: SHORT TERM PLANS]

[Craig R. McClanahan]

On Mon, 14 Jan 2002, John Yu wrote:

> Date: Mon, 14 Jan 2002 11:13:34 +0800
> From: John Yu <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Comptability of JSR 127 and Struts [Was: SHORT TERM PLANS]
>
> I'm wondering how JSR-127 will fit with Struts.
>

It's too early to know much, but I'm confident about the long term
outcome.

> While it's beyond my comprehension how JSR-127 will look like and offer, I
> have this gut feeling that there is an architectural impedance. Frankly,
> it's still vague to me what and how JSR-127 tries to achieve and I always
> thought the JSR-127 effort would somehow overlap a lot with Struts.
>
> Can someone shed some light on this? (Martin, I think you mentioned you saw
> the demo in JavaOne. And Craig, I think you are on the expert group?)

Yes, I am on the expert group forFaces (and for the JSP Standard Tag
Library, JSTL).  Discussions are ongoing, and good progress towards
defining a good architecture for GUI components is being made.

In general terms, I look at JavaServer Faces (and the JSP Standard Tag
Library) as "mainstream" efforts that will, ultimately, supplant the use
of the majority of the Struts custom tag libraries.  We'll continue to
support the existing libraries (there are *way* too many apps using them
to consider deprecating them :-), but I am not putting any attention on
major functional improvements in the areas that Faces and JSTL are going
to cover.  Instead, I'm going to be focusing my personal attention on
things like the multi-application support (just checked in), and
integration of the workflow project that is in the Commons sandbox.

Happily, the Struts controller doesn't care what technology was used to
create the user interface -- it deals with request parameters and request
dispatcher forwards.  We may need to do a little bit of glue work to
emulate some of the "automatic" interactions between form beans and the UI
compoennts, but I don't anticipate any significant hurdles in this
respect.

I would encourage future-looking Struts applcation developers to start
learning the JSP Standard Tag Library (JSTL) now -- you can get the early
access release from <http://jakarta.apache.org/taglibs> -- and be ready to
examine an early access release of Faces if and when the Expert Group is
ready to share one.

> --
> John
>

Craig McClanahan


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

Re: Comptability of JSR 127 and Struts [Was: SHORT TERM PLANS]

[John Yu]

Thanks for your reply, Craig. Your assurance is encouraging.

A couple of questions:

1. I think, correct me if I'm wrong, JSF's components are event-driven, 
like what Swing does, and the server-side needs the infrastructure (some 
servlets?) to handle the events. If so, I'm wondering how Struts controller 
can jell with this infrastructure.

2. Is there timetable for the publicly available spec draft?

3. Is there timetable for the Early Access impl?

I hope answering these are still within your NDA boundary.

p.s. I saw the other thread on the multi-app support you checked in. Good 
work! (Do you sleep? :) I should check it out soon.
--
John



At 09:17 pm 13-01-2002 -0800, you wrote:


>On Mon, 14 Jan 2002, John Yu wrote:
>
> > Date: Mon, 14 Jan 2002 11:13:34 +0800
> > From: John Yu <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Comptability of JSR 127 and Struts [Was: SHORT TERM PLANS]
> >
> > I'm wondering how JSR-127 will fit with Struts.
> >
>
>It's too early to know much, but I'm confident about the long term
>outcome.
>
> > While it's beyond my comprehension how JSR-127 will look like and offer, I
> > have this gut feeling that there is an architectural impedance. Frankly,
> > it's still vague to me what and how JSR-127 tries to achieve and I always
> > thought the JSR-127 effort would somehow overlap a lot with Struts.
> >
> > Can someone shed some light on this? (Martin, I think you mentioned you saw
> > the demo in JavaOne. And Craig, I think you are on the expert group?)
>
>Yes, I am on the expert group forFaces (and for the JSP Standard Tag
>Library, JSTL).  Discussions are ongoing, and good progress towards
>defining a good architecture for GUI components is being made.
>
>In general terms, I look at JavaServer Faces (and the JSP Standard Tag
>Library) as "mainstream" efforts that will, ultimately, supplant the use
>of the majority of the Struts custom tag libraries.  We'll continue to
>support the existing libraries (there are *way* too many apps using them
>to consider deprecating them :-), but I am not putting any attention on
>major functional improvements in the areas that Faces and JSTL are going
>to cover.  Instead, I'm going to be focusing my personal attention on
>things like the multi-application support (just checked in), and
>integration of the workflow project that is in the Commons sandbox.
>
>Happily, the Struts controller doesn't care what technology was used to
>create the user interface -- it deals with request parameters and request
>dispatcher forwards.  We may need to do a little bit of glue work to
>emulate some of the "automatic" interactions between form beans and the UI
>compoennts, but I don't anticipate any significant hurdles in this
>respect.
>
>I would encourage future-looking Struts applcation developers to start
>learning the JSP Standard Tag Library (JSTL) now -- you can get the early
>access release from <http://jakarta.apache.org/taglibs> -- and be ready to
>examine an early access release of Faces if and when the Expert Group is
>ready to share one.
>
> > --
> > John
> >
>
>Craig McClanahan

-- 
John Yu   Scioworks Technologies
e: [EMAIL PROTECTED] w: +(65) 873 5989
w: http://www.scioworks.com   m: +(65) 9782 9610

Scioworks Camino - "Rapid WebApp Assembly for Struts"


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

Re: Comptability of JSR 127 and Struts [Was: SHORT TERM PLANS]

[Craig R. McClanahan]

On Mon, 14 Jan 2002, John Yu wrote:

> Date: Mon, 14 Jan 2002 20:13:47 +0800
> From: John Yu <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Comptability of JSR 127 and Struts [Was: SHORT TERM PLANS]
>
>
> Thanks for your reply, Craig. Your assurance is encouraging.
>
> A couple of questions:
>
> 1. I think, correct me if I'm wrong, JSF's components are event-driven,
> like what Swing does, and the server-side needs the infrastructure (some
> servlets?) to handle the events. If so, I'm wondering how Struts controller
> can jell with this infrastructure.
>

In event processing terms, the only event that the Struts controller cares
about is a "page submit".  A GUI framework that intercepts any lower level
events it cares about, invisibly to the application, will be really easy
to integrate with.

> 2. Is there timetable for the publicly available spec draft?
>

When the expert group feels it's ready.  Prior to public draft, there will
be a "community review" period when everyone who is participating in the
JCP process (ans has signed a JPDA, as outlined at <http://www.jcp.org>)
gets to see and review it first.

> 3. Is there timetable for the Early Access impl?
>

When the expert group feels it's ready.

> I hope answering these are still within your NDA boundary.
>

How did I do :-)

> p.s. I saw the other thread on the multi-app support you checked in. Good
> work! (Do you sleep? :) I should check it out soon.

I've got one more useful new goody on my workbench - an ActionForm
implementation that uses the new DynaBean APIs in the Commons version of
BeanUtils that let you define form beans without having to write all the
properties in individual bean classes.

After that, maybe I can get some sleep.  :-)


> --
> John

Craig


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

Re: Comptability of JSR 127 and Struts [Was: SHORT TERM PLANS]

[Ted Husted]

"Craig R. McClanahan" wrote:
> I've got one more useful new goody on my workbench - an ActionForm
> implementation that uses the new DynaBean APIs in the Commons version of
> BeanUtils that let you define form beans without having to write all the
> properties in individual bean classes.

Bryan Field-Elliot is also doing some interesting, seminal work with the
(very kewl) DynaBeans as part of a persistence layer framework. 

http://netmeme.org/simper/

We're hoping to polish this up and propose it to the Commons. Bryan
doesn't have a Jakarta account right now, otherwise we'd check it into
the sandbox. 

The example uses Struts, and the DynaBeans look very sweet when called
from an Action :)

It's also filter-based, and so requires a "leading edge" container, like
Tomcat 4.0.1.


-- 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:   
For additional commands, e-mail: 

RE: Comptability of JSR 127 and Struts [Was: SHORT TERM PLANS]

[Nicholas Lesiecki]

>>It's also filter-based, and so requires a "leading edge" container, like
>>Tomcat 4.0.1.

Or Resin 2.0.5.

(Another developer-source app-server we've had luck with--an that Struts
runs flawlessly on.)

Cheers,

Nick

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 15, 2002 2:41 PM
To: Struts Developers List
Subject: Re: Comptability of JSR 127 and Struts [Was: SHORT TERM PLANS]


"Craig R. McClanahan" wrote:
> I've got one more useful new goody on my workbench - an ActionForm
> implementation that uses the new DynaBean APIs in the Commons version of
> BeanUtils that let you define form beans without having to write all the
> properties in individual bean classes.

Bryan Field-Elliot is also doing some interesting, seminal work with the
(very kewl) DynaBeans as part of a persistence layer framework.

http://netmeme.org/simper/

We're hoping to polish this up and propose it to the Commons. Bryan
doesn't have a Jakarta account right now, otherwise we'd check it into
the sandbox.

The example uses Struts, and the DynaBeans look very sweet when called
from an Action :)

It's also filter-based, and so requires a "leading edge" container, like
Tomcat 4.0.1.


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