On 10/5/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > > > I've brought this up before and in a few bug reports but I think that > fundamentally fixing the issues that exist with FreeMarker, the tags and > OGNL is more important than ripping them out and allowing pluggability. > Also, in my not humble opinion, heading back to JSPs seems like just a > step in the wrong direction. > > Let's say that FreeMarker and OGNL were perfect for everything (I know a > stretch, but let's assume), what does removing the tags offer? It > reduces some coupling (good). It provides a better managed dependency > (both good and bad). Anything else?
It allows the people who don't use them to leave the clutter out of their apps. An increasing number of people are building apps in pure DHTML, Flex or AIR, and simply have no need for server-side rendering at all, let alone tag libraries. -- Martin Cooper It seems that there is no reason that plugins can't provide new tags and > alternate tags while still providing a good base of tags within the core > distribution. > > I guess my only fear is that S2 will become much more difficult to "get > into" when new users now have to understand multiple plugins just to get > an app up and running. The uber struts.jar solution helps to some > degree, but is just hiding the complexity, which once exposed (due to > core bugs, plugin bugs, plugin incompatibility, dependency conflicts, > etc, etc.) could alienate new users. > > -bp > > > > Don Brown 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] > > > > > > >
