>>>>> "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]>