cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Flavio Palumbo" <flavio.palu...@fastwebnet.it>
Subject Re: problem with getxml
Date Tue, 03 Feb 2004 08:42:34 GMT
Hi Joerg,

thank you for the hint ;-)

I have already looked at the java code but i am too "young" in cocoon stuff
to completely understand what's wrong in the original session:getxml.

I wrote the code i send, looking at some mails by Antonio Gallardo of August
2003.

If i have understood correctly, it is a known problem due at the absence
of getxml in xsp-session namespace.

Anyway i hope this mail could help somebody else.

Thanks a lot

Flavio
>-- Original Message --
>Reply-To: users@cocoon.apache.org
>Date: Tue, 03 Feb 2004 00:38:16 +0100
>From: Joerg Heinicke <joerg.heinicke@gmx.de>
>To:  users@cocoon.apache.org
>Subject: Re: problem with getxml
>
>
>On 02.02.2004 22:24, Flavio Palumbo wrote:

> Hi Joerg,
> 
> i found this strange behaviour : 
> 
> the content of the fragment at /authentication/data/socOM in the context
> authentication contains the code "8801", and i can see this value if i
>show
> on screen with first snippet.
> 
> I thought that i could evaluate a variable in the same manner (second
snippet)
> ; but this doesn't happen.
> 
> Anyway, looking at the mail archive, i found some interesting examples
and
> i wrote a lit
>le function that seems to work ; here is the code :
> 
>       private synchronized String getParAut(String inContext, String inPath)
> {
> 
>          String sRet = null;
>          org.apache.avalon.framework.component.ComponentManager cm = thi
>.manager;
>          org.apache.cocoon.webapps.session.SessionManager sm = null;
> 
>          //System.out.println("getParAut - cerco **"+inPath+"** in **"+inContext+"**");
>          try {
>              sm = (org.apache.cocoon.webapps.session.S
>ssionManager)cm.lookup(org.apache.cocoon.webapps.session.SessionManager.ROLE);
>              org.w3c.dom.DocumentFragment df = sm.getContextFragment(inContext,
> inPath);
>              StringBuffer sb = new StringBuffer();
>              for (int
>i=0; i< df.getChildNodes().getLength(); i++) {
>                   sb.append(df.getChildNodes().item(i).getNodeValue());
>                   sRet = sb.toString();
>              }
>              if (sm != null) {
>                  cm.release((
>omponent)sm);
>              }
>          } catch (Throwable e) {
>                  System.out.println("getParAut - Errore "+e);
>          }
> 	 finally {
> 		cm.release((Component)sm);
> 	 }
>          return sRet;
>       }
> 
>         
>  <xsp:logic>String sSoc = getParAut("authentication", "/authentication/data/socOM");</xsp:logic>
>            <outEasy sizeFont="3" label="Codice Societa':" alignLabel="left"
> widthLabel="100" 
>                      alignCampo="left" widthCampo="
>00" name="codiceSoc"
> size="5">
>                      <xsp:attribute name="value"><xsp:expr>sSoc</xsp:expr></xsp:attribute>
> 
> Please let me know what you think about.

As I said I don't know about the internals, only about possible error 
c
>uses. Now that it works I think it's ok. It would just be interesting 
to have your solution compared with the session:getxml solution.

I don't know if you know it but the XSP stuff is transformed via XSLT 
into Java code. Somewhere the resulting 
>ava code must be lying around 
(e.g. TOMCAT_HOME/work/**). You can compare them if you want to see 
what's wrong with the standardized solution provided by session:getxml.

Joerg

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





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


Mime
View raw message