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

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.



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


Jing


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to