The way we've handled this in the Beehive/NetUI tags is to have a <netui:attribute> tag which can be nested inside of other NetUI tags to extend the containing tag's attribute set. The <attribute> tag adds an arbitrary name / value pair that is written when the tag renders.
So, something like this:
<netui:textBox dataSource="actionForm.name">
<netui:attribute name="foo" value="bar"/>
</netui:textBox>will render:
<input type="text" ... foo="bar"/>
which could be used to support IE specific data binding features, for example.
The benefit is that developers can render any attribute but the TLDs stay pure relative to the HTML / XHTML specs.
FWIW...
Eddie
Joe Germuska wrote:
At 10:14 AM -0400 10/20/04, Kichline, Don \(EM, PTL\) wrote:
Not to be rude, but guess what, not every struts application runs on the internet for absolutely anyone to use.
...
I am working with what I was handed.
Good points. Have you seen Niall's post (to [EMAIL PROTECTED] only, I believe) wherein he points out that he has done some refactoring that should make it fairly straightforward for people to write custom tags which support non-standard attributes?
I don't think that adhering to standards is merely a factor of idealism or "high-horsedness" ;-) It is important to have a clear place to draw some kinds of lines, and particularly with JSP custom tags, where each added attribute adds maintenance (because attributes must be declared in the TLD) and clutters the already verbose documentation (not that I think it's *too* verbose).
I think it's great that Niall has figured out a way to provide extensibility where it is clearly sometimes needed. I also think it's appropriate that non-standard tags stay out of the Struts core.
Now, if someone wanted to take advantage of the route Niall provides and build a distribution of Struts taglibs that supported non-standard tags, I wouldn't object to making that available via the Struts SourceForge project. Personally, I don't think I'd even object to making it a Struts sub-project that was available but clearly distinct from the core and the base taglibs -- but some other committers might. In any case, I'd probably think it deserved "incubation" at struts.sf.net since if none of the current committers (myself included) are motivated to support code for non-standard tags, it would be a shame to adopt it without some clear community of developers who were committed to it. The Struts SF project provides a place for that community to develop.
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
