Re: passing sitemap parameters to XSP?

[Olivier Billard]

You must surroud your Java code with <xsp:logic>. Without it, it is considered to be 
output.
HTH,
--
Olivier
Lars Huttar wrote:
OK, I'm still struggling... I'm not used to putting raw
Java code in an XSP page.
I tried:
<xsp:page language="java" xmlns:xsp="http://apache.org/xsp";
xmlns:xsp-request="http://apache.org/xsp/request/2.0"; 
xmlns:esql="http://apache.org/cocoon/SQL/v2";>
  String id = parameters.getParameter("id", "-1");
        <language-entry>
                <class>Language in Country</class>
                <id>
                        <xsp:expr>id</xsp:expr>
                </id>
        </language-entry>
</xsp:page>
and got the error:
org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Error compiling 
language_entry_xsp: ERROR
1 (org\apache\cocoon\www\cvsmount\ethnologue\sources\language_entry_xsp.java): ...
this.characters("\n\t\t\t"); // start error (lines 325-325) "id cannot be resolved"
XSPObjectHelper.xspExpr(contentHandler, id); // end error this.characters("\n\t\t"); 
... Line 325,
column 0: id cannot be resolved
Line 325 says
         XSPObjectHelper.xspExpr(contentHandler, id);
I noticed that in language_entry_xsp.java, the
  String id = parameters.getParameter("id", "-1");
code was nowhere to be found.
Then I tried it with <xsp:logic> around that code:
<xsp:page language="java" xmlns:xsp="http://apache.org/xsp";
xmlns:xsp-request="http://apache.org/xsp/request/2.0"; 
xmlns:esql="http://apache.org/cocoon/SQL/v2";>
  <xsp:logic>String id = parameters.getParameter("id", "-1");</xsp:logic>
        <language-entry>
                <class>Language in Country</class>
                <id>
                        <xsp:expr>id</xsp:expr>
                </id>
        </language-entry>
</xsp:page>
but this gave the error:
Original Exception: java.lang.NullPointerException
        at
org.apache.cocoon.www.cvsmount.ethnologue.sources.language_entry_xsp.<init>(org.apache.cocoon.www.c
vsmount.ethnologue.sources.language_entry_xsp:239)
where line 239 is:
  String id = parameters.getParameter("id", "-1");
No doubt I'm doing something wrong but don't know what else to
try.
Thanks again,
Lars

-----Original Message-----
From: Jan Hoskens [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 11, 2004 7:20 AM
To: [EMAIL PROTECTED]
Subject: Re: passing sitemap parameters to XSP?

<xsp:page>
String id = parameters.getParameter("id", "defaultvalue");
</xsp:page>
Kind Regards,
Jan
Lars Huttar wrote:

Dear Cocoonists,
I'm trying to pass sitemap parameters to an XSP page:
    <map:match pattern="data/language-entry/*">
      <map:generate src="sources/language-entry.xsp"
type="serverpages">
        <map:parameter name="id" value="{1}" />
      </map:generate>
      <map:serialize type="xml" />
    </map:match>
But in the xsp page, where I use <xsp-request:get-parameter
name="id"/>,
the result is nothing (empty string).
This makes sense, since the parameter I'm looking for is
not a request parameter, so xsp-request shouldn't find it.
But then, how DO I pick up sitemap parameters?
(If I am using the term "sitemap parameter" right?)
It is documented in various places, including the xsp.xsl
logicsheet, that "parameters - parameters defined in the sitemap"
is one of the "Built-in parameters available for use" in XSP. But
nowhere can I find how to access it/them.
Any help is appreciated!
You are probably wondering why I don't use a request parameter,
e.g.
    <map:match pattern="data/language-entry/*">
      <map:generate src="sources/language-entry.xsp"
type="serverpages">
        <map:parameter name="id" value="{1}" />
      </map:generate>
      <map:serialize type="xml" />
    </map:match>
instead of a sitemap parameter.
That is an option.
I've been avoiding it because it would mean that when it
comes to using that parameter as part of a filename, for reading
or writing, I would have to take extra steps to make sure
someone doesn't try to sneak in values like "foo/../../etc"
and try to get access to files they shouldn't.
Thanks,
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]