----- Original Message -----
From: "David M. Karr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 22, 2002 11:45 PM
Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
> >>>>> "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).
The convention (see JSTL spec 2.2.1) is to use the name "var" for attributes
that export information. As I do not think <html-el:text/> should do any
export
things, we could simplify Craig's example as follows:
<c:forEach items="customers" varStatus="status">
<html-el:text property="customers[${status.index}].id"/>
</c:forEach>
Where we are only interested in the current iteration index evaluated by
an EL engine at run time and no changes are needed in the action codes.
Will it be possible to keep the semantics of name/property attributes
and drop the "indexed" attribute when the EL engine is available?
Jing
>
> (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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
