>>>>> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
Craig> I've been thinking about this issue as well, as you might imagine.
Craig> For general form field properties, I'm assuming that we would have to make
Craig> the existence of the form bean explict -- say, for example:
Craig> <html-el:test var="${logonForm.username}"/>
Craig> instead of assuming that you could just use username and "know" that it
Craig> was resolved against the form bean in the surrounding scope. The property
Craig> name can either be inferred from the expression (i.e. after the first
Craig> period), or we could allow an optional "property" attribute that would
Craig> provide the field name for the rendered <input> field.
I'm very hesitant to start parsing the EL string, as there's a lot of different
ways to form a legal expression, and I don't want to try to restrict the form
of the EL expression in these situations.
We could of course have the "var" attribute be an EL to get the current value,
and have the "property" attribute be the "name" attribute in the generated
HTML, but then you have a disconnect between the value and the name, whereas
the current "name/property" pair allows a clean specification of both the
current value and the request parameter name.
Craig> For indexed things, remember that the subscript in an EL expression can be
Craig> a variable. So something like this should work, where "customers" is an
Craig> array of customer objects, and we're inside a form with a field per
Craig> customer account number:
Craig> <c:forEach var="customer" items="customers" varStatus="status">
Craig> <html-el:text var="${customer.id}"
Craig> property="customers[${status.index}]"/>
Craig> </c:forEach>
Craig> could do the trick, as long as you scanned both the "var" and "property"
Craig> attributes for expressions.
Yes, I had considered the array index possibility. This will provide more
flexibility, allowing the case of two nested "iterate" tags, and you want the
"property" attribute of the HTML tag to come from the OUTER iterate tag (which
someone on "struts-user" just asked about today).
However, in the general case, we're still having the users specify more, and
redundant information, just to avoid the use of the "name/property" pair.
I guess we could provide two ways to do this:
If the "name" attribute is present, the "name" and "property" are combined as
usual. However, if the "var" attribute is present, in place of the "name"
attribute, then the "var" value is used for the current value, and the
"property" attribute is used as the entire "name" attribute (of the generated
HTML).
(It's certainly confusing to have the "name" attribute mean two different
things, one in JSP, and the other in HTML).
Unfortunately, a change like this will require changing the base Struts tag.
In the case of "CheckboxTag" (and probably others), the current value lookup is
done directly in its "doStartTag()" method, with no comparison of "value"
against null check to bypass it (which is the case in other tags, like "size"
and "message", for instance).
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
