----- Original Message -----
From: "David M. Karr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 01, 2002 11:55 AM
Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
> See comments below.
>
> >>>>> "Jing" == Jing Zhou <[EMAIL PROTECTED]> writes:
>
> >> Therefore, I would say that "<html-el:text>" (and similar tags)
wouldn't
> Jing> 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
> Jing> request
> >> parameter name. The current meaning of the "value" attribute
should still
> >> apply (overrides the property attribute for the current value).
>
> Jing> There could be a way to enhance the current html tags while
keeping the
> Jing> semantics of "name", "property" which is one of beautiful things
> Jing> in Craig's original thinking.
>
> Jing> Suppose we define EL based name, property by attributes
> Jing> _name, _property and initialize them to be null. Then we could
have
>
> Jing> protected String _name = null;
> Jing> public void setName(String name) {
> Jing> this._name = name;
> Jing> }
> Jing> protected String _property = null;
> Jing> public void setProperty(String property) {
> Jing> this._property = property;
> Jing> }
> Jing> public int doStartTag() throws JspException {
> Jing> if (_name == null) {
> Jing> name = Constants.BEAN_KEY; // so we do not need to
initialize name
> Jing> to be a non-null value any more
> Jing> } else {
> Jing> name = (String)
ExpressionEvaluationManager.evaluate("name", _name,
> Jing> String.class, this, pageContext);
> Jing> if (name == null) {
> Jing> name = Constants.BEAN_KEY;
> Jing> }
> Jing> }
> Jing> if (_property == null) {
> Jing> // throw new JspException("error message") or keep it
depends on
> Jing> particular tag implementations
> Jing> } else {
> Jing> property = (String)
ExpressionEvaluationManager.evaluate("property",
> Jing> _property, String.class, this, pageContext);
> Jing> if (property == null) {
> Jing> // some decisions here
> Jing> }
> Jing> }
>
> Jing> ...
>
> Jing> // make sure all RequestUtils.lookup will see only evaluated
name,
> Jing> property, scope
> Jing> Object value = RequestUtils.lookup(pageContext, name,
property, null);
>
> Jing> }
>
> Jing> Sometimes ago, I was trying to figure out if I could have a
"compact"
> Jing> attribute which
> Jing> combine name/property/scope altogether when I design my UI. When
I saw above
> Jing> possibility, I feel it is not a good idea to combine them into
one
> Jing> attribute, because:
>
> Jing> 1) The combined attribute could not provide enough additional
power I could
> Jing> buy:
> Jing> End users could put a tag in multi-level loop like this:
>
> Jing> <html-el:text name="some_name[${loop1Status.index}]"
> Jing>
property="p1[${loop2Status.index}].p2[${loop3Status.index}].p3" />
>
> I guess you've partially lost me. Would the alternative for point (1) be:
>
> <html-el:text
property="some_name[loop1Status.index].p1[loop2Status.index].p2[loop3Status.
index].p3"/>
>
> ?
>
> Which are you saying is preferable?
I prefer it in the format <html-el:text name="some EL expression"
property="other EL expression"
readonly="another EL expression"
... />
In the example, the "some_name[" and "]" in the name attribute are
pass-through string literals.
"${" and "}" can not be removed from there. The same rule applied to the
property attribute.
But if you do this: property="${some_name[loop1Status.index]...}" that
is a different thing.
>
> (Will the ActionForm processing successfully parse that "property" value
so the
> value can be set in the ActionForm?)
>
> Jing> 2) If using combined attribute, I have to delemite the attribute
into name,
> Jing> property
> Jing> again, which cost unnecessary CPU time and depend on end users
correct
> Jing> input.
> Jing> I am very concerned about user experience: think about an UI for
City,
> Jing> State, Zip code,
> Jing> How would you feel if a site give you only one text field to
input the
> Jing> city, state, and zip code? It will depend on the end users to
input them in
> Jing> correct
> Jing> order with correct delimiters, it also need developers to parse
the
> Jing> attribute into
> Jing> correct tokens. It will not be a good UI design.
>
> Sorry, I don't understand. I'm not sure what you mean by "delemite the
> attribute into name, property again". How does this depend on the end
user's
> correct input? Are you talking about the programmer, or the user of the
> application?
A spelling error (should be delimit).
Assume someone is still using RequestUtils.lookup() to retrieve
value given form bean name and property when rendering the JSP pages, he
needs seperated name and property passed in the tag functions. In your
alternative
example, how do I figure out which part is for the orginal name attribute,
and
which part is for the orginal property attribute? The first dot "." will not
help
me to delimit the attribute into name/property pair. And if I got the
following
expression:
property="${foo[i].a.b.[j]}"
I could not tell which part is for name at all.
Thinking about the assumption on using RequestUtils.lookup(), assume
somebody has a function that can take one argument, say "property", and
return
an object value. Somehow, he has to parse the argument to figure out the
JSP scoped attribute from it (which is exactly purpose of the name attribute
in
Struts today) and the function will eventually call a function like
RequestUtils (maybe just a different function name)
So the parsing (from one argument into two at least) will cost unnecessary
CPU time
since we already have seperated name/property pair today. Why not just
use it?
I could be wrong. But I would like to be first convinced there is a function
that
is faster than RequestUtils in principles and I could buy additional power
when using seperated name/property expressions could not achieve. It is not
an easy task for me to prove the two points.
>
> Jing> So in general I hope the community could come out a design that
keeps the
> Jing> original
> Jing> beauty of Struts and even the design could enhance the current
html tags
> Jing> without
> Jing> having to create a "parallel" library in the end (Did someone
say that
> Jing> before?)
>
> The only constant is change. There is movement towards using the JSTL.
The
> goal is to eventually have a Struts tag library that works cleanly with
the
> JSTL. This "parallel" library is only a transition strategy.
That will be very cool if "-el" could be dropped eventually from the prefix.
>
> --
> ===================================================================
> 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]>
