You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2004/11/09 13:55:02 UTC

Problem in session-fw / RequestContext

Hi,

We just came across a very annoying problem in session-fw: the 
RequestContext class creates a DOM which represents the full contents of 
a request, translating all request attributes to XML elements having names.

Now when the session transformer is called by a flowscript, there's a 
request attribute whose name is "FOM JavaScript GLOBAL 
SCOPE/file://my/path/to/flow/script.js" which is obviously an invalid 
name for an XML element and leads to a nice DOMException :-(

I added a quick'n dirty workaround (just catch the exception) as we need 
it to work and have a tight schedule, but there are IMO two problems there:
- we cannot assume request nor session attributes names are valid XML 
element names,
- building a complete DOM representing the full request (headers, 
cookies, parameters, attributes, etc, etc) seems really overkill when 
most uses will just extract a single data. It makes me think to the old 
days of Cocoon 1. Using some lazy instanciation techniques would really 
speedup the thing and lower memory consumption.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


RE: Problem in session-fw / RequestContext

Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote: 
> 
> Hi,
> 
> We just came across a very annoying problem in session-fw: 
> the RequestContext class creates a DOM which represents the 
> full contents of a request, translating all request 
> attributes to XML elements having names.
> 
> Now when the session transformer is called by a flowscript, 
> there's a request attribute whose name is "FOM JavaScript 
> GLOBAL SCOPE/file://my/path/to/flow/script.js" which is 
> obviously an invalid name for an XML element and leads to a 
> nice DOMException :-(
> 
> I added a quick'n dirty workaround (just catch the exception) 
> as we need it to work and have a tight schedule, but there 
> are IMO two problems there:
> - we cannot assume request nor session attributes names are 
> valid XML element names,
> - building a complete DOM representing the full request 
> (headers, cookies, parameters, attributes, etc, etc) seems 
> really overkill when most uses will just extract a single 
> data. It makes me think to the old days of Cocoon 1. Using 
> some lazy instanciation techniques would really speedup the 
> thing and lower memory consumption.
> 
Yepp, definitly - I never found a good way of doing it, so if
you or someone else is able to provide a good implementation,
let's change it.

Carsten