>>>>> "David" == David M Karr <[EMAIL PROTECTED]> writes:
>>>>> "Jing" == Jing Zhou <[EMAIL PROTECTED]> writes:
Jing> The convention (see JSTL spec 2.2.1) is to use the name "var" for attributes
Jing> that export information. As I do not think <html-el:text/> should do any
Jing> export
Jing> things, we could simplify Craig's example as follows:
Jing> <c:forEach items="customers" varStatus="status">
Jing> <html-el:text property="customers[${status.index}].id"/>
Jing> </c:forEach>
Jing> Where we are only interested in the current iteration index evaluated by
Jing> an EL engine at run time and no changes are needed in the action codes.
David> It's funny to have "c:forEach" iterate over a collection, but ignore the
item,
David> which is essentially what's happening here. However, it does make sense
here.
David> Just to summarize your example, the "property" attribute will be used in two
David> different ways. It will be recursively wrapped by "${" and "}" and passed
to
David> the EL engine to get the current value, and sent "raw" as the request
parameter
David> name. By "recursive", I mean that "customers[${status.index}].id" would be
David> evaluated, resulting in (say) "customers[2].id" to get the request parameter
David> value, and then wrapped with "${" and "}" to get the current value.
Jing> Will it be possible to keep the semantics of name/property attributes
Jing> and drop the "indexed" attribute when the EL engine is available?
David> I'd like to be sure exactly what you're asking here. It's obvious that we
David> wouldn't need to use "indexed" if we directly construct the index
expression,
David> as in this example.
David> The "property" attribute could have two different interpretations,
depending on
David> whether the "name" attribute was present. The old meaning if "name" was
David> present, and the new meaning if "name" is not present. The "indexed"
attribute
David> could only be present if the "name" attribute was present.
I'm just thinking out loud here in case someone has any thoughts about where
I'm heading here.
I've realized that I can't use my strategy of having the behavior depend on
whether the "name" attribute is present. That's because there's already
conditional behavior that depends on that test, whether it checks the "name"d
form bean or the default form bean.
Therefore, I would say that "<html-el:text>" (and similar tags) wouldn't have a
"name" or "indexed" attribute. The "property" attribute (as I described
earlier) would be used both to get the current value and to specify the request
parameter name. The current meaning of the "value" attribute should still
apply (overrides the property attribute for the current value).
--
===================================================================
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]>
