Hi,
I read all this email but it leaves me with feeling that you have not got yet how XSP are working... Here goes my attempt at explaining how they work:
ServerPagesGenerator is responsible for: (1) Loading Generator created out of ServerPage (2) Invoking Generator created out of ServerPage
Step (1) includes:
* Choosing markup laguage (usually: XSP)
* Choosing programming language (Java, Javascript, Python)
* Resolving serverpages Source
* Invoking ProgramGenerator to create Generator out of Source in given markup, programming language pair (3)
Step (2) is just one-liner, invoke generate() method on obtained generator, plus some exception handling, etc.
Now, as you can see, actual creation of the Generator happens outside of the ServerPagesGenerator, and done by ProgramGenerator. ProgramGenerator's responsibilities include:
* Selecting a Generator instance, if it is loaded already
* Loading a Generator instance, if it is compiled already
* Generate a source code (and compile it) out of the server page.
Usually, last step happens only on first access to the server page. Second step (usually) happens on first access to the server page after server restart. First step happens on each access to the serverpage.
Now, as you can see, programming language source code is generated out of XSP source code only once, on first access to the server page (also, it is done each time XSP source is modified). On all other accesses to the server page, already loaded Generator instance is used, and no compilation take place. If you think about it, that's the ONLY possible way to implement server pages, otherwise the only thing server will be doing is invoking compiler.
When source code is generated out of server page in markup language, it is possible to insert arbitrary XSLT transformations on this code. Such XSLT transformations are called Logicsheets, and they are replacing tags in the logicsheet's namespace with the logic in programming language. Thus, for example,
<xsp-request:get-parameter name="test"/>
becomes:
request.getParameter("test")
after XSP source is passed through the XSP Request Logicsheet.
Now, suppose that you found a way to use SessionTransformer. And suppose that you had asked it to get some information from the current user's session. This means, that whatever information is extracted by the SessionTransformer, will go into the server page's source code in the programming language of choice. And this information will be "baked into" the code of the resulting Generator. Next, what will happen when another user accesses this same server page? There are two options:
(a) Another user will get data of the first user.
(b) You will have to make server pages generator to discard compiled instance of the server page and compile it again.
I think (a) is not what you want. And also (b) is possible, it would NEVER scale beside a cute little demo (see http://localhost:8888/samples/sources/all-dynamic demo). And that's where Logicsheets are coming in. What you need is a logicsheet, which will inject logic into the programming code of the server page, which will invoke necessary Java code to obtain information from the session - see example above about xsp-request.
And last comment about server pages technology in Cocoon. It is mature, and no deep changes are planned for it. Cocoon community concentrating on other, more promising (but - sometimes - unstable yet) technologies, and no significant time will be spent on development of server pages technology. Core of the server pages technology is very solid, but some of the logicsheets are still in need of polishing. Now, you can either join and work on developing newer technologies, such as jxtemplates, or, if you are not in position to do this, your contributions (bugfixes) to existing XSP logicsheets are more than welcome.
Thanks, Vadim
