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
