On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote: > As I've been saying (a lot, it seems, lately) on struts-user, I > think there are legitimate Struts JSP tags like "html:messages" > that are not best replaced by JSTL. Any time Struts tools put > resources in special locations in request or session scope, I think > it's nice to have tags which know the special locations, instead of > expecting people to dig in and find them. And, for example with > html:messages, the message-property filtering is a useful feature > that would require a lot of verbose JSTL to achieve the same goal.
Another way to go would be to provide a "API object" in the request that the tags, or any other presentation technology, could use to access framework resources. In this way, no one else would need to the various special locations, only where to find the API object. This was the idea behind the "ConfigHelper", which we put together when the Velocity/Struts tools was first being discussed. http://tinyurl.com/yshnp It's never been updated for modules, but if it were, the idea would be that it would return references to whatever resources were appropriate to a given module. >From the perspective of a presentation technology, regardless of its nature, the >ConfigHelper (or ActionContext) would be Struts, in the same sense that a JBDC driver >appears to be the database. (Adapter/proxy patterns.) On Thu, 25 Mar 2004 20:09:08 -0800 (PST), David Graham wrote: > Are we really still kidding ourselves that the taglibs are > currently supported? No committer actively takes care of them. No > one in the community responded to Ted's invitation to support them. > We've all moved onto JSTL, JSF, Velocity, XSLT, etc. While the > rest of the world migrates to newer/better technologies, we're > stuck supporting tags that fewer and fewer people actually use. I don't use them myself, but I still know people who do. And some of those people help pay the bills :) I have and will support them by applying patches that people provide, as we just did by adding the module parameter. Moving the taglibs to their own subproject (at last!) will make a significant difference, since what does or does not happen with opt-taglibs won't directly affect core. If we moved to a context-based architecture (as above), it would help decouple the taglibs from the core, so the subprojects could be more independent, and level the playing field for other technologies. And, I'd do whatever it took to refactor the classic taglibs. > IMO, it's almost irresponsible to distribute <logic:iterate> with a > Struts minimum Servlet level of 2.4 where <c:forEach> is available. Things may change this year, but last summer I was still finding people at very large corporations who hadn't migrated to servlet 2.3. So, c:forEAch was not available to them. Hopefully that will change this year, and we'll find nearly everyone has finally found the budget to upgrade. Though, that's not going to get us off the compatibility train. The next thing will be whether they support servlet 2.4 for Struts 2.x :) Pity the world can't download Tomcat and be done it :( :) -Ted --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
