I think I'm coming at this from a different perspective than you :-)Unless you are using some alternative tag library for rendering your markup, such as the struts-faces library when it is done, or any other HTML rendering tag library that someone wanted to adapt (as needed) to work on top of Struts.
The acid test for me is whether you could sensibly create a Struts app
without using the tags (just talking JSP here). While you can get by without
bean or logic tags, I still feel that many of the html tags are *necessary*
for use in a Struts app.
More below...From the perspective of deciding this, it's useful to divide the struts-html tags into two categories -- those that are just "translate JSP tag attributes into corresponding markup" and those that are dependent on Struts core internals. In the latter category, you'll certainly find <html:form>, which has the machinery for automatic creation of a form bean. Indirectly, then, you'll also find that all the input field tags (button, cancel, checkbox, file, hidden, image, multibox, password, radio, select, submit, text, textarea) are dependent, because they depend on <html:form> to provide the base form bean against which property names are resolved.
-----Original Message-----
From: Ted Husted [mailto:[EMAIL PROTECTED]...
Jakarta Taglibs maintains a Dreamweaver extension, why could they not
maintain a Struts extension?
They could but, because JSP is the most common view technology, I think Struts would be diminished without the html tag library.
Likewise, Jakarta Velocity maintains a Struts extension. Should we ask
Nathan Bubna et al. to bring that here because it is dependent on Struts?
But it's also dependent on Velocity :-) I think the need arose from users of Velocity wanting to use Struts rather than the other way round. I think it probably adds more value to Velocity than Struts and, you've pointed out, that's were the developers are.
The new Commons Chain package supports extensions for Servlets,
Portlets, and JavaServer Faces, which are technologies not maintained by
the Chain team.
That's not really the same. Struts would depend on Chain, much as it now depends on other commons packages. Chain is useful in many other situations that don't include Struts. That's not *currently* the case for the taglibs.
My view is that Struts taglib (html) depends on Struts *and* Struts depends on the tags. It's that co-dependency that leads me to think they should stay together.
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.
And I think that the Struts project is where the maintainers of the Struts taglib are / will be :-) Changes to the tags will be as a result of changes to Struts and it requires an understanding of the internals of Struts to effectively support the tags. ...
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.
That's a very definite possibility. If we can decouple the tags from Struts
so that they could be used independently *then* it would make sense to treat
them as a generic tag library. I would support moves in that direction, I
just don't think they're ready to stand on their own two feet *yet*.
Less fundamental linkages, but real nevertheless, can be found in the errors, link, and messages tags. That doesn't leave a whole lot.
Of course, the whole discussion of migrating tag libraries elsewhere is totally academic unless there is someone who wants to *do* it instead of just talk about it. In the absence of that, there's nothing wrong with leaving them exactly where they are.
Agreed ... personally, I'm working on a different solution (than the Struts html tag library) to that problem :-).
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.
I'm still happy to be in the view business, but I do think that decoupling
the controller from the view would be A Good Thing.
SteveCraig
---------------------------------------------------------------------
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]
