You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Jens Lorenz <je...@interface-business.de> on 2000/09/04 10:57:23 UTC
SAX & DOM in tag libs (was: Re: Aha! got it! 64k limit)
----- Original Message -----
From: Stefano Mazzocchi <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Saturday, September 02, 2000 12:28 AM
Subject: Re: Aha! got it! 64k limit(was: new version of the sql
logicsheetunder development)
> > Well. What about compiled tag libs ? (java class together with
stylesheet,
> > as the provided ones - C1)
> >
> > I've tried to find a way to avoid the DOM stuff, but I haven't found one
...
> > (and I'm now heavily depending on the DOM stuff in order to create
> > XML fragments)
> >
> > Is there an independent _and_ efficient way to create XML fragments ?
> >
> > I've tried building long strings with the XML text in it, but the
> > xspParser (used by util:include-expr) need's a looooong time to parse
> > such an string ... (much too long)
>
> Can you elaborate more? If what we have today forces you to use DOM
> there is something wrong in the design and we should fix this in C1 ASAP
> before you guys have too much legacy stuff to port.
>
> Please, give us more info so that we can fix the problems (your code
> should be totally DOM agnostic and XSP should enforce this).
Well. I'll try to ...
So. Basically I render Java class contents into XML Code ... (The data
originates in a DB, but there are Beans between the DB and my tag lib
provided some simple document and content managment system)
Let's say I 've a bean containing some items (other beans) and some basic
properties ...
class Bean {
public int ClassId;
public Bean[] getItems();
}
and I want to have something like:
<bean>
<classid>1</classid>
<items>
<bean>
<classid>2</classid>
</bean>
<bean>
<classid>3</classid>
</bean>
</items>
</bean>
on this structure I could use some XSLT in order to make in human readable
...
The thing I do now is having an XSPBeanLibrary with many static functions
providing the functionality and all the dynamic data is put into the
HttpSession of the Servlet-Container ...
class XSPBeanLibrary {
public static Element getBean(int ClassId);
}
together with a logic sheet
<xsl:template match="getBean">
<xsp:expr>
XSPBeanLibrary.getBean(Integer.parseInt(<xsl:value-of select="ClassId">)
</xsp:expr>
</xsl:template>
Thus, <xsp:expr> in C2 had to convert all my DOM Element stuff (and also
Document to create the Elements and Nodes) to SAX. Though this is not
impossible (as there are already several DOM2SAX converters) it's
wastes more time and memory, than using SAX direct. (for example
via xsp:element and xsp:attribute)
... and my Beans may have many items and properties ... I'll use some
mechanism to select only certain, but for the application there will
be a tree of the beans to be displayed ... So I've to call getBean
recursively to create an XML tree which I've to insert into the
original XML tree (thus replacing <getBean>) ...
And I also do not want to switch to clean-page model, since I've done
already too much with tag libs ... and they also give me the ability
to separate the xsp logic from bean logic ... (important to have more
than one person work on a tag library and having more than one class
with logic)
So. The big question is: how to create XML fragments in the tag library
without depending on the DOM/SAX/whatever_there_will_be_in_some_years
stuff but also not wasting too much time and memory in converting ...
... maybe it's just very simple, but I don't see any good solution ...
Regards,
Jens
--
jens.lorenz@interface-business.de
interface-business GmbH \\|//
Tolkewitzer Strasse 49 (o o)
01277 Dresden ~~~~oOOo~(_)~oOOo~~~~
Germany
RE: [Cocoon Users] Re: COCOON.PROPERTIES
Posted by Fabrice SOLLAMI <fa...@marketschemer.com>.
Thanks a lot.
-----Message d'origine-----
De : cocoon-users-admin@lists.real-time.com
[mailto:cocoon-users-admin@lists.real-time.com]De la part de Berin
Loritsch
Envoye : mercredi 6 septembre 2000 15:35
A : cocoon-users@xml.apache.org
Objet : [Cocoon Users] Re: COCOON.PROPERTIES
Fabrice SOLLAMI wrote:
>
> Hello,
>
> It appears that in the web.xml xe have to specify that :
> <servlet>
> <servlet-name>org.apache.cocoon.Cocoon</servlet-name>
> <servlet-class>org.apache.cocoon.Cocoon</servlet-class>
> <init-param>
> <param-name>properties</param-name>
> <param-value>cocoon.properties</param-value>
>
> </init-param>
> </servlet>
>
> But in this case as soon as you want to process xml/xsl you have to put a
> copy of the cocoon.properties in the same folder.
>
> SO is their a way to set an absolute path to the cocoon.properties file
such
> asd:\tomcat\conf\cocoon.properties.
This is a *feature* of Servlet 2.2 for completely pluggable webapps. Any
properties files and such must be relative _within_ the its context. In
other words, the path
<param-value>../../conf/cocoon.properties</param-value>
should NOT work (because you are leaving your context). Cocoon, respecting
this feature, only allows absolute paths if you are using a pre-Servlet 2.2
engine. You do have the option to allow you to place the properties in a
non-readable folder like this:
<param-value>WEB-INF/cocoon.properties</param-value>
All will be well with the world, except for one thing: not all servlet
vendors
are equal and there are at least one or two that don't allow anything other
than your web.xml, /classes, and /lib files or directories within that
particular directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
_______________________________________________
cocoon-users mailing list
cocoon-users@lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/cocoon-users
Re: COCOON.PROPERTIES
Posted by Berin Loritsch <bl...@infoplanning.com>.
Fabrice SOLLAMI wrote:
>
> Hello,
>
> It appears that in the web.xml xe have to specify that :
> <servlet>
> <servlet-name>org.apache.cocoon.Cocoon</servlet-name>
> <servlet-class>org.apache.cocoon.Cocoon</servlet-class>
> <init-param>
> <param-name>properties</param-name>
> <param-value>cocoon.properties</param-value>
>
> </init-param>
> </servlet>
>
> But in this case as soon as you want to process xml/xsl you have to put a
> copy of the cocoon.properties in the same folder.
>
> SO is their a way to set an absolute path to the cocoon.properties file such
> asd:\tomcat\conf\cocoon.properties.
This is a *feature* of Servlet 2.2 for completely pluggable webapps. Any
properties files and such must be relative _within_ the its context. In
other words, the path <param-value>../../conf/cocoon.properties</param-value>
should NOT work (because you are leaving your context). Cocoon, respecting
this feature, only allows absolute paths if you are using a pre-Servlet 2.2
engine. You do have the option to allow you to place the properties in a
non-readable folder like this:
<param-value>WEB-INF/cocoon.properties</param-value>
All will be well with the world, except for one thing: not all servlet vendors
are equal and there are at least one or two that don't allow anything other
than your web.xml, /classes, and /lib files or directories within that
particular directory.
COCOON.PROPERTIES
Posted by Fabrice SOLLAMI <fa...@marketschemer.com>.
Hello,
It appears that in the web.xml xe have to specify that :
<servlet>
<servlet-name>org.apache.cocoon.Cocoon</servlet-name>
<servlet-class>org.apache.cocoon.Cocoon</servlet-class>
<init-param>
<param-name>properties</param-name>
<param-value>cocoon.properties</param-value>
</init-param>
</servlet>
But in this case as soon as you want to process xml/xsl you have to put a
copy of the cocoon.properties in the same folder.
SO is their a way to set an absolute path to the cocoon.properties file such
asd:\tomcat\conf\cocoon.properties.
Thanks.
Fabrice
COCOON.PROPERTIES
Posted by Fabrice SOLLAMI <fa...@marketschemer.com>.
Hello
Is their a way to have only one cocoon.properties file ?
Thanks
-----Message d'origine-----
De : cocoon-users-admin@lists.real-time.com
[mailto:cocoon-users-admin@lists.real-time.com]De la part de Stefano
Mazzocchi
Envoye : mardi 5 septembre 2000 17:04
A : cocoon-users@xml.apache.org
Objet : [Cocoon Users] Re: SAX & DOM in tag libs (was: Re: Aha! got it!
64k limit)
Jens Lorenz wrote:
>
> ----- Original Message -----
> From: Stefano Mazzocchi <st...@apache.org>
> To: <co...@xml.apache.org>
> Sent: Monday, September 04, 2000 12:56 PM
> Subject: Re: SAX & DOM in tag libs (was: Re: Aha! got it! 64k limit)
>
> > > > > Well. What about compiled tag libs ? (java class together with
> > > stylesheet,
> > > > > as the provided ones - C1)
> > > > >
> > > > > I've tried to find a way to avoid the DOM stuff, but I haven't
found
> one
> > > ...
> > > > > (and I'm now heavily depending on the DOM stuff in order to create
> > > > > XML fragments)
> > > > >
> > > > > Is there an independent _and_ efficient way to create XML
fragments
> ?
> > > > >
> > > > > I've tried building long strings with the XML text in it, but the
> > > > > xspParser (used by util:include-expr) need's a looooong time to
> parse
> > > > > such an string ... (much too long)
> > > >
> > > > Can you elaborate more? If what we have today forces you to use DOM
> > > > there is something wrong in the design and we should fix this in C1
> ASAP
> > > > before you guys have too much legacy stuff to port.
> > > >
> > > > Please, give us more info so that we can fix the problems (your code
> > > > should be totally DOM agnostic and XSP should enforce this).
> > >
> > > Well. I'll try to ...
> > >
> > > So. Basically I render Java class contents into XML Code ... (The data
> > > originates in a DB, but there are Beans between the DB and my tag lib
> > > provided some simple document and content managment system)
> > >
> > > Let's say I 've a bean containing some items (other beans) and some
> basic
> > > properties ...
> > >
> > > class Bean {
> > > public int ClassId;
> > > public Bean[] getItems();
> > > }
> > >
> > > and I want to have something like:
> > >
> > > <bean>
> > > <classid>1</classid>
> > > <items>
> > > <bean>
> > > <classid>2</classid>
> > > </bean>
> > > <bean>
> > > <classid>3</classid>
> > > </bean>
> > > </items>
> > > </bean>
> > >
> > > on this structure I could use some XSLT in order to make in human
> readable
> > > ...
> > >
> > > The thing I do now is having an XSPBeanLibrary with many static
> functions
> > > providing the functionality and all the dynamic data is put into the
> > > HttpSession of the Servlet-Container ...
> > >
> > > class XSPBeanLibrary {
> > > public static Element getBean(int ClassId);
> > > }
> > >
> > > together with a logic sheet
> > >
> > > <xsl:template match="getBean">
> > > <xsp:expr>
> > > XSPBeanLibrary.getBean(Integer.parseInt(<xsl:value-of
> select="ClassId">)
> > > </xsp:expr>
> > > </xsl:template>
> > >
> > > Thus, <xsp:expr> in C2 had to convert all my DOM Element stuff (and
also
> > > Document to create the Elements and Nodes) to SAX. Though this is not
> > > impossible (as there are already several DOM2SAX converters) it's
> > > wastes more time and memory, than using SAX direct. (for example
> > > via xsp:element and xsp:attribute)
> > >
> > > ... and my Beans may have many items and properties ... I'll use some
> > > mechanism to select only certain, but for the application there will
> > > be a tree of the beans to be displayed ... So I've to call getBean
> > > recursively to create an XML tree which I've to insert into the
> > > original XML tree (thus replacing <getBean>) ...
> > >
> > > And I also do not want to switch to clean-page model, since I've done
> > > already too much with tag libs ... and they also give me the ability
> > > to separate the xsp logic from bean logic ... (important to have more
> > > than one person work on a tag library and having more than one class
> > > with logic)
> > >
> > > So. The big question is: how to create XML fragments in the tag
library
> > > without depending on the DOM/SAX/whatever_there_will_be_in_some_years
> > > stuff but also not wasting too much time and memory in converting ...
> >
> > Ok, your concern is serious and my answer is solid: implement XObject!
> >
> > This class provides you with two methods:
> >
> > void toSAX(ContentHandler handler);
> >
> > DocumentFragment toDOM();
> >
> > and in C2 we'll provide abstract classes that allow you to implement
> > just one of the two (in your case toDOM() since your logic is DOM based)
> > and let Cocoon generate the SAX events. Or implement the toSAX method
> > directly and the toDOM method will be ignored.
> >
> > When XML-izing complex information XSP logic should not be used (like
> > you are doing), there is no easy way around it.
>
> I'm afraid I don't understand ... Do you mean, that I do not use XSP
> logic (well, at least I use xsp:expr) and that's good or that I use
> XSP logic and I should try another way ... (if, which ?) ...
If you use a DOM instance _directly_ inside xsp:logic your stuff won't
be portable. Clear and simple.
Then up to you to use it or not, after you are aware of this.
> > But returning XObjects to xsp:expr elements guarantees future
> > compatibility with new document creation technology.
>
> Well, I'm afraid I don't get the point in XObject ... It's an interface
> in org.apache.cocoon.framework providing your two methods ...
>
> Well assuming the model above, shall I extend class Bean and implement
> XObject and implement the toDOM() method an returning these Objects
> to <xsp:expr> statement ?
This is correct.
> e.g.:
>
> public class XBean extends Bean implements XObject {
> void toDOM(org.w3c.dom.Node node)
> {
> Node.appendChild(node.getOwnerDocument().createTextNode("foobar"));
> }
>
> void toSAX(org.xml.sax.DocumentHandler handler)
> {
> // do nothing ...
> }
> }
>
> Well, C1 will call always toDOM() and C2 will check for toDOM() method and
> if present use it, otherwise use toSAX() ?
C2 will probably always call toSAX(), but we will provide an
AbstractXObject method that will wrap around your toDOM() method to
crawl the DOM object and throw SAX events.
At the end, porting would just mean changing from
public myclass implements XObject
to
public myclass extends AbstractXObject
so my only suggestion is to make sure your bean doesn't extend directly
any other class (you can do it with your internal classes)
> Or is there another, better way ?
Better? I think this is just as simple as possible, but I'm open to
suggestions, as always.
> Are there examples ? (a grep 'toDOM' `find ~/cvs/cocoon2` didn't find
> anything)
This is not yet implemented in C2.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
_______________________________________________
cocoon-users mailing list
cocoon-users@lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/cocoon-users
Re: SAX & DOM in tag libs (was: Re: Aha! got it! 64k limit)
Posted by Stefano Mazzocchi <st...@apache.org>.
Jens Lorenz wrote:
>
> ----- Original Message -----
> From: Stefano Mazzocchi <st...@apache.org>
> To: <co...@xml.apache.org>
> Sent: Monday, September 04, 2000 12:56 PM
> Subject: Re: SAX & DOM in tag libs (was: Re: Aha! got it! 64k limit)
>
> > > > > Well. What about compiled tag libs ? (java class together with
> > > stylesheet,
> > > > > as the provided ones - C1)
> > > > >
> > > > > I've tried to find a way to avoid the DOM stuff, but I haven't found
> one
> > > ...
> > > > > (and I'm now heavily depending on the DOM stuff in order to create
> > > > > XML fragments)
> > > > >
> > > > > Is there an independent _and_ efficient way to create XML fragments
> ?
> > > > >
> > > > > I've tried building long strings with the XML text in it, but the
> > > > > xspParser (used by util:include-expr) need's a looooong time to
> parse
> > > > > such an string ... (much too long)
> > > >
> > > > Can you elaborate more? If what we have today forces you to use DOM
> > > > there is something wrong in the design and we should fix this in C1
> ASAP
> > > > before you guys have too much legacy stuff to port.
> > > >
> > > > Please, give us more info so that we can fix the problems (your code
> > > > should be totally DOM agnostic and XSP should enforce this).
> > >
> > > Well. I'll try to ...
> > >
> > > So. Basically I render Java class contents into XML Code ... (The data
> > > originates in a DB, but there are Beans between the DB and my tag lib
> > > provided some simple document and content managment system)
> > >
> > > Let's say I 've a bean containing some items (other beans) and some
> basic
> > > properties ...
> > >
> > > class Bean {
> > > public int ClassId;
> > > public Bean[] getItems();
> > > }
> > >
> > > and I want to have something like:
> > >
> > > <bean>
> > > <classid>1</classid>
> > > <items>
> > > <bean>
> > > <classid>2</classid>
> > > </bean>
> > > <bean>
> > > <classid>3</classid>
> > > </bean>
> > > </items>
> > > </bean>
> > >
> > > on this structure I could use some XSLT in order to make in human
> readable
> > > ...
> > >
> > > The thing I do now is having an XSPBeanLibrary with many static
> functions
> > > providing the functionality and all the dynamic data is put into the
> > > HttpSession of the Servlet-Container ...
> > >
> > > class XSPBeanLibrary {
> > > public static Element getBean(int ClassId);
> > > }
> > >
> > > together with a logic sheet
> > >
> > > <xsl:template match="getBean">
> > > <xsp:expr>
> > > XSPBeanLibrary.getBean(Integer.parseInt(<xsl:value-of
> select="ClassId">)
> > > </xsp:expr>
> > > </xsl:template>
> > >
> > > Thus, <xsp:expr> in C2 had to convert all my DOM Element stuff (and also
> > > Document to create the Elements and Nodes) to SAX. Though this is not
> > > impossible (as there are already several DOM2SAX converters) it's
> > > wastes more time and memory, than using SAX direct. (for example
> > > via xsp:element and xsp:attribute)
> > >
> > > ... and my Beans may have many items and properties ... I'll use some
> > > mechanism to select only certain, but for the application there will
> > > be a tree of the beans to be displayed ... So I've to call getBean
> > > recursively to create an XML tree which I've to insert into the
> > > original XML tree (thus replacing <getBean>) ...
> > >
> > > And I also do not want to switch to clean-page model, since I've done
> > > already too much with tag libs ... and they also give me the ability
> > > to separate the xsp logic from bean logic ... (important to have more
> > > than one person work on a tag library and having more than one class
> > > with logic)
> > >
> > > So. The big question is: how to create XML fragments in the tag library
> > > without depending on the DOM/SAX/whatever_there_will_be_in_some_years
> > > stuff but also not wasting too much time and memory in converting ...
> >
> > Ok, your concern is serious and my answer is solid: implement XObject!
> >
> > This class provides you with two methods:
> >
> > void toSAX(ContentHandler handler);
> >
> > DocumentFragment toDOM();
> >
> > and in C2 we'll provide abstract classes that allow you to implement
> > just one of the two (in your case toDOM() since your logic is DOM based)
> > and let Cocoon generate the SAX events. Or implement the toSAX method
> > directly and the toDOM method will be ignored.
> >
> > When XML-izing complex information XSP logic should not be used (like
> > you are doing), there is no easy way around it.
>
> I'm afraid I don't understand ... Do you mean, that I do not use XSP
> logic (well, at least I use xsp:expr) and that's good or that I use
> XSP logic and I should try another way ... (if, which ?) ...
If you use a DOM instance _directly_ inside xsp:logic your stuff won't
be portable. Clear and simple.
Then up to you to use it or not, after you are aware of this.
> > But returning XObjects to xsp:expr elements guarantees future
> > compatibility with new document creation technology.
>
> Well, I'm afraid I don't get the point in XObject ... It's an interface
> in org.apache.cocoon.framework providing your two methods ...
>
> Well assuming the model above, shall I extend class Bean and implement
> XObject and implement the toDOM() method an returning these Objects
> to <xsp:expr> statement ?
This is correct.
> e.g.:
>
> public class XBean extends Bean implements XObject {
> void toDOM(org.w3c.dom.Node node)
> {
> Node.appendChild(node.getOwnerDocument().createTextNode("foobar"));
> }
>
> void toSAX(org.xml.sax.DocumentHandler handler)
> {
> // do nothing ...
> }
> }
>
> Well, C1 will call always toDOM() and C2 will check for toDOM() method and
> if present use it, otherwise use toSAX() ?
C2 will probably always call toSAX(), but we will provide an
AbstractXObject method that will wrap around your toDOM() method to
crawl the DOM object and throw SAX events.
At the end, porting would just mean changing from
public myclass implements XObject
to
public myclass extends AbstractXObject
so my only suggestion is to make sure your bean doesn't extend directly
any other class (you can do it with your internal classes)
> Or is there another, better way ?
Better? I think this is just as simple as possible, but I'm open to
suggestions, as always.
> Are there examples ? (a grep 'toDOM' `find ~/cvs/cocoon2` didn't find
> anything)
This is not yet implemented in C2.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: mailing-list-archive down
Posted by Peter Wuebbelt <Pe...@Wuebbelt.de>.
> is there another chance to get the old mails?
> the archive on http://xml-archive.webweaving.org/xml-archive-cocoon-users
> is down for at least one week...
>
you can either use
http://mailman.real-time.com/pipermail/cocoon-users/ or
http://mailman.real-time.com/rte-cocoon/ in case you need a search engine.
perhaps somebody can alter the URL the webpages is pointing to.
the page above shows the some message for at least 4 weeks .... :-(
regards
Peter Wuebbelt
mailing-list-archive down
Posted by Dieter Piringer <dp...@orange-interactive.de>.
is there another chance to get the old mails?
the archive on http://xml-archive.webweaving.org/xml-archive-cocoon-users
is down for at least one week...
thank you,
dieter piringer
dp@orange-interactive.de
Re: SAX & DOM in tag libs (was: Re: Aha! got it! 64k limit)
Posted by Jens Lorenz <je...@interface-business.de>.
----- Original Message -----
From: Stefano Mazzocchi <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Monday, September 04, 2000 12:56 PM
Subject: Re: SAX & DOM in tag libs (was: Re: Aha! got it! 64k limit)
> > > > Well. What about compiled tag libs ? (java class together with
> > stylesheet,
> > > > as the provided ones - C1)
> > > >
> > > > I've tried to find a way to avoid the DOM stuff, but I haven't found
one
> > ...
> > > > (and I'm now heavily depending on the DOM stuff in order to create
> > > > XML fragments)
> > > >
> > > > Is there an independent _and_ efficient way to create XML fragments
?
> > > >
> > > > I've tried building long strings with the XML text in it, but the
> > > > xspParser (used by util:include-expr) need's a looooong time to
parse
> > > > such an string ... (much too long)
> > >
> > > Can you elaborate more? If what we have today forces you to use DOM
> > > there is something wrong in the design and we should fix this in C1
ASAP
> > > before you guys have too much legacy stuff to port.
> > >
> > > Please, give us more info so that we can fix the problems (your code
> > > should be totally DOM agnostic and XSP should enforce this).
> >
> > Well. I'll try to ...
> >
> > So. Basically I render Java class contents into XML Code ... (The data
> > originates in a DB, but there are Beans between the DB and my tag lib
> > provided some simple document and content managment system)
> >
> > Let's say I 've a bean containing some items (other beans) and some
basic
> > properties ...
> >
> > class Bean {
> > public int ClassId;
> > public Bean[] getItems();
> > }
> >
> > and I want to have something like:
> >
> > <bean>
> > <classid>1</classid>
> > <items>
> > <bean>
> > <classid>2</classid>
> > </bean>
> > <bean>
> > <classid>3</classid>
> > </bean>
> > </items>
> > </bean>
> >
> > on this structure I could use some XSLT in order to make in human
readable
> > ...
> >
> > The thing I do now is having an XSPBeanLibrary with many static
functions
> > providing the functionality and all the dynamic data is put into the
> > HttpSession of the Servlet-Container ...
> >
> > class XSPBeanLibrary {
> > public static Element getBean(int ClassId);
> > }
> >
> > together with a logic sheet
> >
> > <xsl:template match="getBean">
> > <xsp:expr>
> > XSPBeanLibrary.getBean(Integer.parseInt(<xsl:value-of
select="ClassId">)
> > </xsp:expr>
> > </xsl:template>
> >
> > Thus, <xsp:expr> in C2 had to convert all my DOM Element stuff (and also
> > Document to create the Elements and Nodes) to SAX. Though this is not
> > impossible (as there are already several DOM2SAX converters) it's
> > wastes more time and memory, than using SAX direct. (for example
> > via xsp:element and xsp:attribute)
> >
> > ... and my Beans may have many items and properties ... I'll use some
> > mechanism to select only certain, but for the application there will
> > be a tree of the beans to be displayed ... So I've to call getBean
> > recursively to create an XML tree which I've to insert into the
> > original XML tree (thus replacing <getBean>) ...
> >
> > And I also do not want to switch to clean-page model, since I've done
> > already too much with tag libs ... and they also give me the ability
> > to separate the xsp logic from bean logic ... (important to have more
> > than one person work on a tag library and having more than one class
> > with logic)
> >
> > So. The big question is: how to create XML fragments in the tag library
> > without depending on the DOM/SAX/whatever_there_will_be_in_some_years
> > stuff but also not wasting too much time and memory in converting ...
>
> Ok, your concern is serious and my answer is solid: implement XObject!
>
> This class provides you with two methods:
>
> void toSAX(ContentHandler handler);
>
> DocumentFragment toDOM();
>
> and in C2 we'll provide abstract classes that allow you to implement
> just one of the two (in your case toDOM() since your logic is DOM based)
> and let Cocoon generate the SAX events. Or implement the toSAX method
> directly and the toDOM method will be ignored.
>
> When XML-izing complex information XSP logic should not be used (like
> you are doing), there is no easy way around it.
I'm afraid I don't understand ... Do you mean, that I do not use XSP
logic (well, at least I use xsp:expr) and that's good or that I use
XSP logic and I should try another way ... (if, which ?) ...
> But returning XObjects to xsp:expr elements guarantees future
> compatibility with new document creation technology.
Well, I'm afraid I don't get the point in XObject ... It's an interface
in org.apache.cocoon.framework providing your two methods ...
Well assuming the model above, shall I extend class Bean and implement
XObject and implement the toDOM() method an returning these Objects
to <xsp:expr> statement ?
e.g.:
public class XBean extends Bean implements XObject {
void toDOM(org.w3c.dom.Node node)
{
Node.appendChild(node.getOwnerDocument().createTextNode("foobar"));
}
void toSAX(org.xml.sax.DocumentHandler handler)
{
// do nothing ...
}
}
Well, C1 will call always toDOM() and C2 will check for toDOM() method and
if present use it, otherwise use toSAX() ?
Or is there another, better way ?
Are there examples ? (a grep 'toDOM' `find ~/cvs/cocoon2` didn't find
anything)
Regards,
Jens
--
jens.lorenz@interface-business.de
interface-business GmbH \\|//
Tolkewitzer Strasse 49 (o o)
01277 Dresden ~~~~oOOo~(_)~oOOo~~~~
Germany
Re: SAX & DOM in tag libs (was: Re: Aha! got it! 64k limit)
Posted by Stefano Mazzocchi <st...@apache.org>.
Jens Lorenz wrote:
>
> ----- Original Message -----
> From: Stefano Mazzocchi <st...@apache.org>
> To: <co...@xml.apache.org>
> Sent: Saturday, September 02, 2000 12:28 AM
> Subject: Re: Aha! got it! 64k limit(was: new version of the sql
> logicsheetunder development)
>
> > > Well. What about compiled tag libs ? (java class together with
> stylesheet,
> > > as the provided ones - C1)
> > >
> > > I've tried to find a way to avoid the DOM stuff, but I haven't found one
> ...
> > > (and I'm now heavily depending on the DOM stuff in order to create
> > > XML fragments)
> > >
> > > Is there an independent _and_ efficient way to create XML fragments ?
> > >
> > > I've tried building long strings with the XML text in it, but the
> > > xspParser (used by util:include-expr) need's a looooong time to parse
> > > such an string ... (much too long)
> >
> > Can you elaborate more? If what we have today forces you to use DOM
> > there is something wrong in the design and we should fix this in C1 ASAP
> > before you guys have too much legacy stuff to port.
> >
> > Please, give us more info so that we can fix the problems (your code
> > should be totally DOM agnostic and XSP should enforce this).
>
> Well. I'll try to ...
>
> So. Basically I render Java class contents into XML Code ... (The data
> originates in a DB, but there are Beans between the DB and my tag lib
> provided some simple document and content managment system)
>
> Let's say I 've a bean containing some items (other beans) and some basic
> properties ...
>
> class Bean {
> public int ClassId;
> public Bean[] getItems();
> }
>
> and I want to have something like:
>
> <bean>
> <classid>1</classid>
> <items>
> <bean>
> <classid>2</classid>
> </bean>
> <bean>
> <classid>3</classid>
> </bean>
> </items>
> </bean>
>
> on this structure I could use some XSLT in order to make in human readable
> ...
>
> The thing I do now is having an XSPBeanLibrary with many static functions
> providing the functionality and all the dynamic data is put into the
> HttpSession of the Servlet-Container ...
>
> class XSPBeanLibrary {
> public static Element getBean(int ClassId);
> }
>
> together with a logic sheet
>
> <xsl:template match="getBean">
> <xsp:expr>
> XSPBeanLibrary.getBean(Integer.parseInt(<xsl:value-of select="ClassId">)
> </xsp:expr>
> </xsl:template>
>
> Thus, <xsp:expr> in C2 had to convert all my DOM Element stuff (and also
> Document to create the Elements and Nodes) to SAX. Though this is not
> impossible (as there are already several DOM2SAX converters) it's
> wastes more time and memory, than using SAX direct. (for example
> via xsp:element and xsp:attribute)
>
> ... and my Beans may have many items and properties ... I'll use some
> mechanism to select only certain, but for the application there will
> be a tree of the beans to be displayed ... So I've to call getBean
> recursively to create an XML tree which I've to insert into the
> original XML tree (thus replacing <getBean>) ...
>
> And I also do not want to switch to clean-page model, since I've done
> already too much with tag libs ... and they also give me the ability
> to separate the xsp logic from bean logic ... (important to have more
> than one person work on a tag library and having more than one class
> with logic)
>
> So. The big question is: how to create XML fragments in the tag library
> without depending on the DOM/SAX/whatever_there_will_be_in_some_years
> stuff but also not wasting too much time and memory in converting ...
Ok, your concern is serious and my answer is solid: implement XObject!
This class provides you with two methods:
void toSAX(ContentHandler handler);
DocumentFragment toDOM();
and in C2 we'll provide abstract classes that allow you to implement
just one of the two (in your case toDOM() since your logic is DOM based)
and let Cocoon generate the SAX events. Or implement the toSAX method
directly and the toDOM method will be ignored.
When XML-izing complex information XSP logic should not be used (like
you are doing), there is no easy way around it.
But returning XObjects to xsp:expr elements guarantees future
compatibility with new document creation technology.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------