See intermixed (well, it's really at the bottom).
On Thu, 1 Aug 2002, Jing Zhou wrote:
> Date: Thu, 1 Aug 2002 16:56:16 -0500
> From: Jing Zhou <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
>
>
> ----- 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.
>
I think any attempt to keep the current split name/property/scope
parameters is going to be very confusing to someone already used to the
JSTL EL syntax. I'm afraid that it's us that really needs to change,
rather than them ... and I'd like to see that process start in this
transitional library.
>
> >
> > 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.
>
Remember that it's the page author that sets the prefix ... not the
library :-). You can set it to anything you like.
> >
> > --
> > ===================================================================
> > 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]>
> >
> >
>
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
