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 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]
smime.p7s
Description: S/MIME Cryptographic Signature
