Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Craig R. McClanahan]

On 4 Aug 2002, Arron Bates wrote:

> Date: 04 Aug 2002 03:39:32 +1000
> From: Arron Bates <[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?
>
> > 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
>
> thought about it a little, and there doesn't seem to be an obvious fit
> to pairing the evaluation to a complex bean structure ready for
> BeanUtils without explicit handling. if it does happen it'll be a
> concoction of our making rather than something that just slides in
> there. think maybe the nested tags will become victim to the jstl. oh
> well. in this regard I think the jstl is lacking a little power for use
> with Struts. though I am bias, you can do some truly funky stuff with
> Struts when its marked up with the nested tags. But they're hardly a
> standard.
>

If we can come up with something generic that is similar to the nested
tags concept, but is not Struts specific, it could certainly be considered
for JSTL 1.1.

> Lately been working on a project which has some interesting stuff.
> I've taken a few parts a next step and I get the feeling it's towards
> what I imagine Java Server Faces to turn out to be. Looks like a bright
> future. If if could muster the energy for something open source in the
> future, it'd be the JSF impl. Apache looking at taking on an impl
> project?...

No news at the moment.

> Any chances of getting a backdoor of that spec?... :)
>

Sorry, not until public draft :-).

But keep in mind that I do like the EL expression language ... :-)

> Arron.
>

Craig


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

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Arron Bates]

> 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

thought about it a little, and there doesn't seem to be an obvious fit
to pairing the evaluation to a complex bean structure ready for
BeanUtils without explicit handling. if it does happen it'll be a
concoction of our making rather than something that just slides in
there. think maybe the nested tags will become victim to the jstl. oh
well. in this regard I think the jstl is lacking a little power for use
with Struts. though I am bias, you can do some truly funky stuff with
Struts when its marked up with the nested tags. But they're hardly a
standard.

Lately been working on a project which has some interesting stuff. 
I've taken a few parts a next step and I get the feeling it's towards
what I imagine Java Server Faces to turn out to be. Looks like a bright
future. If if could muster the energy for something open source in the
future, it'd be the JSF impl. Apache looking at taking on an impl
project?... Any chances of getting a backdoor of that spec?... :)

Arron.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Craig R. McClanahan]

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 g

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Jing Zhou]

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

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Craig R. McClanahan]

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 "" (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>  > Jing>
> property="p1[${loop2Status.index}].p2[${loop3Status.index}].p3" />
> >
> > I guess you've partially lost me.  Would the alternative for point (1) be:
> >
> >  property="some_name[loop1Status.index].p1[loop2Status.index].p2[loop3Status.
> index].p3"/>
> >
> > ?
> >
> > Which are you saying is preferable?
>
> I prefer it in the 

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Jing Zhou]

- 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 "" (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>  Jing>
property="p1[${loop2Status.index}].p2[${loop3Status.index}].p3" />
>
> I guess you've partially lost me.  Would the alternative for point (1) be:
>
> 
>
> ?
>
> Which are you saying is preferable?

I prefer it in the format 
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

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[David M. Karr]

See comments below.

> "Jing" == Jing Zhou <[EMAIL PROTECTED]> writes:

>> Therefore, I would say that "" (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>  property="p1[${loop2Status.index}].p2[${loop3Status.index}].p3" />

I guess you've partially lost me.  Would the alternative for point (1) be:



?

Which are you saying is preferable?

(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?

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.

-- 
===
David M. Karr  ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Jing Zhou]

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 
should do any
> Jing> export
> Jing> things, we could simplify Craig's example as follows:
>
> Jing> 
> Jing> 
> Jing> 
>
> 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 "" (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
}
}

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[David M. Karr]

> "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  should do any
Jing> export
Jing> things, we could simplify Craig's example as follows:

Jing> 
Jing> 
Jing> 

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 "" (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).

-- 
===
David M. Karr  ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[David M. Karr]

> "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  should do any
Jing> export
Jing> things, we could simplify Craig's example as follows:

Jing> 
Jing>  
Jing> 

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.

It's funny to have "c:forEach" iterate over a collection, but ignore the item,
which is essentially what's happening here.  However, it does make sense here.

Just to summarize your example, the "property" attribute will be used in two
different ways.  It will be recursively wrapped by "${" and "}" and passed to
the EL engine to get the current value, and sent "raw" as the request parameter
name.  By "recursive", I mean that "customers[${status.index}].id" would be
evaluated, resulting in (say) "customers[2].id" to get the request parameter
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?

I'd like to be sure exactly what you're asking here.  It's obvious that we
wouldn't need to use "indexed" if we directly construct the index expression,
as in this example.

The "property" attribute could have two different interpretations, depending on
whether the "name" attribute was present.  The old meaning if "name" was
present, and the new meaning if "name" is not present.  The "indexed" attribute
could only be present if the "name" attribute was present.

This would provide a transitional strategy, even while using the Struts-EL
library.

I'm still bouncing around these ideas in my mind.  Any other affirmation or
rejection of these ideas would be useful, at least.

-- 
===
David M. Karr  ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Jing Zhou]

- Original Message -
From: "David M. Karr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 22, 2002 11:45 PM
Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?


> >>>>> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
>
> Craig> I've been thinking about this issue as well, as you might
imagine.
>
> Craig> For general form field properties, I'm assuming that we would
have to make
> Craig> the existence of the form bean explict -- say, for example:
>
> Craig>   
>
> Craig> instead of assuming that you could just use username and "know"
that it
> Craig> was resolved against the form bean in the surrounding scope.
The property
> Craig> name can either be inferred from the expression (i.e. after the
first
> Craig> period), or we could allow an optional "property" attribute
that would
> Craig> provide the field name for the rendered  field.
>
> I'm very hesitant to start parsing the EL string, as there's a lot of
different
> ways to form a legal expression, and I don't want to try to restrict the
form
> of the EL expression in these situations.
>
> We could of course have the "var" attribute be an EL to get the current
value,
> and have the "property" attribute be the "name" attribute in the generated
> HTML, but then you have a disconnect between the value and the name,
whereas
> the current "name/property" pair allows a clean specification of both the
> current value and the request parameter name.
>
> Craig> For indexed things, remember that the subscript in an EL
expression can be
> Craig> a variable.  So something like this should work, where
"customers" is an
> Craig> array of customer objects, and we're inside a form with a field
per
> Craig> customer account number:
>
> Craig>   
> Craig>  Craig>  property="customers[${status.index}]"/>
> Craig>   
>
> Craig> could do the trick, as long as you scanned both the "var" and
"property"
> Craig> attributes for expressions.
>
> Yes, I had considered the array index possibility.  This will provide more
> flexibility, allowing the case of two nested "iterate" tags, and you want
the
> "property" attribute of the HTML tag to come from the OUTER iterate tag
(which
> someone on "struts-user" just asked about today).
>
> However, in the general case, we're still having the users specify more,
and
> redundant information, just to avoid the use of the "name/property" pair.
>
> I guess we could provide two ways to do this:
>
> If the "name" attribute is present, the "name" and "property" are combined
as
> usual.  However, if the "var" attribute is present, in place of the "name"
> attribute, then the "var" value is used for the current value, and the
> "property" attribute is used as the entire "name" attribute (of the
generated
> HTML).

The convention (see JSTL spec 2.2.1) is to use the name "var" for attributes
that export information. As I do not think  should do any
export
things, we could simplify Craig's example as follows:


 


Where we are only interested in the current iteration index evaluated by
an EL engine at run time and no changes are needed in the action codes.

Will it be possible to keep the semantics of name/property attributes
and drop the "indexed" attribute when the EL engine is available?

Jing

>
> (It's certainly confusing to have the "name" attribute mean two different
> things, one in JSP, and the other in HTML).
>
> Unfortunately, a change like this will require changing the base Struts
tag.
> In the case of "CheckboxTag" (and probably others), the current value
lookup is
> done directly in its "doStartTag()" method, with no comparison of "value"
> against null check to bypass it (which is the case in other tags, like
"size"
> and "message", for instance).
>
> --
> ===
> David M. Karr  ; Java/J2EE/XML/Unix/C++
> [EMAIL PROTECTED]
>
>
> --
> 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]>

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[David M. Karr]

> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:

Craig> I've been thinking about this issue as well, as you might imagine.

Craig> For general form field properties, I'm assuming that we would have to make
Craig> the existence of the form bean explict -- say, for example:

Craig>   

Craig> instead of assuming that you could just use username and "know" that it
Craig> was resolved against the form bean in the surrounding scope.  The property
Craig> name can either be inferred from the expression (i.e. after the first
Craig> period), or we could allow an optional "property" attribute that would
Craig> provide the field name for the rendered  field.

I'm very hesitant to start parsing the EL string, as there's a lot of different
ways to form a legal expression, and I don't want to try to restrict the form
of the EL expression in these situations.

We could of course have the "var" attribute be an EL to get the current value,
and have the "property" attribute be the "name" attribute in the generated
HTML, but then you have a disconnect between the value and the name, whereas
the current "name/property" pair allows a clean specification of both the
current value and the request parameter name.

Craig> For indexed things, remember that the subscript in an EL expression can be
Craig> a variable.  So something like this should work, where "customers" is an
Craig> array of customer objects, and we're inside a form with a field per
Craig> customer account number:

Craig>   
Craig>   property="customers[${status.index}]"/>
Craig>   

Craig> could do the trick, as long as you scanned both the "var" and "property"
Craig> attributes for expressions.

Yes, I had considered the array index possibility.  This will provide more
flexibility, allowing the case of two nested "iterate" tags, and you want the
"property" attribute of the HTML tag to come from the OUTER iterate tag (which
someone on "struts-user" just asked about today).

However, in the general case, we're still having the users specify more, and
redundant information, just to avoid the use of the "name/property" pair.

I guess we could provide two ways to do this:

If the "name" attribute is present, the "name" and "property" are combined as
usual.  However, if the "var" attribute is present, in place of the "name"
attribute, then the "var" value is used for the current value, and the
"property" attribute is used as the entire "name" attribute (of the generated
HTML).

(It's certainly confusing to have the "name" attribute mean two different
things, one in JSP, and the other in HTML).

Unfortunately, a change like this will require changing the base Struts tag.
In the case of "CheckboxTag" (and probably others), the current value lookup is
done directly in its "doStartTag()" method, with no comparison of "value"
against null check to bypass it (which is the case in other tags, like "size"
and "message", for instance).

-- 
===
David M. Karr  ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Craig R. McClanahan]

On Mon, 22 Jul 2002, Craig R. McClanahan wrote:

>
>   
>   property="customers[${status.index}]"/>
>   
>

Err, that should probably something more like:

  

  

but you get the idea, I hope.

Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Craig R. McClanahan]

On 22 Jul 2002, David M. Karr wrote:

> Date: 22 Jul 2002 20:07:22 -0700
> From: David M. Karr <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Struts-EL: Ideas about "name" and indexed "name" attributes?
>
> In mapping Struts tags to Struts-EL, I'm wondering about the "name" attribute
> of the generated HTML for these tags, along with the "property" attribute of
> the custom tag, and "indexed" tags.
>
> In the current Struts library, in the "checkbox" tag, for instance, the
> strategy of setting the "name" and "property" attributes nicely flows the
> specified field values back into the specified actionform and property on the
> return trip.  If the "indexed" attribute is set, it nicely builds an index
> reference, which will eventually cause the correct array/collection entry to be
> set.
>
> I'm thinking and thinking about how I can possibly map something like this to
> JSTL functionality, and I just don't see it.  I was assuming that the
> "name/property" functionality would be mutually exclusive with the JSTL
> functionality, but in at least the HTML tags, where the "name/property" pair is
> used to build the HTML "name" attribute, I don't see how I can replace that.
>
> In the case of "checkbox", the "value" attribute and others could still use the
> EL engine, just not the "name/property" functionality.
>
> Does anyone have any ideas about this?
>

I've been thinking about this issue as well, as you might imagine.

For general form field properties, I'm assuming that we would have to make
the existence of the form bean explict -- say, for example:

  

instead of assuming that you could just use username and "know" that it
was resolved against the form bean in the surrounding scope.  The property
name can either be inferred from the expression (i.e. after the first
period), or we could allow an optional "property" attribute that would
provide the field name for the rendered  field.

For indexed things, remember that the subscript in an EL expression can be
a variable.  So something like this should work, where "customers" is an
array of customer objects, and we're inside a form with a field per
customer account number:

  

  

could do the trick, as long as you scanned both the "var" and "property"
attributes for expressions.

> David M. Karr  ; Java/J2EE/XML/Unix/C++

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: