Brent,
it sounds like you are getting there, maybe a few hints will close the gap
for you.
First off, you *can* apply multiple logicsheets to an XML document. Use
the <?xml-logicsheet href="..."?> processing instruction multiple times for
logicsheets that aren't associated with a namespace in the
cocoon.properties file, and declare the appropriate namespaces for all
logicsheets. You may also use one logicsheet inside another logicsheet, as
long as you declare the namespace for the secondary logicsheet both in the
using logicsheet and in the XML file (and add the appropriate
<?xml-logicsheet ...?> PI to the XML document if necessary).
The rest of your issues can be dealt with by looking at the sequence of
events when processing your XML. First, the Cocoon processors get applied
in the order in which they are requested via <?cocoon-process type="..."?>
PI's. If you are using XSP, then that processor should *always* be first.
(In Cocoon 1, you can get away with putting an XSP processing step later,
but it can work kind of funny and it is also slow, since you get a
compilation every time the page is requested.)
When the XSP processor is applied, things happen in roughly this sequence:
1. All logicsheets are applied to the source document using normal XSLT.
So for instance, if you use two custom logicsheets using the
<?xml-logicsheet ...?> PI and also use the request logicsheet (and all
three namespaces are declared correctly), then each logicsheet will be
applied to the XML source as an XSL Transform in turn (the output of one
becomes the input of the next and so on). I'm not sure of the exact order
in which the logicsheets will be applied, but common sense would suggest
that the order of <?xml-logicsheet?> PI's and the order of namespace
declarations will be significant.
2. After all logicsheets are applied, the XML is transformed into Java
code (this is also done mostly using XSLT, I believe - look for the
xsp-java.xsl file in your Cocoon src tree).
3. The Java code is compiled.
4. The resulting code is loaded and run to generate the XML page.
The resulting XML from this step is passed on to any other processors down
the line, including your XSLT processor.
This should explain a few things for you. First, you can't really use the
request taglib from inside a stylesheet. Even if the logicsheet were
applied, you'd just end up with uncompiled Java code, which won't do you
any good. All logicsheets have to be used in the XSP step. You can,
however, use the request logicsheet in your XSP program, storing the
results in a tag that you can later process in your stylesheet.
Second, you can't mix Java logic and XSLT logic, which is what you do when
you try to use <xsl:choose> syntax on the result of the
<request:get-parameter>. Keep in mind that the XSLT is just what is
applied to the XML to help transform it into Java code. The
<request:get-parameter> tag gets transformed in that way. If you look at
the actual request.xsl logicsheet (in your src tree), you'll see that the
<request:get-parameter> tag gets transformed into something like
XSPRequestLibrary.getParameter(
request,
String.valueOf("whatever"),
"",
document
);
So, the request code gets run and gives you a result much later in the
process than when your <xsl:choose> is applied. Your <xsl:choose> is not
turned into Java code itself, it is applied as XSLT to generate the Java
code. This is why you can get the results of the request tag in your
output but not use the <xsl:choose> in your logicsheet on the result. One
is dynamic, giving a result at runtime. The other is static, generating
code that will be compiled once and run many times.
Oh yeah, that's the other thing. If you don't change your logicsheets or
source XML, then the next time a request is made to that XML, none of the
logicsheet application and compilation is done - the existing program is
merely re-run.
Anyway, to do what you want, you need to mix apples and apples as it were.
You can either mix Java with Java:
<xsp:logic>
if ("whatever".equals(<request:get-parameter name="screen"/>)) {
<xsp:content>
<b>This screen is 'whatever'!</b>
</xsp:content>
} else {
<xsp:content>
<font color="FF0000">Wrong screen!</font>
</xsp:content>
}
</xsp:logic>
or mix XML with XSLT:
(in your XSP program or logicsheet)
<screen><request:get-parameter name="screen"/></screen>
(in your stylesheet, later in the chain)
<xsl:template match="screen">
<xsl:choose>
<xsl:when test="text() = 'whatever'">
.... and so forth.
Finally, if all that wasn't enough, note that you can gain access to
request parameters in your stylesheet (not your logicsheet!). Coocon does
some sort of trick to make these available. Merely declare XSL parameters
with the same name as your request parameter at the top level of your
stylesheet, like so:
<xsl:param name="screen"/>
See the user guide (http://swift.mc.duke.edu/cocoon_docs/guide.html) for
more on this approach.
I hope some of this is helpful. Good luck!
-Christopher
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: Re: [c1] xsp:logic compiling
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
name="screen"/></xsl:variable>
If I do this, then attempt to do an xsl:choose on it, it never works and
always falls to the otherwise...
<xsl:choose>
<xsl:when test="$screen='whatever'">
Print some stuff here
</xsl:when>
<xsl:otherwise>
I always get here
</xsl:otherwise>
</xsl:choose>
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
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
