You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Fabrice SOLLAMI <fa...@marketschemer.com> on 2000/09/05 17:14:12 UTC
COCOON.PROPERTIES
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: [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