Hi Don,
My experience with the Struts2 tags has been fairly negative, mainly
due to the UIBean base class. It's a fragile base class scenario in
which you must extend UIBean if you want the benefit of the
TemplateEngineManager, but UIBean contains a lot of crud that isn't
applicable to its subclasses.
eg.
1. UIBean includes a property for every html attribute and tooltips
etc. When these aren't applicable to subclasses they have to be
overridden and/or removed from the TLD (manually)
2. UIBean is tightly coupled to the TemplateEngineManager. It seems
you can't create tags that utilise Struts2's template/theme feature
unless you subclass UIBean
3. UIBean is tightly coupled to the OGNL expressions (a parent class
performs the expression evaluation)
There's also a lot of boilerplate code required in the current
implementation (the Component impl, the Tag impl, the Velocity
Directive and the FreeMarker TagModel).
Therefore I would say the design is not solid. It's a reasonable
basis though. When I last looked, I thought the TemplateEngineManager
could be refactored to accept an interface to something that has
properties (the tag and context) and can resolve expressions rather
than invoking methods directly in UIBean to do this. As I dug deeper
it got too hard.
Additionally the theme system is not solid due to frequently discussed
issues with ${parameters.theme} within nested templates. Hard-coding
parent theme names within templates and duplication of templates for
every new theme is necessary (theme inheritance doesn't work as one
would expect). There's no easy fix to that.
cheers,
Jeromy Evans
On 12/08/2009, at 12:19 AM, Don Brown wrote:
At Atlassian, every application seems to have picked a different web
framework and template engine to use. As we are finally starting to
do some common UI work, I'm wondering if the Struts 2 tag library
framework is worth basing our tag library on. Assume it wouldn't be
too hard to extract mostly as-is:
* Is the design solid?
* How limiting do you find it over native tags/macros in the
respective template engines?
* How useful is the theme system really? For example, properties that
are only used by some themes are confusing and error-prone.
* Any performance bottlenecks outside all the OGNL usage?
* Would Struts be interested in the result?
The benefits I see are:
* Support for Velocity, Freemarker, and JSP
* Overridable, customizable Themes
* Ability to plug in a new template engine
* Generated tld and docs
While I've worked a bit on the tags from a struts dev pov, I've
haven't used them much myself. My gut feel is it would be worth it in
the short and long term, however I remember some discussion about
their design and value, so I'd like to revisit those concerns.
BTW, was digging around in the javatemplate stuff...very impressive!
It is cool to see simple prototype code turned into a full featured
library. Any thoughts on how that sax-like design worked out? Should
it have been a more DOM-like object model instead?
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
