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

It's funny to have "c:forEach" iterate over a collection, but ignore the item,
which is essentially what's happening here.  However, it does make sense here.

Just to summarize your example, the "property" attribute will be used in two
different ways.  It will be recursively wrapped by "${" and "}" and passed to
the EL engine to get the current value, and sent "raw" as the request parameter
name.  By "recursive", I mean that "customers[${status.index}].id" would be
evaluated, resulting in (say) "customers[2].id" to get the request parameter
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?

I'd like to be sure exactly what you're asking here.  It's obvious that we
wouldn't need to use "indexed" if we directly construct the index expression,
as in this example.

The "property" attribute could have two different interpretations, depending on
whether the "name" attribute was present.  The old meaning if "name" was
present, and the new meaning if "name" is not present.  The "indexed" attribute
could only be present if the "name" attribute was present.

This would provide a transitional strategy, even while using the Struts-EL
library.

I'm still bouncing around these ideas in my mind.  Any other affirmation or
rejection of these ideas would be useful, at least.

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

Reply via email to