I am trying to be more constructive, see my thoughts below.
----- Original Message -----
From: "David M. Karr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 26, 2002 1:16 PM
Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
> >>>>> "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).
>
There could be a way to enhance the current html tags while keeping the
semantics of "name", "property" which is one of beautiful things
in Craig's original thinking.
Suppose we define EL based name, property by attributes
_name, _property and initialize them to be null. Then we could have
protected String _name = null;
public void setName(String name) {
this._name = name;
}
protected String _property = null;
public void setProperty(String property) {
this._property = property;
}
public int doStartTag() throws JspException {
if (_name == null) {
name = Constants.BEAN_KEY; // so we do not need to initialize name
to be a non-null value any more
} else {
name = (String) ExpressionEvaluationManager.evaluate("name", _name,
String.class, this, pageContext);
if (name == null) {
name = Constants.BEAN_KEY;
}
}
if (_property == null) {
// throw new JspException("error message") or keep it depends on
particular tag implementations
} else {
property = (String) ExpressionEvaluationManager.evaluate("property",
_property, String.class, this, pageContext);
if (property == null) {
// some decisions here
}
}
...
// make sure all RequestUtils.lookup will see only evaluated name,
property, scope
Object value = RequestUtils.lookup(pageContext, name, property, null);
}
Sometimes ago, I was trying to figure out if I could have a "compact"
attribute which
combine name/property/scope altogether when I design my UI. When I saw above
possibility, I feel it is not a good idea to combine them into one
attribute, because:
1) The combined attribute could not provide enough additional power I could
buy:
End users could put a tag in multi-level loop like this:
<html-el:text name="some_name[${loop1Status.index}]"
property="p1[${loop2Status.index}].p2[${loop3Status.index}].p3" />
2) If using combined attribute, I have to delemite the attribute into name,
property
again, which cost unnecessary CPU time and depend on end users correct
input.
I am very concerned about user experience: think about an UI for City,
State, Zip code,
How would you feel if a site give you only one text field to input the
city, state, and zip code? It will depend on the end users to input them in
correct
order with correct delimiters, it also need developers to parse the
attribute into
correct tokens. It will not be a good UI design.
So in general I hope the community could come out a design that keeps the
original
beauty of Struts and even the design could enhance the current html tags
without
having to create a "parallel" library in the end (Did someone say that
before?)
> --
> ===================================================================
> David M. Karr ; Java/J2EE/XML/Unix/C++
> [EMAIL PROTECTED]
>
>
Jing
> --
> 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]>
