See below.
On Fri, 2 Aug 2002, Jing Zhou wrote:
> Date: Fri, 2 Aug 2002 15:05:27 -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: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Thursday, August 01, 2002 5:10 PM
> Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
>
>
> > See intermixed (well, it's really at the bottom).
> >
> > >
> > > 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.
>
> I am not against to changes. In fact, our visual productivity tool will
> allow end users to publish/withdraw action mappings (visual form
> bean models, visual form view models, visual form controller models)
> online. Behind the publishing mechanism, there is a stylesheet per
> mapping that could transform struts taglibs into any other taglibs
> where prefixes, element names, attribute names, can be
> changed/combined according to needs (or future definitions)
>
> When I saw the intension to combine the name/property/scope
> into one attribute, I realized I had to extract out the JSP scope attribute
> name from the combined attribute in some way inside the tag functions,
> if you agree.
>
> It is not clear to me if there is a clean way to extract out the JSP scope
> attribute name from the combined attribute without adding new
> syntax rules in addition to the standard JSTL EL syntax. Of course,
> we can restrict the combined attribute in the format
> ${session.name.property}
> But it is over restricted given a lot of additional capabilities of EL
> engine.
>
Conforming to the actual rules JSTL follows (and JSP 2.0 will follow) is a
little more complex than that. Consider the following cases:
* ${foo.bar} -- Searches for "foo' in any scope (page, request, session,
application) and then call getBar() on it.
* ${sessionScope.foo.bar} -- Searches for "foo" in session scope only
(analogous pseudo-variables exist for other scopes, plus the headers,
parameters, and cookies on a request) and then calls getBar() on it.
The bottom line is that there isn't necessarily a scope identifier present
in the expression. But if one is there, it has a fixed value that can be
recognized.
> If any body comes up a great idea to extract out the JSP scope
> attribute name in a general way, I would like to see it. But remember,
> any attempt to add additional rules on the attribute in addition to the
> standard syntax rules is going to be very confusing too (from my experience)
> and a check is needed to see if there are lost capabilities comparing with
> the case using split name/property expressions.
>
One thing we do give up (I think) is the implicit nesting of form field
names (specified in the "property" attribute) inside the variable name of
the form bean itself. I guess the same is true of the "with"-like
facilities of the entire nested tag library.
It will be interesting to see if we can come up with a way to keep this --
perhaps by composing a compound expression on the fly.
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
