I would very much like to be able to extend the tags in a plugin. But how do we keep the tld file(s) in sync? If there's going to be several tag projects, there's going to be confusion if they all define their own attributes and tags. There should at least be a minimum requirement of common tags and attributes that should be maintained in a "parent" tag project.
Nils-H On 10/5/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]
