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. 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts-EL: Ideas about name and indexed name attributes?
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?
- 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?
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
Re: Struts-EL: Ideas about name and indexed name attributes?
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 html-el:text/
should do any
Jing export
Jing things, we could simplify Craig's example as follows:
Jing c:forEach items=customers varStatus=status
Jing html-el:text property=customers[${status.index}].id/
Jing /c:forEach
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
named
form bean or the default form bean.
Therefore, I would say that html-el:text (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
}
}
...
// make sure all RequestUtils.lookup will see only evaluated name,
property, scope
Object value = RequestUtils.lookup(pageContext, name, property, null);
}
Sometimes ago, I was trying to figure out if I could have a compact
attribute which
combine name/property/scope altogether when I design my UI. When I saw above
possibility, I feel it is not a good idea to combine them into one
attribute, because:
1) The combined attribute could not provide enough additional power I could
buy:
End users could put a tag in multi-level loop like this:
html-el:text name=some_name[${loop1Status.index}]
property=p1[${loop2Status.index}].p2[${loop3Status.index}].p3 /
2) If using combined attribute, I have to delemite the attribute into name
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?
(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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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
Re: Struts-EL: Ideas about name and indexed name attributes?
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
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 html-el:text/ should do any
Jing export
Jing things, we could simplify Craig's example as follows:
Jing c:forEach items=customers varStatus=status
Jing html-el:text property=customers[${status.index}].id/
Jing /c:forEach
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 named
form bean or the default form bean.
Therefore, I would say that html-el:text (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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts-EL: Ideas about name and indexed name attributes?
- 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 html-el:test var=${logonForm.username}/
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 input 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 c:forEach var=customer items=customers
varStatus=status
Craig html-el:text var=${customer.id}
Craig property=customers[${status.index}]/
Craig /c:forEach
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 html-el:text/ should do any
export
things, we could simplify Craig's example as follows:
c:forEach items=customers varStatus=status
html-el:text property=customers[${status.index}].id/
/c:forEach
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?
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 html-el:text/ should do any
Jing export
Jing things, we could simplify Craig's example as follows:
Jing c:forEach items=customers varStatus=status
Jing html-el:text property=customers[${status.index}].id/
Jing /c:forEach
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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts-EL: Ideas about name and indexed name attributes?
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:
html-el:test var=${logonForm.username}/
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 input 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:
c:forEach var=customer items=customers varStatus=status
html-el:text var=${customer.id}
property=customers[${status.index}]/
/c:forEach
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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 html-el:test var=${logonForm.username}/
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 input 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 c:forEach var=customer items=customers varStatus=status
Craig html-el:text var=${customer.id}
Craig property=customers[${status.index}]/
Craig /c:forEach
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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
