struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar P Dollin <>
Subject RE: PATCH: html:cancel tag. Made a javascript version for submitt ing
Date Wed, 23 Jun 2004 18:32:26 GMT
> Speak for yourself, I use Struts-EL and JSTL quite happily.  One day I
> would like to generate XML for the "view" and use XSLT to transform it
> into HTML to which a CSS is applied, but I don't yet know how.

There are already solutions for this although this seems like a problem
waiting to happen.  I guess for certain types of thinkers using
files to write code makes sense but I don't know too many who after they
a complex xml piece of code, i.e. apache or tomcat configuration can't find
there way in it and need some other tool to sort it out.

> It would be chaos otherwise, as people introduced non-standard stuff
> that works in one browser but breaks another.  Struts also requires
> adherence to the JavaBeans specification, nobody complains about that.

I disagree about, KAOS, since the committers who have to agree that a piece 
of code is useful.  The only issue that I see is the criteria used for 
evaluation of code for committment.  I do agree that it should be possible
to write pure html 4.01 code, but not a requirement.

> Why the insistence on getting things immediately accepted into the core?
> If you put it out there, and enough people like it and use it, it will
> become a defacto standard.

Again, not to the point.  The point is that the criteria used for evaluation
of tag code is slightly off making many truly useful enhancements ineligible
for inclusion in the body of struts and limiting it's potential.

> I don't care where the tags live.  I do care that they generate clean
> HTML and don't require JavaScript.  If you want JavaScript and
> non-standard HTML, then extend the Struts tags or write your own,
> release them, and see what happens.

Obviously, I already have had to write my own tags and would like to release

them.  I don't see the point of putting them in the standard tag lib because
then they become difficult to use and I like others get discouraged posting
code that gets tossed.

Where the tags live is important because when you commit to a product like
struts, you are committing to the interfaces.  Actions, at least in my view,

are commodities, you write a couple of generic ones (save, read, etc.) and 
you are done.   The real committment to struts is in the view technology as 
there is way more struts specific view code in a typical application.  If 
the tags are disconnected from the controller as an application then the 
committment to struts is more complex.  


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

View raw message