You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Hablutzel, Robert" <Ro...@LibertyMutual.com> on 2003/12/20 02:33:56 UTC

Configuring tags from bean properties - Bugzilla 25671

First off, I'm new here, so if I breech etiquette please let me know.
 
I just submitted an enhancement request (Bugzilla 25671). This note is to give some background information for that request.
 
I work in a regulated industry. This has the effect that our business process is (slightly) different in different jurisdictions. For example, coverages we are required to provide in some states are optional in others. This isn't significant to our business process, but it does drive changes to our UI/presentation (among other things). In jurisdictions where coverages aren't allowed, we don't display the coverage choice to the user.
 
It gets even more complex than that. The range of possible values, default value, label, and even the actions that occur when items are selected can all be changed jurisdictionally - or may depend on earlier stages of the process. It is complicated enough that encoding all the possible combinations in hard-coded JSPs is a maintance nightmare.
 
We are currently looking at the viability of using Struts for our next generation application, rather than our current custom (in-house) solution. Determining the values to display (text, show/hide, subsequent actions and so forth) isn't in scope of the Struts layer - we are looking to a rules engine such as Jess for this. What is in scope is the need for the Struts tags to be reactive to the calculated values.
 
So say out of the Jess layer we get a bean with all the attributes we need to populate an html:text field. We can certainly do this today, with expression language constructs. The example I gave from the bug report was as follows:
 
   <html:text name="<%= bean.getName() %>"
              property="<%= bean.getProperty() %>"
              value="<%= bean.getValue() %>"
              onchange="<%= bean.getOnchange() %> 
              ... and so forth ... />

This gets a little messy when lots of attributes are involved.
 
The proposed covered by 25671 is to extend the tags with the ability to retrieve attributes from a supplied Java bean. The attributes would be matched name for name with the properties on the bean - any missing values from the bean would be defaulted or supplied by the tag. So the resulting code from the example above would become:
 
    <html:text propertyBean="bean"/>
 
In this case, the bean would be introspected. The properties name, property, value, onchange and so forth would be uncovered, and those that returned not-null values would be used as the values of the html:text tag. The resulting JSP is considerably shorter and easier to read and maintain. (Remember that the values being supplied are no more visible to the developer at develop time with the older syntax - they are still encapsulated within the bean properties.)
 
I believe (without looking at the code) that this would be a relatively trivial extension to the tag libraries. I would even be willing to take a crack at the implementation if that helped the adoption.
 
I would be happy to discuss this further and try to answer any questions.
 
Thanks,
 
hab