You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Daniel Ridings <ri...@holding.gu.se> on 2000/05/10 14:48:01 UTC

dynamic production of XML

After tearing out my hair:

We get Cocoon to work with static files, no problem (but have little use
of static files).

We have a servlet that produces XML and can get Explorer 5 to process with
XSL, but not Cocoon. Well, we simply can't understand Cocoon and we're not
even really certain we have found the documentation, if there is any.

I've studied CocoonFromServlet.java. Ok, that creates a String document
and we use the Java libs to produce XML, but it's XML. So I started
wondering about:

CocoonServletRequest myReq = new CocoonServletRequest(document, req);

Ok, document here is a string, put a PrintWriter is what we get by using
the Sun package. I tried my best to find anything on CocoonServletRequest
in the API docs that came along with Cocoon but nothing's there.

import org.apache.cocoon.util.CocoonServletRequest (from the example file)
doesn't work either. The documentation makes no mention of a path:

org.apache.cocoon.util

So the bottom line. XML works wonderfully with Explorer 5
(http://www.lexilogik.com/~sofia/conc.html) but it would be nice to
present some of our work even for Netscape users. Cocoon should be a
perfect match here but it is definitely frustrating.

The servlet we have: is it what one would call a "producer"? The
terminology hasn't ripened in my mind yet.

Thanks for any direction or gentle scoldings here.

Daniel Ridings
LexiLogik AB
Erik Dahlbergsgatan 11b 6tr
411 26 Göteborg, Sweden
Tel: 031 773 47 99 Fax: 070 610 46 18


Re: dynamic production of XML

Posted by Yann <yl...@ims.ltd.uk>.
> > Cocoon produces XML on the server. What is passed to the client is HTML
for
> > instance in the case of IE5. That depends on your stylesheet.
>
> IE5 handles XML directly, so it doesn't really need to be handed HTML. OK,
> Cocoon produces XML, my servlet produces XML, now I want to integrate my
> servlet with Cocoon to let Cocoon take over the XSL processing in order to
> make bother Netscape and Explorer happy (though Explorer doesn't really
> need it, since it can handle the XSL processing itself).

Ok, I am with you now. see below.

> No, I don't want the client to render it. I want to turn the XML over to
> Cocoon and let Cocoon handle it for the clients.

By render I meant "just display it". In other words, avoiding XSL
transformations on the client.

> That is true, I know that and would dearly love to use it. But how does
> one integrate one's own producer of XML in the Cocoon working process to
> allow for this?

Well I don't know what your servlet is doing exacty and I didn't convert my
servlets into Cocoon processors so take my comments with a pich of salt. I
use XSP pages. In them I use my Java business objects. The XML is done by
including tags in my XSP or use the SQL tag lib. You could either convert
your Servlet into a Cocoon processor or use XSP and move your servlet logic
into the xsp:logic tags.

I advise you to look at the source code of some Cocoon processors, like the
SQL tag lib one. You will see which syntax to use and which package to
import. I believe that at this stage, someone more experienced than me
should help you on that specific subject.

Regards,

Yann.


Re: dynamic production of XML

Posted by Daniel Ridings <ri...@holding.gu.se>.
> Cocoon produces XML on the server. What is passed to the client is HTML for
> instance in the case of IE5. That depends on your stylesheet.

IE5 handles XML directly, so it doesn't really need to be handed HTML. OK,
Cocoon produces XML, my servlet produces XML, now I want to integrate my
servlet with Cocoon to let Cocoon take over the XSL processing in order to
make bother Netscape and Explorer happy (though Explorer doesn't really
need it, since it can handle the XSL processing itself).

> What you were doing was to generate XML from your Java Servlet and have the
> client render it. That is not how Cocoon works (although it can do that to).

No, I don't want the client to render it. I want to turn the XML over to
Cocoon and let Cocoon handle it for the clients.

> Even
> better, with Cocoon you can apply a stylesheet depending on the HTTP request
> User Agent so you can have 1 stylesheet for IE, 1 stylesheet for Netscape.
> Both stylesheets could render XML in any browser-dependant
> HTML/DHTML/you-name-it way avoiding all sort of "if browser = IE then" sort
> of obscure syntax.

That is true, I know that and would dearly love to use it. But how does
one integrate one's own producer of XML in the Cocoon working process to
allow for this?

Thanks for your resonse,


Daniel Ridings


Re: dynamic production of XML

Posted by Yann <yl...@ims.ltd.uk>.
Cocoon produces XML on the server. What is passed to the client is HTML for
instance in the case of IE5. That depends on your stylesheet.

What you were doing was to generate XML from your Java Servlet and have the
client render it. That is not how Cocoon works (although it can do that to).

If you wanted to support Netscape that wouldn't be any different. Even
better, with Cocoon you can apply a stylesheet depending on the HTTP request
User Agent so you can have 1 stylesheet for IE, 1 stylesheet for Netscape.
Both stylesheets could render XML in any browser-dependant
HTML/DHTML/you-name-it way avoiding all sort of "if browser = IE then" sort
of obscure syntax.

The bottom line: Cocoon is a big servlet that creates XML documents and uses
XSL stylesheets to render client-specific ways to display them. The
production and tronsformation of these documents is done on the server. Only
the rendering is done on the client.

Yann.


Re: dynamic production of XML

Posted by Yann <yl...@ims.ltd.uk>.
> Am I correct in concluding that you loose a lot of advantages of using
> Servlets over CGI if you mix in Cocoon?

No since you have access to the HttpServletRequest object and HttpSession
object in your XSP. You have access to the Servlet API within Cocoon.

> I have 50 million words of Swedish online with a Servlet accepting a
> request for a Swedish word from the user and then applying various
> linguistic methods (more or less making XSP very cumbersome at best) and
> returning an XML document containing the other words that the search word
> is linguistically associated with (time is associated with "from" "time"
> "to" "time"). It identifies phrases.
>
> All this requires interaction (Servlets are great here) but Cocoon seems
> to want to publish things that are known in advance (rows and columns in a
> database, things like that).

No, no. Not at all.

You can call request.getParameter in your XSP page. Therefore you deal with
data you don't know in advance. You can have one form posting your Swedish
keyword and your processor having a tag <keyword>. Then your processor will
use the content of <keyword> and lookup in a database for instance.

Something like the following line in your XSP page:

<keyword>request.getParameter("keyword")</keyword>

> Should I drop Cocoon from my wish-list (I don't want to). I'm willing to
> write a producer if I can, but like I said, the SQLprocessor seems to be
> pretty hard-coded when it comes to "what" should be queried.

That's only because you saw examples that don't use the request.getParameter
method. I myself have a Cocoon intranet site full of form posts and database
lookup.

Yann.


Re: dynamic production of XML

Posted by Mike Engelhart <me...@earthtrip.com>.
on 5/11/00 9:42 AM, Juan Jose Pablos at J.J.Pablos@bton.ac.uk wrote:

> Mike,
> 
> could you describe a bit more how do you do this?, or at least where I
> can find more info on this approach?
> Thanks.
> 
> Juan

Sure -- Also if you search through any of the JSP mailing list archives
there is bound to be a discussion of using RequestDispatchers with servlets
and JSP's which is basically the same concept.  But here's a quick
introduction.

Obviously a lot of this depends on the complexity of your application and
whether or not you need to use other classes to handle business logic, etc.
My servlets use my own objects I call RequestValidators that handle
application/domain specific tests on the form data to make sure everything
is groovy. 
Let's assume a simple example and say we can handle all our business logic
in the service() method of the servlet.

/***** BEGIN service() method of sample servlet ***/
public void service(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException
{    
  RequestDispatcher rd = null;
  try
  {
   // get parameters out of the request
   String param1 = request.getParameter("param1");
   param1 = param1 + " TESTING REQUEST DISPATCHER";
   request.setAttribute("dispatched_parameter", param1);
   request.getRequestDispatcher("responsepage.xml");
   rd.forward(request, response);
  }
  catch (Exception e)
  {
   request.setAttribute("error", "Put an error message here if you want");
   request.getRequestDispatcher("errorpage.xml");
   rd.forward(request, response);
  }
}
    
/*** END service() method of sample servlet ***/

/*** BEGIN XSP Page ***/

<?xml version="1.0"?>
<?cocoon-process type="xsp"?>
<?cocoon-process type="xslt"?>

<?xml-stylesheet href="responsepage.xsl" type="text/xsl"?>

<xsp:page language="java" xmlns:xsp="http://www.apache.org/1999/XSP/Core">
  <document>
   <xsp:logic>
    String dispatchedParam = (String)
request.getAttribute("dispatched_parameter");
   </xsp:logic>
   <param>
    <value><xsp:expr>dispatchedParam</xsp:expr></value>
   <param>
  </document>
</xsp:page>

/*** END XSP Page ***/


For this specific example you would also need to create an "errorpage.xml"
XSP document to handle Exceptions.

There are a great many different ways to do this.  Using
HttpServletRequest.setAttribute()
you can put any object into the request object and pass it along.  The nice
thing is that the lifetime of the object is only the for the life of the
request object itself so if you have an error message, you can pass it along
to the error page and not have to hold it in a session or resort to URL
rewriting.  of course if you need to save it you can stick it in a session
as well.

Hope this was clear.

Mike


Re: dynamic production of XML

Posted by Juan Jose Pablos <J....@bton.ac.uk>.
Mike,

could you describe a bit more how do you do this?, or at least where I
can find more info on this approach?


Mike Engelhart wrote:
> 
> Not at all!  I use my XSP pages in conjunction with Servlets.   Write a
> servlet that does your request processing and business logic and then put
> the data you need into the request object itself and pass it on to the XSP
> using a RequestDispatcher.  Works fantastic.
> 

Thanks.

Juan

Re: dynamic production of XML

Posted by Mike Engelhart <me...@earthtrip.com>.
on 5/11/00 3:00 AM, Daniel Ridings at ridings@holding.gu.se wrote:

> I would like to thank all for their friendly advice on this topic. I
> suppose I should have specified dynamic and _interactive_ production of
> XML through Cocoon.
> 
> 
> All this requires interaction (Servlets are great here) but Cocoon seems
> to want to publish things that are known in advance (rows and columns in a
> database, things like that).
> 
> Should I drop Cocoon from my wish-list (I don't want to). I'm willing to
> write a producer if I can, but like I said, the SQLprocessor seems to be
> pretty hard-coded when it comes to "what" should be queried.
> 
Not at all!  I use my XSP pages in conjunction with Servlets.   Write a
servlet that does your request processing and business logic and then put
the data you need into the request object itself and pass it on to the XSP
using a RequestDispatcher.  Works fantastic.

You can also as was mentioned use XSP to directly access the
HttpServletRequest but I prefer passing the request with all the processsing
already completed so that my XSP pages aren't so messy.  It's just a matter
of taste I guess.

Mike


Re: dynamic production of XML

Posted by Daniel Ridings <ri...@holding.gu.se>.
I would like to thank all for their friendly advice on this topic. I
suppose I should have specified dynamic and _interactive_ production of
XML through Cocoon.

I've gone through things like the SQLprocessor which talks about putting a
processing instruction in your xml-file (there's the static stuff again)
and the SQL query mentioned in the documentation is hard-coded, static, so
there goes your dynamic creation too.

Am I correct in concluding that you loose a lot of advantages of using
Servlets over CGI if you mix in Cocoon?

I have 50 million words of Swedish online with a Servlet accepting a
request for a Swedish word from the user and then applying various
linguistic methods (more or less making XSP very cumbersome at best) and
returning an XML document containing the other words that the search word
is linguistically associated with (time is associated with "from" "time"
"to" "time"). It identifies phrases.

All this requires interaction (Servlets are great here) but Cocoon seems
to want to publish things that are known in advance (rows and columns in a
database, things like that).

Should I drop Cocoon from my wish-list (I don't want to). I'm willing to
write a producer if I can, but like I said, the SQLprocessor seems to be
pretty hard-coded when it comes to "what" should be queried.

Once again, thanks to all!
Daniel Ridings

> On Wed, 10 May 2000, you wrote:
> > After tearing out my hair:
> > We get Cocoon to work with static files, no problem (but have little use
> > of static files).
> 
> XSP (eXtensible Server Pages) provides a general way to produce dynamic
> XML content in Cocoon
> 


Re: dynamic production of XML

Posted by Darren Scott <ds...@bluecheese.co.uk>.
Kees Jongenburger wrote:
> what i think is the answer?
> that from within a xsp page somewhere I can call a producer or a class
> that wil return  a document/document fragment

I think the answer lies in Ricardo Rocha's reply to my question along
similar lines (at least I hope). Ricardo was saying that the following
will append a document fragment to the source XML:-

> You can use "util:include-expr" to parse any expression and append it
> to the current XSP document position. Example:
> 
>   <xsp:page ...>
>     . . .
>     <util:include-expr>
>       <util:expr>
>         resultSet.getString("column_name")
>       </util:expr>
>     </util:include-expr>
>     . . .
>   </xsp:page>
> 
> This tag is available with the latest release (1.7.4) only.
> 
> For previous versions you can use <xsp:expr> and  the XSP built-in
> parser. Example:
> 
>   <xsp:page ...>
>     . . .
>     <util:include-expr>
>       <xsp:expr>
>         this.xspParser.parse(
>           new InputSource(
>             new StringReader(
>             resultSet.getString("column_name")
>             )
>           )
>         ).getDocumentElement()
>       </xsp:expr>
>     </util:include-expr>
>     . . .
>   </xsp:page>

Darren Scott
Production Director
bluecheese.co.uk

Re: dynamic production of XML

Posted by Tsoloane Moahloli <ts...@zen.co.za>.
I must agree with kees on this point.  I too am following the 
producer/processor route and creating xml output.   Also makes any xml 
files smaller.

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 5/11/00, 7:58:40 AM, Kees Jongenburger <ke...@netlinq.nl> wrote 
regarding Re: dynamic production of XML:


> i don't quite agree on XSP beeing a way to produce dynamic 
content(yet).

> why ?(and this the way i understand XSP) i have 2 choices.

> 1 the jsp like aproach:
> using xsp:expr and sush in the content
> wich we know is not the right way because you dont realy split content 
and
> logic

> 2 the lib aproach
> like using <util:date/>
> in wich case the default behaviour is like calling a function wich
> returnss a String.
> in that case I dont return XML so i can't process it afterwards.

> i have posted this earlyer as a question
> http://xml-archive.webweaving.org/xml-archive-cocoon-users/2768.html
> and the answer was to "hack" into the lib and calling
> xspCurrentNode.appendChild from within a xsp page

> now i dont realy whant to do this because this not the clean way the 
rest
> of cocoon works.(but i am currently doing it).

> what i think is the answer?
> that from within a xsp page somewhere I can call a producer or a class
> that wil return  a document/document fragment

> Kees Jongenburger

> On Wed, 10 May 2000, Ricardo Rocha wrote:

> > On Wed, 10 May 2000, you wrote:
> > > After tearing out my hair:
> > > We get Cocoon to work with static files, no problem (but have little 
use
> > > of static files).
> >
> > XSP (eXtensible Server Pages) provides a general way to produce 
dynamic
> > XML content in Cocoon
> >
> > > Well, we simply can't understand Cocoon and we're not
> > > even really certain we have found the documentation, if there is any.
> >
> > Check http://xml.apache.org/cocoon/xsp.html


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org




Re: dynamic production of XML

Posted by Mike Engelhart <me...@earthtrip.com>.
on 5/11/00 2:58 AM, Kees Jongenburger at keesj@netlinq.nl wrote:

> what i think is the answer?
> that from within a xsp page somewhere I can call a producer or a class
> that wil return  a document/document fragment
What's the difference between that and an XSP???  XSP is not about
displaying the data to a browser or other program, it's about creating an
XML document.  It seems that everyone has it confused with JSP.   XSP is for
generating dynamic XML documents in an easily manipulated way so programmers
don't have to dick around with DOM or SAX.    the XSLT layer is where the
separation of context occurs.

Mike


Re: dynamic production of XML

Posted by Kees Jongenburger <ke...@netlinq.nl>.
i don't quite agree on XSP beeing a way to produce dynamic content(yet).

why ?(and this the way i understand XSP) i have 2 choices.

1 the jsp like aproach:
using xsp:expr and sush in the content
wich we know is not the right way because you dont realy split content and
logic

2 the lib aproach
like using <util:date/>
in wich case the default behaviour is like calling a function wich
returnss a String.
in that case I dont return XML so i can't process it afterwards.

i have posted this earlyer as a question 
http://xml-archive.webweaving.org/xml-archive-cocoon-users/2768.html
and the answer was to "hack" into the lib and calling
xspCurrentNode.appendChild from within a xsp page

now i dont realy whant to do this because this not the clean way the rest
of cocoon works.(but i am currently doing it).

what i think is the answer?
that from within a xsp page somewhere I can call a producer or a class  
that wil return  a document/document fragment

Kees Jongenburger

On Wed, 10 May 2000, Ricardo Rocha wrote:

> On Wed, 10 May 2000, you wrote:
> > After tearing out my hair:
> > We get Cocoon to work with static files, no problem (but have little use
> > of static files).
> 
> XSP (eXtensible Server Pages) provides a general way to produce dynamic
> XML content in Cocoon
> 
> > Well, we simply can't understand Cocoon and we're not
> > even really certain we have found the documentation, if there is any.
> 
> Check http://xml.apache.org/cocoon/xsp.html


Re: dynamic production of XML

Posted by Ricardo Rocha <ri...@apache.org>.
On Wed, 10 May 2000, you wrote:
> After tearing out my hair:
> We get Cocoon to work with static files, no problem (but have little use
> of static files).

XSP (eXtensible Server Pages) provides a general way to produce dynamic
XML content in Cocoon

> Well, we simply can't understand Cocoon and we're not
> even really certain we have found the documentation, if there is any.

Check http://xml.apache.org/cocoon/xsp.html