cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brent L Johnson" <>
Subject Re: [c1] xsp:logic compiling
Date Mon, 06 Aug 2001 17:44:20 GMT
OK - I think I see where my problem is.  I've been reading through Cocoon1
docs this whole time and didn't really see much information about
logicsheets (until following the link you sent).

Basically, what I'm trying to do is keep all database queries, all dynamic
code, everything development related out of the XML document (which is
pretty much my purpose of using Cocoon in the first place).  Right now, I've
got my own logicsheet (intranet-logic.xsl) and stylesheet (intranet.xsl).
Im doing an "import" in my logicsheet and importing the authentication
logicsheet (since I assume you can't refer to multiple logicsheets in a
single XML file).

So - as I understand it from a concept point of view:
* xml document - holds all the content that will be displayed on the web
(using tags defined in intranet.xsl and intranet-logic.xsl)
* xsl stylesheet - defines the custom tags (like <page>) by transforming the
<page> into html
* xsl logicsheet - contains all programatic information - all dynamic xsp
code (and functions similar to the stylesheet)

The problem with this though - is I'm not sure I understand the relationship
of the logicsheet to the stylesheet.  If I want to do something simple like
check a parameter in the stylesheet to decide what HTML to show, it becomes
a bit of a pain.  I can't seem to use the request logicsheet from inside my
stylesheet document (i can, but it never returns anything)... so I have to
create a special tag in my logicsheet which then uses the request logicsheet
to read the value.

But even with this, I've noticed something strange when doing this inside my
logicsheet... here is the code:
<xsl:variable name="screen"><request:get-parameter

If I do this, then attempt to do an xsl:choose on it, it never works and
always falls to the otherwise...
  <xsl:when test="$screen='whatever'">
    Print some stuff here
    I always get here

It also does this if I do an
<xsp:expr>request.getParameter("screen")</xsp:expr> instead of the
<request:get-parameter>.  But, if I print out the value of $screen using
<xsl:copy-of select="screen"/> it is 'whatever' (or whatever string should
make the test true).

Anways - it's all starting to get a little clearer now (at least I think it
is), thanks for all the help!

- Brent

> -----Original Message-----
> From: Christopher Painter-Wakefield []
> Sent: Friday, August 03, 2001 7:05 AM
> To:
> Subject: Re: [c1] xsp:logic compiling
> Brent,
> is the code you've submitted from a logicsheet?  What does your XML file
> look like?  If you are trying to run your XML through a stylesheet, and
> then through the XSP processor, as it appears you might be doing, then you
> need to rethink your approach.  For more info on logicsheets and how they
> work in 1.8.2, see
> (yes
> it is in the Cocoon 2 docs, but it was really written for Cocoon 1).
> Based on your current code, the main thing I would suggest is putting
> <xsp:content>...</xsp:content> around your <html> nodes.
> -Christopher
> Please respond to
> To:   <>
> cc:
> Subject:  [c1] xsp:logic compiling
> I'm fairly new to Cocoon - but I've been muddling through it now for a few
> days.  But I'm hoping this isn't too big of a newbie question,
> but I didn't
> find any answers in the mailing list archives, the newsgroups, or the web.
> * Cocoon 1.8.2 with Tomcat
> I've created an XSL file which is working fine so far (it's a basic login)
> with it's XML instance document counterpart.  When the user submit a
> login/pw form, it submits back to the same XML file (which in my case is
> index.xml).  Here's a quick snip of the XSL code:
>   <xsl:template match="page">
>     <xsl:processing-instruction
> name="cocoon-process">type="xsp"</xsl:processing-instruction>
>     <xsl:processing-instruction
> name="cocoon-format">type="text/html"</xsl:processing-instruction>
>     <xsp:page language="java"
> xmlns:xsp="">
>     <html>
>     ....
> What I want to do is fairly simple.  Check to see if the form has been
> submitted, by checking for the "login" parameter.  So here is what I
> changed
> the code to:
>   <xsl:template match="page">
>     <xsl:processing-instruction
> name="cocoon-process">type="xsp"</xsl:processing-instruction>
>     <xsl:processing-instruction
> name="cocoon-format">type="text/html"</xsl:processing-instruction>
>     <xsp:page language="java"
> xmlns:xsp="">
>     <xsp:logic>
>     if (request.getParameter("login.x") == null) {
>     <html>
>     .... the rest of the HTML which shows the login form ....
>     </html>
>     } else {
>     ... check username exists, etc
>         response.sendRedirect("main.xml");
>     }
>     </xsp:logic>
> The problem seems to be how Cocoon is generating the java code.  It seems
> as
> though if I put the <xsp:logic> tags before the <html> tag it
> puts the code
> outside of any method in the /* User Class Declarations */ part which is,
> of
> course, not valid Java syntax if I'm doing an "if" statement.
> If I move the <xsp:logic> after the <html> tag my if statement goes into
> the
> populateDocument() method (which is OK - but after an HTML tag has been
> sent
> to the browser I can no longer redirect).
> Can anyone give me a suggestion on how I should handle the redirects??
> Also, how "full-featured" is Cocoon2?  It looks as though C2 has
> some nifty
> logicsheets for request and response objects (of which, by the way, it
> seems
> as though I can use the request logicsheet in C1 and
> <request:get-parameter>
> seems to still work fine... <response> on the other hand does not).  With
> those logic sheets I could just use an <xsl:choose> on the parameter and
> then send the redirect.
> I'm working on a live site for a client though, so stability is an
> important
> issue.
> Anyways, any help would be appreciated, thanks,
> - Brent
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <>
> To unsubscribe, e-mail: <>
> For additional commands, e-mail: <>

Please check that your question has not already been answered in the
FAQ before posting. <>

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

View raw message