For the first time in many months, there was some visible progress in theYes, the progress has been heartening. I'll throw some of my own thoughts in on your points below.
area of acceptance of submissions on tags. Thank you David and Robert.
My original reasoning for this was definitely a value judgement on the importance of portability. That's one of the keys to the value proposition for Java as a whole, and you can actually do a lot with standard (X)HTML.I do have some points that I am sure will draw fire, but I have been an idiot on this forum for so long...
1) It is fine that the basic tags in struts don't emit non-standard html,
but why do struts tags have to 'police' the emission of non-html. For many
intranet style projects, non standard html is important to achieve specific
required functionality. To deny the need for such code seems strange.
From a Struts developer perspective, the policy also makes it very easy to decide whether or not proposed attributes should be added. Just look them up in the relevant specs, and add the new ones if we missed them the first time, or "just say no" otherwise. No muss, no fuss.
But there's no such thing as being "half pregnant". Either we stick with the standards or we don't. If we were to go the other way, there would be no reasonable technical justification for omitting *any* element or attribute that is supported by *any* browser. If the attributes are there, people will use them ... most of the time without thinking about portability at all, and we lose out on part of our portability claim for Struts apps. That would not be good.
Here's what I would suggest for people that really don't care about the portability issues and would want extended tags:
* Tell us *exactly* how to refactor the existing tags to make them easier to subclass. Patches talk louder than whines :-). Especially when there has been a *lot* of improvement between 1.0 and 1.1 in this regard. Want proof? Building the struts-el library would have been much more difficult on the 1.0 code base than it was this time.
* Build up your own extension tag libraries that add whatever attributes you want. We'll publish pointers to 'em in the resources pages. If committers are willing to support them, I'm even OK with such tags in the "contrib" directory (but SourceForge works too).
As long as my vote counts here, I'm still not in favor of violating the "standard attributes only" policy for the core tag libraries packaged with Struts. Extension libraries that want to do this, however, are OK with me.
2) It baffles my mind why struts insists the tags be so minimalistic andThe fundamental issue here is that Struts does not have a user interface component model, so there is no basis for a Struts-hosted tag library that does the more complicated things like grids, trees, calendars, and the like. On the other hand, there is also no reason you can't use someone else's complex layout tag libraries in a Struts based application, just like you can use whatever persistence tier APIs you like. Why should it *have* to be part of Struts?
non-creative. I am aware of the difficulties in writing tags with the weird
life span and semi random instantiation patterns and the bugs that are
almost endemic with custom tags. But simple tags like java-script assisted
date entry are so basic that simple implementations should be part of
struts. Many of us have implementations of this (i.e. Matt Kruse's date
functions) but there would be no hope of a submission passing muster.
As for me personally, I'm building just such a user interface component model (I'm co-spec-lead for JavaServer Faces), and plan to use those components, with Struts, once it goes final. The component model here is precisely aimed at making it easy to build both simple and complex UI widgets of the type you describe, without restricting yourself to only running them on a single MVC controller framework.
<soapbox>
I'm continually surprised by how many people keep asking "how do I do X in Struts", when X is something that is perfectly doable with standard servlet/JSP APIs, or with easily integrated class or tag libraries. There seems to be an unspoken assumption that, if it's not included in the app framework I'm using, then I can't (or perhaps shouldn't) be using it. I think this is a slippery slope; it puts you at substantial technical risk if your chosen framework does not expand ahead of (or at least in parallel with) your needs.
You're much better off mixing and matching technologies to meet the particular needs of each particular application's requirements. The extra pain of integration is wel worth it for the additional flexibility and the lower dependency risks.
</soapbox>
If it were still three years ago, or if JavaServer Faces didn't exist, then I'd be in hearty agreement with you that Struts should focus on improving the HTML tag library. Neither of those is the case, however; so, in the time *I* have to devote to Struts, it's going to be spent on other things.
3) Lastly, there are certain class of business information that the viewI'd need to see a more detailed description of what you're thinking about to know whether it would fit in, but I assume you're talking about something more than the "disabled" and "readonly" attributes that already exist?
needs, i.e. readonly, size. The tags should have to ability to easily pass
this information from the business tier to the view. Again, the hope of a
submission relating to this type of extension being accepted seems iffy,
especially since generalizing a specific implementation is a bit of effort.
EdgarCraig
-----Original Message-----
From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2003 5:07 PM
To: Struts Developers List
Subject: Re: Editable Fields V/S Static Text
David Graham wrote:
There are 3 things that earn my -1 on tag enhancements:Just as an aside, I believe by -1 David means that he won't volunteer his own time to the issue. As a volunteer, this is his absolute right. But, since the Struts minimum platform doesn't support JSTL, this point alone would not be a justification for a "product change" veto.
1. Functionality already provided by the JSTL.
2. Functionality that supports non-standard HTMLgeneration. 3. Tags
that don't tie into the Struts core functionality. Theseare better
suited for the Jakarta Taglibs project.However, IMHO, these would be technical justifications for a -1 veto =:)
-Ted.
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
