What I need to do is execute some Java code that uses both request parameters and XML node values as sources for variables. For example, I want to record someone's submitted username to a special log system, which is based on ID numbers. In this case, the username is supplied in the query, but the ID is stored in the source XML for the application. This is a simplified version of the more complicated things I need to do deeper down. If I have to cram this ID into the request, it defeats the purpose of using XML in the first place -- this XML is essentially a configuration file so users of the system don't need to know things like what ID number the log system needs for this particular "application."
The XML is chosen on the fly based on the URI. The URI may or may not have request parameters and will be a direct request, as in "not generated from another page inside of Cocoon." It may have been sent in an email or it may be hardcoded on another site. http://server/config1/launch or http://server/config1/launch?user=foobar Here's the sitemap I was using: <map:match pattern="*/xsp/launch.xsp"> <map:generate src="{1}.xml" /> <!-- in this example, config1.xml --> <map:transform src="xsp/launch-xsp.xsl" /> <map:serialize /> </map:match> <map:match pattern="*/launch"> <map:generate type="serverpages" src="cocoon:/{1}/xsp/launch.xsp" /> <!-- in this example, config1/xsp/launch.xsp --> <map:transform src="xsp/launch-html.xsl" /> <map:serialize type="html" /> </map:match> This worked great, as the launch-xsp.xsl would generate an XSP from {1}.xml, filling the needed values while stripping out the un-needed nodes for launch-html.xsl. launch.xsp would then not only have the necessary "flattened" XML values in its <xsp:logic> blocks, but also contain the <xsl-request:get-parameter> tags needed to take in the request parameters the FORM would provide. The result was an XSP that was built from XML that could take parameters and be styled appropriately based on the XSP's processing. But I need this to reload when the XML is changed without restarting the server. And from the looks of it it should, but it doesn't. If you made a real request for http://server/config1/xsp/launch.xsp you'd see the change, but the class would never recompile. On Wednesday, March 6, 2002, at 05:22 PM, Benjamin Grant wrote: > > I'm not sure I entirely understand what you are trying to do, > here, but if > all you need to do is provide some XSP-derived data to an XSL > document that > transforms chunks of XML into XHTML, then you were probably on the > right > track by setting up a pipeline -- we do this using an aggregation and a > sub-sitemap. > > Here is some example code that does something similar to what > you've tried; > with this setup, things _do_ recompile on request -- eventually. > We have in > fact noticed that at times it takes several seconds and/or several > requests > for Cocoon to notice that a given XML or XSL doc has changed. On rare > occasions, a document seems to get "stuck" in Tomcat's work > dir/cache, and we > have to toss it out manually. > > Anyway... > > Sample: > > > <map:pipelines> > > <map:pipeline internal-only="true"> > > <map:match pattern="code/*.xsp"> > <map:generate type="serverpages" src="CODE/{1}.xsp"/> > <map:serialize type="xml"/> > </map:match> > > <map:match pattern="content/**.xml"> > <map:generate src="{1}.xml"/> > <map:serialize type="xml"/> > </map:match> > > </map:pipeline> > > > <map:pipeline> > > <map:match pattern="**.html"> > <map:aggregate element="page"> > <map:part src="cocoon:/code/myxspstuff.xsp"/> > <map:part src="cocoon:/content/{1}.xml"/> > </map:aggregate> > > <map:transform src="STYLESHEETS/generic-template.xsl"/> > <map:serialize type="html"/> > </map:match> > > </map:pipeline> > > </map:pipelines> > > You can expand on this idea to gain very granular control over > which XSP is > applied to which URL patterns. In your case I guess those would > be your > frame targets. > > CODE and STYLESHEETS are real directories containing the XSP and XSL, > respectively. "code" and "content" are fake and only used to > address the > internal pipeline and are named distinctly to prevent confusion. > > In this example we're taking requests for .html files, but > actually fetching > .xml files and transforming them. > > To use this setup, reference logicsheets in your XSP to access URL > params, > cookies, etc... > > myxspstuff.xsp: > > <?xml version="1.0" encoding="UTF-8" ?> > > <xsp:page language="java" > xmlns:xsp="http://apache.org/xsp"; > xmlns:xsp-cookie="http://apache.org/xsp/cookie/2.0"; > xmlns:xsp-request="http://apache.org/xsp/request/2.0";> > > <xsp:structure> > <xsp:include>org.apache.cocoon.environment.Cookie</xsp:include> > </xsp:structure> > > <stuff> > > <CookieData> > <xsp-cookie:getCookie as="xml" name="COOKIE_NAME"/> > </CookieData> > > <aVariable> > <xsp-request:get-parameter name="varname" > default="nothing" as="xml"/> > </aVariable> > > </stuff> > > </xsp:page> > > > You can reference that directly with XPATH or you can convert them > into XSL > variables within your XSL stylesheet: > > > <xsl:template match="*"> > > <xsl:variable name="showAds"> > <xsl:choose> > <xsl:when test="contains(//premiumCookieData, > 'ADS=N')">N</xsl:when> > <xsl:otherwise>Y</xsl:otherwise> > </xsl:choose> > </xsl:variable> > > <xsl:variable name="subCategory"> > <xsl:value-of select="//@subCategory"/> > </xsl:variable> > > <xsl:variable name="pn"> > <xsl:value-of select="//pageRequested"/> > </xsl:variable> > > </xsl:template> > > > If in fact you need to invoke logic within the body of a document > to get some > output, rather than prior to its transformation, then using a custom > logicsheet is probably your best bet. And it will keep your > actual logic out > of the content. There's an updated tutorial on adding a logicsheet to > Cocoon in the dev tree now, I think -- the old docs on the site > are/were > geared towards c1. > > > > On Wednesday 06 March 2002 01:08 pm, you wrote: >> Well, that's it. I'm almost ready to scrap Cocoon. >> >> All I want to do is generate a simple HTML page that when requested >> does a little Java code first using some request parameters and >> values from the XML it's being generated from. I need to do this in >> many little ways: sending email, writing to a log, accessing >> services and sending data. >> >> Like: >> >> source.xml: >> <foo id="100"> >> <bar>Hello</bar> >> <foo> >> >> write.xsl?write=test (submitted via form): >> <xsl:param name="test"/> >> <xsl:template match="foo"> >> <html> >> <xsp:logic> >> SpecialLogger logger = new SpecialLogger(<xsl:value-of >> select="@id"/>); >> if (logger.writeThis("<xsl:value-of select="$test"/>")) { >> <body> >> <xsl:value-of select="bar"/> worked! >> <!-- body content version A --> >> </body> >> } else { >> <body> >> <xsl:value-of select="bar"/> didn't work >> <!-- body content version B --> >> </body> >> } >> <xsp:logic> >> </html> >> </xsl:template> >> >> + ~20 other xsl files that spit out frames based on the same XML >> but only require barebones XSLT >> >> This is important because this runs in a framed environment where >> all frames' HTML use the same XML as source, and I don't want to >> have any special code in the XML because there will be many of >> these sources soon, and it only needs to execute this code for this >> *one* transformation. >> >> The only way I have gotten this to work is to create a pipeline >> that turns the XML into an XSP and have the real URL match to a >> cocoon:/ protocol to generate that XML-to-XSP pipeline. While this >> works, it creates a class that WILL NOT RECOMPILE no matter how >> much the referenced XML changes until I restart Cocoon or manually >> delete it, which is unacceptable. >> >> It is absolutely imperative that I be able to accomplish this >> without adding any Java classes--I just won't have the access >> needed to do this. >> >> There MUST be a way! >> >> >> --------------------------------------------------------------------- >> 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]> > > --------------------------------------------------------------------- > 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]> > --------------------------------------------------------------------- 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]>
