> 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 configuration files to write code makes sense but I don't know too many who after they have 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. Edgar --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]