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