You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jing Zhou <ji...@netspread.com> on 2002/08/01 18:10:30 UTC
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" <dm...@earthlink.net>
To: <st...@jakarta.apache.org>
Sent: Friday, July 26, 2002 1:16 PM
Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
> >>>>> "David" == David M Karr <dm...@earthlink.net> writes:
>
> >>>>> "Jing" == Jing Zhou <ji...@netspread.com> 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
"name"d
> 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,
property
again, which cost unnecessary CPU time and depend on end users correct
input.
I am very concerned about user experience: think about an UI for City,
State, Zip code,
How would you feel if a site give you only one text field to input the
city, state, and zip code? It will depend on the end users to input them in
correct
order with correct delimiters, it also need developers to parse the
attribute into
correct tokens. It will not be a good UI design.
So in general I hope the community could come out a design that keeps the
original
beauty of Struts and even the design could enhance the current html tags
without
having to create a "parallel" library in the end (Did someone say that
before?)
> --
> ===================================================================
> David M. Karr ; Java/J2EE/XML/Unix/C++
> dmkarr@earthlink.net
>
>
Jing
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 4 Aug 2002, Arron Bates wrote:
> Date: 04 Aug 2002 03:39:32 +1000
> From: Arron Bates <st...@keyboardmonkey.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
Posted by Arron Bates <st...@keyboardmonkey.com>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See below.
On Fri, 2 Aug 2002, Jing Zhou wrote:
> Date: Fri, 2 Aug 2002 15:05:27 -0500
> From: Jing Zhou <ji...@netspread.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
>
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <cr...@apache.org>
> To: "Struts Developers List" <st...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
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:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
Jing
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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 <ji...@netspread.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
>
>
> ----- Original Message -----
> From: "David M. Karr" <dm...@earthlink.net>
> To: <st...@jakarta.apache.org>
> 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 <ji...@netspread.com> writes:
> >
> > >> Therefore, I would say that "<html-el:text>" (and similar tags)
> wouldn't
> > Jing> have a
> > >> "name" or "indexed" attribute. The "property" attribute (as I
> described
> > >> earlier) would be used both to get the current value and to specify
> the
> > Jing> request
> > >> parameter name. The current meaning of the "value" attribute
> should still
> > >> apply (overrides the property attribute for the current value).
> >
> > Jing> There could be a way to enhance the current html tags while
> keeping the
> > Jing> semantics of "name", "property" which is one of beautiful things
> > Jing> in Craig's original thinking.
> >
> > Jing> Suppose we define EL based name, property by attributes
> > Jing> _name, _property and initialize them to be null. Then we could
> have
> >
> > Jing> protected String _name = null;
> > Jing> public void setName(String name) {
> > Jing> this._name = name;
> > Jing> }
> > Jing> protected String _property = null;
> > Jing> public void setProperty(String property) {
> > Jing> this._property = property;
> > Jing> }
> > Jing> public int doStartTag() throws JspException {
> > Jing> if (_name == null) {
> > Jing> name = Constants.BEAN_KEY; // so we do not need to
> initialize name
> > Jing> to be a non-null value any more
> > Jing> } else {
> > Jing> name = (String)
> ExpressionEvaluationManager.evaluate("name", _name,
> > Jing> String.class, this, pageContext);
> > Jing> if (name == null) {
> > Jing> name = Constants.BEAN_KEY;
> > Jing> }
> > Jing> }
> > Jing> if (_property == null) {
> > Jing> // throw new JspException("error message") or keep it
> depends on
> > Jing> particular tag implementations
> > Jing> } else {
> > Jing> property = (String)
> ExpressionEvaluationManager.evaluate("property",
> > Jing> _property, String.class, this, pageContext);
> > Jing> if (property == null) {
> > Jing> // some decisions here
> > Jing> }
> > Jing> }
> >
> > Jing> ...
> >
> > Jing> // make sure all RequestUtils.lookup will see only evaluated
> name,
> > Jing> property, scope
> > Jing> Object value = RequestUtils.lookup(pageContext, name,
> property, null);
> >
> > Jing> }
> >
> > Jing> Sometimes ago, I was trying to figure out if I could have a
> "compact"
> > Jing> attribute which
> > Jing> combine name/property/scope altogether when I design my UI. When
> I saw above
> > Jing> possibility, I feel it is not a good idea to combine them into
> one
> > Jing> attribute, because:
> >
> > Jing> 1) The combined attribute could not provide enough additional
> power I could
> > Jing> buy:
> > Jing> End users could put a tag in multi-level loop like this:
> >
> > Jing> <html-el:text name="some_name[${loop1Status.index}]"
> > Jing>
> property="p1[${loop2Status.index}].p2[${loop3Status.index}].p3" />
> >
> > I guess you've partially lost me. Would the alternative for point (1) be:
> >
> > <html-el:text
> property="some_name[loop1Status.index].p1[loop2Status.index].p2[loop3Status.
> index].p3"/>
> >
> > ?
> >
> > Which are you saying is preferable?
>
> I prefer it in the format <html-el:text name="some EL expression"
> property="other EL expression"
> readonly="another EL expression"
> ... />
> In the example, the "some_name[" and "]" in the name attribute are
> pass-through string literals.
> "${" and "}" can not be removed from there. The same rule applied to the
> property attribute.
> But if you do this: property="${some_name[loop1Status.index]...}" that
> is a different thing.
>
> >
> > (Will the ActionForm processing successfully parse that "property" value
> so the
> > value can be set in the ActionForm?)
> >
> > Jing> 2) If using combined attribute, I have to delemite the attribute
> into name,
> > Jing> property
> > Jing> again, which cost unnecessary CPU time and depend on end users
> correct
> > Jing> input.
> > Jing> I am very concerned about user experience: think about an UI for
> City,
> > Jing> State, Zip code,
> > Jing> How would you feel if a site give you only one text field to
> input the
> > Jing> city, state, and zip code? It will depend on the end users to
> input them in
> > Jing> correct
> > Jing> order with correct delimiters, it also need developers to parse
> the
> > Jing> attribute into
> > Jing> correct tokens. It will not be a good UI design.
> >
> > Sorry, I don't understand. I'm not sure what you mean by "delemite the
> > attribute into name, property again". How does this depend on the end
> user's
> > correct input? Are you talking about the programmer, or the user of the
> > application?
>
> A spelling error (should be delimit).
>
> Assume someone is still using RequestUtils.lookup() to retrieve
> value given form bean name and property when rendering the JSP pages, he
> needs seperated name and property passed in the tag functions. In your
> alternative
> example, how do I figure out which part is for the orginal name attribute,
> and
> which part is for the orginal property attribute? The first dot "." will not
> help
> me to delimit the attribute into name/property pair. And if I got the
> following
> expression:
> property="${foo[i].a.b.[j]}"
> I could not tell which part is for name at all.
>
> Thinking about the assumption on using RequestUtils.lookup(), assume
> somebody has a function that can take one argument, say "property", and
> return
> an object value. Somehow, he has to parse the argument to figure out the
> JSP scoped attribute from it (which is exactly purpose of the name attribute
> in
> Struts today) and the function will eventually call a function like
> RequestUtils (maybe just a different function name)
> So the parsing (from one argument into two at least) will cost unnecessary
> CPU time
> since we already have seperated name/property pair today. Why not just
> use it?
>
> I could be wrong. But I would like to be first convinced there is a function
> that
> is faster than RequestUtils in principles and I could buy additional power
> when using seperated name/property expressions could not achieve. It is not
> an easy task for me to prove the two points.
>
I think any attempt to keep the current split name/property/scope
parameters is going to be very confusing to someone already used to the
JSTL EL syntax. I'm afraid that it's us that really needs to change,
rather than them ... and I'd like to see that process start in this
transitional library.
>
> >
> > Jing> So in general I hope the community could come out a design that
> keeps the
> > Jing> original
> > Jing> beauty of Struts and even the design could enhance the current
> html tags
> > Jing> without
> > Jing> having to create a "parallel" library in the end (Did someone
> say that
> > Jing> before?)
> >
> > The only constant is change. There is movement towards using the JSTL.
> The
> > goal is to eventually have a Struts tag library that works cleanly with
> the
> > JSTL. This "parallel" library is only a transition strategy.
>
> That will be very cool if "-el" could be dropped eventually from the prefix.
>
Remember that it's the page author that sets the prefix ... not the
library :-). You can set it to anything you like.
> >
> > --
> > ===================================================================
> > David M. Karr ; Java/J2EE/XML/Unix/C++
> > dmkarr@earthlink.net
> >
>
> Jing
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "David M. Karr" <dm...@earthlink.net>
To: <st...@jakarta.apache.org>
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 <ji...@netspread.com> writes:
>
> >> Therefore, I would say that "<html-el:text>" (and similar tags)
wouldn't
> Jing> have a
> >> "name" or "indexed" attribute. The "property" attribute (as I
described
> >> earlier) would be used both to get the current value and to specify
the
> Jing> request
> >> parameter name. The current meaning of the "value" attribute
should still
> >> apply (overrides the property attribute for the current value).
>
> Jing> There could be a way to enhance the current html tags while
keeping the
> Jing> semantics of "name", "property" which is one of beautiful things
> Jing> in Craig's original thinking.
>
> Jing> Suppose we define EL based name, property by attributes
> Jing> _name, _property and initialize them to be null. Then we could
have
>
> Jing> protected String _name = null;
> Jing> public void setName(String name) {
> Jing> this._name = name;
> Jing> }
> Jing> protected String _property = null;
> Jing> public void setProperty(String property) {
> Jing> this._property = property;
> Jing> }
> Jing> public int doStartTag() throws JspException {
> Jing> if (_name == null) {
> Jing> name = Constants.BEAN_KEY; // so we do not need to
initialize name
> Jing> to be a non-null value any more
> Jing> } else {
> Jing> name = (String)
ExpressionEvaluationManager.evaluate("name", _name,
> Jing> String.class, this, pageContext);
> Jing> if (name == null) {
> Jing> name = Constants.BEAN_KEY;
> Jing> }
> Jing> }
> Jing> if (_property == null) {
> Jing> // throw new JspException("error message") or keep it
depends on
> Jing> particular tag implementations
> Jing> } else {
> Jing> property = (String)
ExpressionEvaluationManager.evaluate("property",
> Jing> _property, String.class, this, pageContext);
> Jing> if (property == null) {
> Jing> // some decisions here
> Jing> }
> Jing> }
>
> Jing> ...
>
> Jing> // make sure all RequestUtils.lookup will see only evaluated
name,
> Jing> property, scope
> Jing> Object value = RequestUtils.lookup(pageContext, name,
property, null);
>
> Jing> }
>
> Jing> Sometimes ago, I was trying to figure out if I could have a
"compact"
> Jing> attribute which
> Jing> combine name/property/scope altogether when I design my UI. When
I saw above
> Jing> possibility, I feel it is not a good idea to combine them into
one
> Jing> attribute, because:
>
> Jing> 1) The combined attribute could not provide enough additional
power I could
> Jing> buy:
> Jing> End users could put a tag in multi-level loop like this:
>
> Jing> <html-el:text name="some_name[${loop1Status.index}]"
> Jing>
property="p1[${loop2Status.index}].p2[${loop3Status.index}].p3" />
>
> I guess you've partially lost me. Would the alternative for point (1) be:
>
> <html-el:text
property="some_name[loop1Status.index].p1[loop2Status.index].p2[loop3Status.
index].p3"/>
>
> ?
>
> Which are you saying is preferable?
I prefer it in the format <html-el:text name="some EL expression"
property="other EL expression"
readonly="another EL expression"
... />
In the example, the "some_name[" and "]" in the name attribute are
pass-through string literals.
"${" and "}" can not be removed from there. The same rule applied to the
property attribute.
But if you do this: property="${some_name[loop1Status.index]...}" that
is a different thing.
>
> (Will the ActionForm processing successfully parse that "property" value
so the
> value can be set in the ActionForm?)
>
> Jing> 2) If using combined attribute, I have to delemite the attribute
into name,
> Jing> property
> Jing> again, which cost unnecessary CPU time and depend on end users
correct
> Jing> input.
> Jing> I am very concerned about user experience: think about an UI for
City,
> Jing> State, Zip code,
> Jing> How would you feel if a site give you only one text field to
input the
> Jing> city, state, and zip code? It will depend on the end users to
input them in
> Jing> correct
> Jing> order with correct delimiters, it also need developers to parse
the
> Jing> attribute into
> Jing> correct tokens. It will not be a good UI design.
>
> Sorry, I don't understand. I'm not sure what you mean by "delemite the
> attribute into name, property again". How does this depend on the end
user's
> correct input? Are you talking about the programmer, or the user of the
> application?
A spelling error (should be delimit).
Assume someone is still using RequestUtils.lookup() to retrieve
value given form bean name and property when rendering the JSP pages, he
needs seperated name and property passed in the tag functions. In your
alternative
example, how do I figure out which part is for the orginal name attribute,
and
which part is for the orginal property attribute? The first dot "." will not
help
me to delimit the attribute into name/property pair. And if I got the
following
expression:
property="${foo[i].a.b.[j]}"
I could not tell which part is for name at all.
Thinking about the assumption on using RequestUtils.lookup(), assume
somebody has a function that can take one argument, say "property", and
return
an object value. Somehow, he has to parse the argument to figure out the
JSP scoped attribute from it (which is exactly purpose of the name attribute
in
Struts today) and the function will eventually call a function like
RequestUtils (maybe just a different function name)
So the parsing (from one argument into two at least) will cost unnecessary
CPU time
since we already have seperated name/property pair today. Why not just
use it?
I could be wrong. But I would like to be first convinced there is a function
that
is faster than RequestUtils in principles and I could buy additional power
when using seperated name/property expressions could not achieve. It is not
an easy task for me to prove the two points.
>
> Jing> So in general I hope the community could come out a design that
keeps the
> Jing> original
> Jing> beauty of Struts and even the design could enhance the current
html tags
> Jing> without
> Jing> having to create a "parallel" library in the end (Did someone
say that
> Jing> before?)
>
> The only constant is change. There is movement towards using the JSTL.
The
> goal is to eventually have a Struts tag library that works cleanly with
the
> JSTL. This "parallel" library is only a transition strategy.
That will be very cool if "-el" could be dropped eventually from the prefix.
>
> --
> ===================================================================
> David M. Karr ; Java/J2EE/XML/Unix/C++
> dmkarr@earthlink.net
>
Jing
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts-EL: Ideas about "name" and indexed "name" attributes?
Posted by "David M. Karr" <dm...@earthlink.net>.
See comments below.
>>>>> "Jing" == Jing Zhou <ji...@netspread.com> 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++
dmkarr@earthlink.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>