Is the struts-el taglib now actually broken because html:link gained a missing property? Or does it simply fail to meet one of our expectations for the taglib?
I am of the opinion that all the taglibs should be packaged separately. In this way, that fixes and enhancements that do not affect the core Action and Config packages could be released more easily. The conventional taglibs have stayed put so far since they arguably do no harm and provide a convenience to a great many users.
But we now have the situation where you would be obligated to vote against a release because changes to one package where not reflected in another package, which at this time lives in the contrib folder. I submit this that this is the type of coupling that MVC was invented to defeat, and that we not taking our own advice =:0)
Craig plans on releasing the Struts-JSF tablib separately, why can't we do the same with Struts-EL?
-Ted.
David M. Karr wrote:
I guess my only problem with this argument is that Struts-EL releases have to be closely tied to Struts releases. It doesn't just "use" Struts, like other contributions, it's interface has to exactly mirror the Struts interface. Except for some occasional minor bugs I've found in Struts-EL, the only real changes I've had to make were to reflect changes to tag attributes in the base library. Once Struts 1.1 is released with Struts-EL, I'm not sure I'd want to make any more releases of Struts-EL, until the next Struts release (unless I find any non-interface problems). If I made a Struts-EL release reflecting changes to the Struts nightly build (after 1.1), then we'd have the situation of a Struts-EL release which had to be used with a nightly build of Struts, and not the latest release.
-- Ted Husted, Struts in Action <http://husted.com/struts/book.html> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
