You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <Cr...@eng.sun.com> on 2000/10/09 08:27:23 UTC
[PROPOSAL] Integrating Struts with XML Data
One of the desireable goals for Struts 1.0 is a closer integration with
XML-formatted data -- that is, a graceful way to deal with data sources
that produce XML data and wish to have their information displayed in an
HTML page. One obvious candidate technology is to use for this purpose
is XSLT transformations to convert the XML data to HTML or WML or
whatever -- but writing XSLT stylesheets is not something that most web
developers will be very comfortable with. An easier solution is needed
to deal with simple cases.
Given the fact that Struts now includes some very powerful bean-related
tags like <struts-bean:define>, wouldn't it be nice if we could extend
those tags to deal with XML data as well? It turns out that this is
quite feasible ... the proposal below is an approach to extending the
Struts bean-related tags so that, when they are presented with a bean
that is an XML object (that is, an object of type org.w3c.dom.Document
or some reasonable subordinate object like Element), the bean tags
should extract property values from them similarly to the way they treat
Java objects. The big advantage is, a page developer would be able to
use essentially the same tags for cases where the data was presented as
XML as when the data was presented as JavaBeans or EJBs. (A similar
extension could be made later to deal with Rows and Columns in a JDBC
result set).
In the examples below, assume that a DOM object with the following
structure is attached to the bean name "bean":
<a b="1" c="2">
<d e="3" f="4"/>
<d e="5" f="6"/>
</a>
<a b="7" c="8">
<d e="9" f="10"/>
<d e="11" f="12"/>
</a>
Here's the proposal -- please let me know what you think:
(1) Extensions to <struts-bean:define>:
If the bean referenced by the "name" attribute is a DOM object, apply
the syntax for simple, nested, and/or indexed property syntax to extract
the appropriate element or attribute from the DOM according to the
following rules:
* If the final name in a nested property expression such as a.b.c
identifies an attribute of a selected XML element, return it as a
String.
Otherwise, return a DOM element representing the selected
XML element.
* If a component of a property name expression is indexed,
it is zero-relative in the usual way. If it is not indexed, the
implied index is zero (i.e. a reference to the "a" element in
the example will return the first <a> element).
These rules cause the following behavior given a "<struts-bean:define
name="bean" property='xxx"/>" tag, given the following values for "xxx":
Simple property names:
a --> (the first <a> element as a DOM object)
b --> 1
c --> 2
Nested property names
a.b --> 1
a.c --> 2
a.d --> <d e="3" f="4"/>
a.d.e --> 3
a.d.f --> 4
Indexed property names:
a[0] --> (the first <a> element as a DOM object)
a[1] --> (the second <a> element as a DOM object)
a.d --> <d e="3" f="4"/>
a[0].d --> <d e="3" f="4"/>
a[0].d[0] --> <d e="3" f="4"/>
a.d[1] = <d e="5" f="6"/>
Combination property names (examples only, not exhausitive):
a.d[1].e --> 3
a[1].d[1].e --> 11
(2) Extensions to <struts-bean:write>:
If the object referenced by the "name" and optional "property"
attributes is a DOM object, pretty-print it in its XML format with
"<" and ">" escapes for the angle brackets. This is useful in
debugging, and for catching property naming expression errors. It might
also be useful in a production application to do something similar to
the XSL "<xsl:select>" operation.
(3) Extensions to <struts-bean:iterate>:
If the object referenced by the "name" and optional "property"
attributes is a DOM object, iterate over the XML elements that are
nested inside the specified element, exposing each iterated element as a
DOM object:
<struts-bean:iterate name="bean"> --> Iterate over both <a> elements
<struts-bean:iterate name="bean" property="a"> --> Iterate over both
<d> elements of the first <a> element
<struts-bean:iterate name="bean" property="a[0]"> --> Iterate over
both <d> elements of the first <a> element
<struts-bean:iterate name="bean" property="a[1]"> --> Iterate over
both <d> elements of the second <a> element
<struts-bean:iterate name="bean" property="a[0].d"> --> Iterate over
a zero length collection because there are no nested elements.
Note that, because the <struts-bean:write> tag can be used to extract
appropriate properties from the individual elements being iterated over,
you can use these tags to create reports based on a collection of
"objects" that are in fact represented as XML elements, in the same way
that you could create reports based on an ArrayList of Java objects that
have properties corresponding to the attribute names of the iterated
elements.
Craig McClanahan
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: [PROPOSAL] Integrating Struts with XML Data
Posted by Eduardo Pelegri--Llopart <Ed...@eng.sun.com>.
I think there is some very useful synergy between JSP and XPath, and I
would love to see some exploration of the concepts. HOpefully we would
be able to feed something into the standard JSP tag library (JSR-052).
- eduard/o
Joe Walnes wrote:
>
> In terms of the syntax for selecting properties, would X-Path not make
> sense?
>
> Reasons:
>
> 1) It's a W3C (proposed) standard.
> http://www.w3.org/TR/xpath
>
> 2) It's very easy to perform basic selections - yet powerful enought to
> select just about any node/collection.
>
> 3) Allows navigation to any child node/element/attribute or collection
>
> 4) There are many existing implementations that can easily be reused.
> (Apache Xalan has a nice implementation in the org.apache.xalan.xpath
> package)
> http://xml.apache.org/xalan/
>
> 5) Is used in XSL to select nodes, so users of either system will not have
> to 're-learn' how to use it, and transition from xsl->struts and vice-versa
> will be easy.
>
> Here's some examples of X-Path:
>
> <blah id="12">
> Hello
> <xx>Some text</xx>
> <name first="Bob" last="Bobkins" />
> <cheeses>
> <cheese type="blue">Stilton</cheese>
> <cheese type="soft">Brie</cheese>
> <cheese type="dull">Cheddar</cheese>
> <cheese type="blue">Dorset Vinney</cheese>
> </cheeses>
> </blah>
>
> (I do not mean to offend any cheddar lovers by implying it is a dull
> cheese - it's for the sake of example)
>
> If the <blah> tag is the bean, other attributes can be access like:
>
> . = Hello
> @id = 12
> xx = Some text
> name/@first = Bob
> cheeses/cheese[2] = Brie
> cheeses/cheese[3]/@type = dull
>
> Essentially, / seperates items in the node path, and @ represents
> attributes. Collections can also be retrieved easily.
>
> Incorporating an existing X-Path engine would be a lot easier (and probably
> more powerful) than attempting to implement a proprietry expression language
> from scratch.
>
> my $0.03
>
> -Joe Walnes
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> To: <st...@jakarta.apache.org>
> Sent: Monday, October 09, 2000 7:27 AM
> Subject: [PROPOSAL] Integrating Struts with XML Data
>
> > One of the desireable goals for Struts 1.0 is a closer integration with
> > XML-formatted data -- that is, a graceful way to deal with data sources
> > that produce XML data and wish to have their information displayed in an
> > HTML page. One obvious candidate technology is to use for this purpose
> > is XSLT transformations to convert the XML data to HTML or WML or
> > whatever -- but writing XSLT stylesheets is not something that most web
> > developers will be very comfortable with. An easier solution is needed
> > to deal with simple cases.
> >
> > Given the fact that Struts now includes some very powerful bean-related
> > tags like <struts-bean:define>, wouldn't it be nice if we could extend
> > those tags to deal with XML data as well? It turns out that this is
> > quite feasible ... the proposal below is an approach to extending the
> > Struts bean-related tags so that, when they are presented with a bean
> > that is an XML object (that is, an object of type org.w3c.dom.Document
> > or some reasonable subordinate object like Element), the bean tags
> > should extract property values from them similarly to the way they treat
> > Java objects. The big advantage is, a page developer would be able to
> > use essentially the same tags for cases where the data was presented as
> > XML as when the data was presented as JavaBeans or EJBs. (A similar
> > extension could be made later to deal with Rows and Columns in a JDBC
> > result set).
> >
> > In the examples below, assume that a DOM object with the following
> > structure is attached to the bean name "bean":
> >
> > <a b="1" c="2">
> > <d e="3" f="4"/>
> > <d e="5" f="6"/>
> > </a>
> > <a b="7" c="8">
> > <d e="9" f="10"/>
> > <d e="11" f="12"/>
> > </a>
> >
> > Here's the proposal -- please let me know what you think:
> >
> > (1) Extensions to <struts-bean:define>:
> >
> > If the bean referenced by the "name" attribute is a DOM object, apply
> > the syntax for simple, nested, and/or indexed property syntax to extract
> > the appropriate element or attribute from the DOM according to the
> > following rules:
> >
> > * If the final name in a nested property expression such as a.b.c
> > identifies an attribute of a selected XML element, return it as a
> > String.
> > Otherwise, return a DOM element representing the selected
> > XML element.
> >
> > * If a component of a property name expression is indexed,
> > it is zero-relative in the usual way. If it is not indexed, the
> > implied index is zero (i.e. a reference to the "a" element in
> > the example will return the first <a> element).
> >
> > These rules cause the following behavior given a "<struts-bean:define
> > name="bean" property='xxx"/>" tag, given the following values for "xxx":
> >
> > Simple property names:
> >
> > a --> (the first <a> element as a DOM object)
> >
> > b --> 1
> >
> > c --> 2
> >
> > Nested property names
> >
> > a.b --> 1
> >
> > a.c --> 2
> >
> > a.d --> <d e="3" f="4"/>
> >
> > a.d.e --> 3
> >
> > a.d.f --> 4
> >
> > Indexed property names:
> >
> > a[0] --> (the first <a> element as a DOM object)
> >
> > a[1] --> (the second <a> element as a DOM object)
> >
> > a.d --> <d e="3" f="4"/>
> >
> > a[0].d --> <d e="3" f="4"/>
> >
> > a[0].d[0] --> <d e="3" f="4"/>
> >
> > a.d[1] = <d e="5" f="6"/>
> >
> > Combination property names (examples only, not exhausitive):
> >
> > a.d[1].e --> 3
> >
> > a[1].d[1].e --> 11
> >
> > (2) Extensions to <struts-bean:write>:
> >
> > If the object referenced by the "name" and optional "property"
> > attributes is a DOM object, pretty-print it in its XML format with
> > "<" and ">" escapes for the angle brackets. This is useful in
> > debugging, and for catching property naming expression errors. It might
> > also be useful in a production application to do something similar to
> > the XSL "<xsl:select>" operation.
> >
> > (3) Extensions to <struts-bean:iterate>:
> >
> > If the object referenced by the "name" and optional "property"
> > attributes is a DOM object, iterate over the XML elements that are
> > nested inside the specified element, exposing each iterated element as a
> > DOM object:
> >
> > <struts-bean:iterate name="bean"> --> Iterate over both <a> elements
> >
> > <struts-bean:iterate name="bean" property="a"> --> Iterate over both
> > <d> elements of the first <a> element
> >
> > <struts-bean:iterate name="bean" property="a[0]"> --> Iterate over
> > both <d> elements of the first <a> element
> >
> > <struts-bean:iterate name="bean" property="a[1]"> --> Iterate over
> > both <d> elements of the second <a> element
> >
> > <struts-bean:iterate name="bean" property="a[0].d"> --> Iterate over
> > a zero length collection because there are no nested elements.
> >
> > Note that, because the <struts-bean:write> tag can be used to extract
> > appropriate properties from the individual elements being iterated over,
> > you can use these tags to create reports based on a collection of
> > "objects" that are in fact represented as XML elements, in the same way
> > that you could create reports based on an ArrayList of Java objects that
> > have properties corresponding to the attribute names of the iterated
> > elements.
> >
> > Craig McClanahan
> >
> > ====================
> > See you at ApacheCon Europe <http://www.apachecon.com>!
> > Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
> > Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
> > Applications to Tomcat
> >
Re: [PROPOSAL] Integrating Struts with XML Data
Posted by Joe Walnes <jo...@wirestation.co.uk>.
In terms of the syntax for selecting properties, would X-Path not make
sense?
Reasons:
1) It's a W3C (proposed) standard.
http://www.w3.org/TR/xpath
2) It's very easy to perform basic selections - yet powerful enought to
select just about any node/collection.
3) Allows navigation to any child node/element/attribute or collection
4) There are many existing implementations that can easily be reused.
(Apache Xalan has a nice implementation in the org.apache.xalan.xpath
package)
http://xml.apache.org/xalan/
5) Is used in XSL to select nodes, so users of either system will not have
to 're-learn' how to use it, and transition from xsl->struts and vice-versa
will be easy.
Here's some examples of X-Path:
<blah id="12">
Hello
<xx>Some text</xx>
<name first="Bob" last="Bobkins" />
<cheeses>
<cheese type="blue">Stilton</cheese>
<cheese type="soft">Brie</cheese>
<cheese type="dull">Cheddar</cheese>
<cheese type="blue">Dorset Vinney</cheese>
</cheeses>
</blah>
(I do not mean to offend any cheddar lovers by implying it is a dull
cheese - it's for the sake of example)
If the <blah> tag is the bean, other attributes can be access like:
. = Hello
@id = 12
xx = Some text
name/@first = Bob
cheeses/cheese[2] = Brie
cheeses/cheese[3]/@type = dull
Essentially, / seperates items in the node path, and @ represents
attributes. Collections can also be retrieved easily.
Incorporating an existing X-Path engine would be a lot easier (and probably
more powerful) than attempting to implement a proprietry expression language
from scratch.
my $0.03
-Joe Walnes
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Monday, October 09, 2000 7:27 AM
Subject: [PROPOSAL] Integrating Struts with XML Data
> One of the desireable goals for Struts 1.0 is a closer integration with
> XML-formatted data -- that is, a graceful way to deal with data sources
> that produce XML data and wish to have their information displayed in an
> HTML page. One obvious candidate technology is to use for this purpose
> is XSLT transformations to convert the XML data to HTML or WML or
> whatever -- but writing XSLT stylesheets is not something that most web
> developers will be very comfortable with. An easier solution is needed
> to deal with simple cases.
>
> Given the fact that Struts now includes some very powerful bean-related
> tags like <struts-bean:define>, wouldn't it be nice if we could extend
> those tags to deal with XML data as well? It turns out that this is
> quite feasible ... the proposal below is an approach to extending the
> Struts bean-related tags so that, when they are presented with a bean
> that is an XML object (that is, an object of type org.w3c.dom.Document
> or some reasonable subordinate object like Element), the bean tags
> should extract property values from them similarly to the way they treat
> Java objects. The big advantage is, a page developer would be able to
> use essentially the same tags for cases where the data was presented as
> XML as when the data was presented as JavaBeans or EJBs. (A similar
> extension could be made later to deal with Rows and Columns in a JDBC
> result set).
>
> In the examples below, assume that a DOM object with the following
> structure is attached to the bean name "bean":
>
> <a b="1" c="2">
> <d e="3" f="4"/>
> <d e="5" f="6"/>
> </a>
> <a b="7" c="8">
> <d e="9" f="10"/>
> <d e="11" f="12"/>
> </a>
>
> Here's the proposal -- please let me know what you think:
>
> (1) Extensions to <struts-bean:define>:
>
> If the bean referenced by the "name" attribute is a DOM object, apply
> the syntax for simple, nested, and/or indexed property syntax to extract
> the appropriate element or attribute from the DOM according to the
> following rules:
>
> * If the final name in a nested property expression such as a.b.c
> identifies an attribute of a selected XML element, return it as a
> String.
> Otherwise, return a DOM element representing the selected
> XML element.
>
> * If a component of a property name expression is indexed,
> it is zero-relative in the usual way. If it is not indexed, the
> implied index is zero (i.e. a reference to the "a" element in
> the example will return the first <a> element).
>
> These rules cause the following behavior given a "<struts-bean:define
> name="bean" property='xxx"/>" tag, given the following values for "xxx":
>
> Simple property names:
>
> a --> (the first <a> element as a DOM object)
>
> b --> 1
>
> c --> 2
>
> Nested property names
>
> a.b --> 1
>
> a.c --> 2
>
> a.d --> <d e="3" f="4"/>
>
> a.d.e --> 3
>
> a.d.f --> 4
>
> Indexed property names:
>
> a[0] --> (the first <a> element as a DOM object)
>
> a[1] --> (the second <a> element as a DOM object)
>
> a.d --> <d e="3" f="4"/>
>
> a[0].d --> <d e="3" f="4"/>
>
> a[0].d[0] --> <d e="3" f="4"/>
>
> a.d[1] = <d e="5" f="6"/>
>
> Combination property names (examples only, not exhausitive):
>
> a.d[1].e --> 3
>
> a[1].d[1].e --> 11
>
> (2) Extensions to <struts-bean:write>:
>
> If the object referenced by the "name" and optional "property"
> attributes is a DOM object, pretty-print it in its XML format with
> "<" and ">" escapes for the angle brackets. This is useful in
> debugging, and for catching property naming expression errors. It might
> also be useful in a production application to do something similar to
> the XSL "<xsl:select>" operation.
>
> (3) Extensions to <struts-bean:iterate>:
>
> If the object referenced by the "name" and optional "property"
> attributes is a DOM object, iterate over the XML elements that are
> nested inside the specified element, exposing each iterated element as a
> DOM object:
>
> <struts-bean:iterate name="bean"> --> Iterate over both <a> elements
>
> <struts-bean:iterate name="bean" property="a"> --> Iterate over both
> <d> elements of the first <a> element
>
> <struts-bean:iterate name="bean" property="a[0]"> --> Iterate over
> both <d> elements of the first <a> element
>
> <struts-bean:iterate name="bean" property="a[1]"> --> Iterate over
> both <d> elements of the second <a> element
>
> <struts-bean:iterate name="bean" property="a[0].d"> --> Iterate over
> a zero length collection because there are no nested elements.
>
> Note that, because the <struts-bean:write> tag can be used to extract
> appropriate properties from the individual elements being iterated over,
> you can use these tags to create reports based on a collection of
> "objects" that are in fact represented as XML elements, in the same way
> that you could create reports based on an ArrayList of Java objects that
> have properties corresponding to the attribute names of the iterated
> elements.
>
> Craig McClanahan
>
> ====================
> See you at ApacheCon Europe <http://www.apachecon.com>!
> Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
> Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
> Applications to Tomcat
>