cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Man <Martin....@seznam.cz>
Subject [C2] xsp proposal
Date Thu, 22 Feb 2001 14:47:48 GMT
Hi,
	I've got several ideas about XSP to which I came about quite some time
of intensive work with cocoon2...

<xsp:page xmlns:... problem
===========================
The fact that all logisheets' namespaces have to be declared in .xsp file is
pretty annoying I guess, e.g., if my .xsp page uses just <log:xxx, and
<mytaglib:yyy, elements which are then transformed into <esql:zzz, or whatever
else, I want to specify JUST namespaces log and mytagib, 
and after applying mytaglib on
an .xsp source the ProgramGenerator should recognize that my elements were
translated into <esql: and apply this logicsheet then,

to summarize,
ProgramGenerator (or whatever class that is actually doing logicsheet
transformations in order to get .java generator source) should not apply
only logicsheets that were found in the <xsp:page's xmlns: attributes of
source .xsp page but
should figure out which logischeets to apply after every transformation step.

explanation,
developers of xsp should not take care of naming all namespaces that mytaglib
could use, especially in case that they don't name them, everything works but
wrong way of course and I must check logs and figure out what the hell is
going wrong... (not a big deal with my own logicsheet, but can imagine it will
be hell in the future when third party logicsheet will use four other
logischeets (ldap, esql, request, util, ...) to perform an operation.

solution,
maybe add tag such as

<xsp:apply-logicsheet prefix="mytaglib"/>

somewhere in between <xsp:page> </xsp:page>

when another logischeet is being applied, it can add such tags for the
logicsheets it depends on.

or ProgramGenerator should check which namespaces are declared in <xsp:page
element and then apply those logicsheets that were not applied before


xsp without sax output
======================
	the other thing is whether it would be usefull to add an attribute to
<xsp:page, such as 

<xsp:page language="java" output-content="no" (with default yes)

that would prevent an xsp .java code generator from including all code
fragments that actually produce sax events such as 

this.characters(
this.contentHandler.startPrefixMapping(

this.contentHandler.startElement, etc..

this would allow us write pure logic xsp pages using xml and all those nice
logicsheets already available, such pages than could use
<xsp-response:send-redirect, cookies, and other bloody things that have to be
sent out before any actuall content

I know that actions are (or will be) perfect solution for such pure-logic
components, but actions are pure java (for now) and this means again write all
this bloody db connection stuff again and again...

action parameter names
======================
also from what I know about actions from cvs, the sitemap construction
{parameter_name}, where this parameter_name is hardcoded in the action's
source code doesn't make the sitemap very readable (and intuitive) maybe some
way on how to specify the parameter names to set directly from sitemap (I see
that it's almost impossible for actions that are setting more parameters but
anyway) :-))


thanx for reading, and for all the grat work already done...

cocoon fundamentalist,
martin


-- 
-------------------------------------------------------------------------------
"Only dead fish swims with a stream"
gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09  7BCB 6202 7024 6E06 0223

Mime
View raw message