> * For existing tags that take "name", "property", and "scope"
> arguments, define an "xpath" attribute that uses an XPath
> expression to access properties. This would be an alternative
> to the existing name/property/scope access, extended as
> defined in the previous point.
Having used XPath in our current web architecture, I am especially keen to
see this used in Struts (so we can reap Struts other benefits!). I'd like
to mention a few ideas I've had on this topic!
1. How will we establish the scope in which the XPath is to be executed?
There are three options I can see...
a. Use an XPath 'variable' to define the scope of the XPath.
<bean:write xpath="$session/myBean/someBeanProperty" />
The implementation here might have Struts maintaining DOM objects that have
each session/request/application scope object contained as an element.
b. Use a single root DOM object from which the request, session and
application scope DOM objects are exposed as elements.
<bean:write xpath="/session/myBean/someBeanProperty"/>
c. Simply use the existing property attribute (and possibly the name
attribute as well).
<bean:write scope="session" xpath="/myBean/someBeanProperty"/> ... or
...
<bean:write scope="session" name="myBean" xpath="/someBeanProperty"/>
Perhaps the best solution is a combination of 2 and 3, whereby the
developer can choose to fully specify the XPath as including the object's
scope, name and property path, or the name and property only, or just the
property.
2. How will we treat paths that return multiple nodes? Assume that the
'someBeanProperty' of 'myBean' above is in fact an indexed property. Under
XPath notation, if you don't have an expression that limits the values of
'someBeanProperty' that are being returned, then you will get all of them.
My approach to this was to simply delimit them in some fashion; a comma or
a <BR /> statement are the obvious choices here. Alternatively, you might
want to default to only retrieving the first occurrence, if some special
property is defined.
3. Implementation option: In an earlier message (
http://www.mail-archive.com/[email protected]/msg00085.html ) I
suggested that perhaps having a class 'BeanDOMAdapter' or maybe 'BeanToDOM'
might be a better name... anyway a class that implements the
org.w3c.dom.Node interface and is constructed from any JavaBean instance -
the class then uses the BeanInfo to determine what the 'elements' and
'attributes' of the 'Node' are. This might not be the best approach from a
performance point of view however?
Regards,
James W.
--------------------------------------------------------------------------
This e-mail is from Cards Etc Pty Ltd (ACN: 069 533 302). It may contain
privileged and confidential information. It is intended for the named
recipient(s) only. If you are not an intended recipient, please notify us
immediately by reply e-mail or by phone on +61 2 9212 7773 & delete this
e-mail from your system.
--------------------------------------------------------------------------
