Re: XML Selects and bean style properties.
Sorry, sent before seeing Bill's reply and reading that you've got an easy
workaround which is probably the same thing...
Quoting Kris Schneider [EMAIL PROTECTED]:
So, something like this doesn't work?
x:out select=/foo/[EMAIL PROTECTED]/
Find the bar element with an attribute x equal to the value of USER's
full_name. What if you add a level of indirection:
c:set var=fullName value=${USER.full_name}/
x:out select=/foo/[EMAIL PROTECTED]/
Quoting Rick Ross [EMAIL PROTECTED]:
I have a scoped variable called 'USER' with a variety of the usual bean
style
properties. Naturally, it's just a convenient place to hold the user
properties and in the EL, it's quite easy to get them ${USER.full_name}.
However, if I want to predicate an XPath query (in an x: tag select
statement) on information in the USER object, I don't think I can do that.
The spec doesn't mention it and Mr. Bayern's book is not available on
Safari.
Core JSTL also makes no comment here.
A brief look at the 1.1 JSTL spec didn't turn anything up either. Now I
can
easily get around the problem, but it would be immensely more powerful if
we
could embed the EL in our XPath statements. It shouldn't bee too hard to
parse, with ${ } surrounding the EL's inside the XPath as XPath does not
define any of those three characters. The only obvious issue would be
escaped ${ in predicate text.
I certainly understand if this was intentionally left out, but the fact
that
we cannot really even dynamically replace select statements with EL,
combined
with no bean style property access, seems to leave a large functionality
gap.
Or am I just whining? :-)
Rick
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Selects and bean style properties.
The spec only specifies how it works with a specific set of contexts. It
does not require a generic mechanism, although you are correct that it would
make sense for the syntax to be the same.
R
- Original Message -
From: Felipe Leme [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, August 11, 2003 11:38 AM
Subject: Re: XML Selects and bean style properties.
Hi,
Have you tried $USER:full_name?
(not sure if it works, as I never tried, but the specification suggests :
could be used for that)
Felipe
On Monday 11 August 2003 03:34 pm, Kris Schneider kris-at-dotech.com
|jakarta|
wrote:
So, something like this doesn't work?
x:out select=/foo/[EMAIL PROTECTED]/
Find the bar element with an attribute x equal to the value of
USER's
full_name. What if you add a level of indirection:
c:set var=fullName value=${USER.full_name}/
x:out select=/foo/[EMAIL PROTECTED]/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Selects and bean style properties.
So, something like this doesn't work?
x:out select=/foo/[EMAIL PROTECTED]/
Find the bar element with an attribute x equal to the value of USER's
full_name. What if you add a level of indirection:
c:set var=fullName value=${USER.full_name}/
x:out select=/foo/[EMAIL PROTECTED]/
Quoting Rick Ross [EMAIL PROTECTED]:
I have a scoped variable called 'USER' with a variety of the usual bean style
properties. Naturally, it's just a convenient place to hold the user
properties and in the EL, it's quite easy to get them ${USER.full_name}.
However, if I want to predicate an XPath query (in an x: tag select
statement) on information in the USER object, I don't think I can do that.
The spec doesn't mention it and Mr. Bayern's book is not available on Safari.
Core JSTL also makes no comment here.
A brief look at the 1.1 JSTL spec didn't turn anything up either. Now I can
easily get around the problem, but it would be immensely more powerful if we
could embed the EL in our XPath statements. It shouldn't bee too hard to
parse, with ${ } surrounding the EL's inside the XPath as XPath does not
define any of those three characters. The only obvious issue would be
escaped ${ in predicate text.
I certainly understand if this was intentionally left out, but the fact that
we cannot really even dynamically replace select statements with EL, combined
with no bean style property access, seems to leave a large functionality gap.
Or am I just whining? :-)
Rick
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Selects and bean style properties.
Hi,
Have you tried $USER:full_name?
(not sure if it works, as I never tried, but the specification suggests :
could be used for that)
Felipe
On Monday 11 August 2003 03:34 pm, Kris Schneider kris-at-dotech.com |jakarta|
wrote:
So, something like this doesn't work?
x:out select=/foo/[EMAIL PROTECTED]/
Find the bar element with an attribute x equal to the value of USER's
full_name. What if you add a level of indirection:
c:set var=fullName value=${USER.full_name}/
x:out select=/foo/[EMAIL PROTECTED]/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
XML Selects and bean style properties.
I have a scoped variable called 'USER' with a variety of the usual bean style
properties. Naturally, it's just a convenient place to hold the user properties and
in the EL, it's quite easy to get them ${USER.full_name}. However, if I want to
predicate an XPath query (in an x: tag select statement) on information in the USER
object, I don't think I can do that. The spec doesn't mention it and Mr. Bayern's
book is not available on Safari. Core JSTL also makes no comment here.
A brief look at the 1.1 JSTL spec didn't turn anything up either. Now I can easily
get around the problem, but it would be immensely more powerful if we could embed the
EL in our XPath statements. It shouldn't bee too hard to parse, with ${ } surrounding
the EL's inside the XPath as XPath does not define any of those three characters. The
only obvious issue would be escaped ${ in predicate text.
I certainly understand if this was intentionally left out, but the fact that we cannot
really even dynamically replace select statements with EL, combined with no bean style
property access, seems to leave a large functionality gap.
Or am I just whining? :-)
Rick
RE: XML Selects and bean style properties.
I made the same observation in some testing I was doing and I understand your point.
Basically, it seems when using select (XPath) expression you are hamstringed with how
you can access scoped variables.
Of course, the work around is to use c:set to create a variable with the desired
property -- but it is somewhat annoying to get used to one way of accessing data and
then to not have that available for the XML tags.
-Original Message-
From: Rick Ross [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2003 2:22 PM
To: Tag Libraries Users List
Subject: XML Selects and bean style properties.
I have a scoped variable called 'USER' with a variety of the usual bean style
properties. Naturally, it's just a convenient place to hold the user properties and
in the EL, it's quite easy to get them ${USER.full_name}. However, if I want to
predicate an XPath query (in an x: tag select statement) on information in the USER
object, I don't think I can do that. The spec doesn't mention it and Mr. Bayern's
book is not available on Safari. Core JSTL also makes no comment here.
A brief look at the 1.1 JSTL spec didn't turn anything up either. Now I can easily
get around the problem, but it would be immensely more powerful if we could embed the
EL in our XPath statements. It shouldn't bee too hard to parse, with ${ } surrounding
the EL's inside the XPath as XPath does not define any of those three characters. The
only obvious issue would be escaped ${ in predicate text.
I certainly understand if this was intentionally left out, but the fact that we cannot
really even dynamically replace select statements with EL, combined with no bean style
property access, seems to leave a large functionality gap.
Or am I just whining? :-)
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
