I wasn't saying that the existing tags can't or shouldn't be extended. Just that IMO the core Struts tags shouldn't be moved to somewhere like Jakarta Taglibs, because they are dependent on Struts.
Jakarta Taglibs maintains a Dreamweaver extension, why could they not maintain a Struts extension?
Likewise, Jakarta Velocity maintains a Struts extension. Should we ask Nathan Bubna et al. to bring that here because it is dependent on Struts?
The new Commons Chain package supports extensions for Servlets, Portlets, and JavaServer Faces, which are technologies not maintained by the Chain team.
IMHO, it's not a question of technology. It's a question of community support. If the people who actively maintain these tags wanted to maintain them at Jakarta Taglibs, there's no technical reason to keep them here. Conversely, there's no technical reason to move them either. It's just a matter of where the people doing the work want to do the work.
All things remaining equal, I'd suggest that the Struts taglibs are more about taglibs then they are about Struts. They know how to find resources provided by the Struts framework, but after that, virtually all of the coding issues are related to the taglib and HTML specifications, not to the Struts Controller.
When Geir and I bootstrapped the Velocity Tools for Struts initiative, we did discuss whether it should be maintained here or there. In the end, we decided that by maintaining the Tools at Velocity, they would be exposed to the true Velocity experts, and that was a Good Thing. If Struts were doing it's job, hooking up that end of it should be the easy part. And it was.
By the time version 1.0 of Tools launched, there were multiple tools sets: a generic set that could be used by most any web framework or application, and a smaller set on top of that specialized to Struts. As a result, the Tools are not only useful to Struts people, but now make Velocity easier to use within other frameworks as well. [Now, *that's* sharing the wealth :)]
From a community standpoint, most of the taglib support issues are not about Struts, but about using taglibs generally. When JSTL and JSF catches on, this is going to be more and more the case. Not only will we have to support Struts, but we have to support JSTL and JSF as well.
And what do these tag libraries really do anyway? They look up resources from predetermined locations, use them as parameters, and emit HTML. Right now, many of the resource locations are hardwired to use the Struts defaults. But, if they were exposed to a broader community, and configurable factory methods were used, that could change. There could a generic html library that didn't care about Struts, and then a specialized one that utilized the Struts defaults. This strategy works well for the Velocity Tools and should work just as well for taglibs.
We keep saying that JSTL has no corollary to the html taglibs. Well, maybe then it needs one. :) We moved BeanUtils and friends to Commons, and I can't even count how many projects use these utilities now. Maybe we should do the same with the html tags. The problems we are trying to solve are the same problems everyone else is trying to solve. We shared the wealth with Commons, maybe its time to do the same with Taglibs.
But, hey, I'm not a taglib guy, and I'm not going to be doing the work, so it's not my decision. =:) I just want to be sure that them that does the work and make the decisions are aware of their options.
We scuttled Generic Datasource to get out of the Model business, and, volunteers willing, maybe it's time to get out of the View business too.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
