I absolutely agree, I am actually in the process of writing a tag library that is based on the old struts 1 tags but supports OGNL and JSP EL (without any of the overhead of FreeMarker). It was a bit daunting trying to figure out some of the in's-n-out's to get access to the guts of Struts 2/XWorks but I think it's coming together nicely.
I think these tags could be very useful for anyone porting an existing application from S1 to S2. They are not drop replacements, just very similar, but having them co-mingled with the current core tags (if that were ever an option) would probably be more confusing than helpful. If the user could choose the struts-core-taglib-2.1.jar file or the struts-transitional-taglib-2.1.jar file it would be more obvious. (*Chris*) On 10/4/07, Don Brown <[EMAIL PROTECTED]> wrote: > The discussion around WW-2149 [1] has been interesting as it exposed > quite different philosophies with regards to Struts 2 tags. One > thought is Struts 2 should have lots of tags in its core as they are > used by lots of people. On the other hand, other folks (me) think > Struts 2 should keep core very small and have most new tags as > plugins. > > I'm gonna take it to the next level and suggest that our tags should > be their own plugin. Core would have the basic framework for creating > tags such as the TemplateManager, Component base classes, etc., but > the tags themselves would go into a plugin. I think this would be > great for several reasons: > > 1. Much, much less code in core to maintain > 2. Encourage multiple tag libraries (I, for one, would love to see a > simple, high performance (read non-Freemarker/limited EL) library) > 3. Force us to improve our tag pluggability for plugin authors > > Moving the tags out of core would not be unprecedented. Several years > ago, we moved the Struts 1 tags into their own subproject, a move that > had its hiccups, but ultimately, I think it proved useful. > > The new tags plugin, perhaps named struts2-tags-plugin, would still > remain in the Struts 2 repository and be bundled with every release, > just like in Struts 1. For a user, there would be one more jar, but > no other impact. > > The bottom line is I believe, in an open source project with limited > resources like Struts 2, we need to pick our battles, or code as the > case may be. We can't properly support all our existing code with the > same attention, but by carving out logical sections, we can identify > clear areas that we can ensure will receive the support it needs. > > Don > > [1] https://issues.apache.org/struts/browse/WW-2149 > > --------------------------------------------------------------------- > 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]
