Future of UIBean

[Jeromy Evans <je...@blueskyminds.com.au>]

Is anyone actively thinking about the future of UIBean?

This class has several features that I find immensely frustrating as a user:
  1. UIBean includes a property for every imaginable html attribute and 
tooltips etc.  When these these aren't applicable to subclasses they 
have to be overridden and/or removed from the TLD
  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)
  4. They're extremely troublesome to unit test due to #2 and #3

#3 is fundamental and I don't think it's worth the effort to refactor 
UIBean to be EL-independent. Rather creating a new base class would be 
easier
#4 can be eased by moving some of the existing base test classes into 
core (eg. dojo plugin includes the necessary tools in its own test 
source branch)
#2 is my priority - if there were an interface for a "Templatable 
Component" that the TemplateEngine's used rather than UIBean directly 
this would be resolved, although when I last checked even this was a 
non-trivial change
#1 wouldn't be a problem if #2 was solved. 

Whenever I've tried to "fix" it I feel like I'm pulling at an endless 
piece of string.  My efforts have always unravelled and I've fallen back 
to a work-around of a "naked" UIBean for my own Component-based tags.

I suspect UIBean may be a lost cause?  I mean it does the job well for 
the existing tags (except the known template inheritance issues) but it 
can't readily budge from the existing design without severely breaking 
every existing subclass (the fragile base class problem).  Have the 
efforts to create tags for other EL's addressed this?  Are there any 
thoughts on the direction of UIBean?  Or have I missed something?

regards,
 Jeromy Evans


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org