Hi Flavio: sorry, I tought you was not using xsp. Please check:
http://wiki.cocoondev.org/Wiki.jsp?page=XspSessionFw Best Regards, Antonio Gallardo Flavio Palumbo dijo: > 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: [EMAIL PROTECTED] >>Date: Tue, 03 Feb 2004 00:38:16 +0100 >>From: Joerg Heinicke <[EMAIL PROTECTED]> >>To: [EMAIL PROTECTED] >>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: [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]
