[C2] xsp proposal

[Martin Man <Ma...@seznam.cz>]

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

Re: [C2] xsp proposal

[Giacomo Pati <gi...@apache.org>]

Martin Man wrote:
> On Mon, Feb 26, 2001 at 09:38:20PM +0100, Giacomo Pati wrote:
> > Martin Man wrote:
> >
> > <snip/>
> >
> > > 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) :-))
> >
> > I haven't got the point you are telling us. Could you explain it with
> > some examples?
>
> first I'm sorry for my english :-))
>
> I wanted to tell that (as I understand the concept of actions) the
> parameters an action is propagating to the sitemap are hardcoded in a
> action's source code... and therefore it seems to me not very comprehensive
> from where the parameter is coming to the sitemap (e.g, from which action
> exactly)
>
> for example, if there is
>
> <map:match patern="xxx/*">
>
> I know that {1} matches the star in pattern attribute, but if there is
>
> <map:act type="lang_select">
>
> then parameter {lang} is being set by this action, o.k. ??
>
> what I propose is the possibility to declare the "lang" name also from the
> sitemap, not like now when it's hardcoded in a java sourcecode,
>
> <map:act type="lang_select" set="xxx">
>
> so that I can use xxx defined by me as a sitemap developer..
>
> maybe even beter to declare these parameter names in
> <map:action name=".." src="...">
>   <propagate-parameter name="lang" as="my_language"/>
> </map:action>

You can do it this way:

  <map:act type="whatever" src="younameit">
    <parameter name="propagate-lang-name" value="lang"/>
    ...
  </map:act>

and have your action lookup the parameter named "propagate-lang-name" to know 
the name wanted by the sitemap admin.

Giacomo

Re: [C2] xsp proposal

[Martin Man <Ma...@seznam.cz>]

On Mon, Feb 26, 2001 at 09:38:20PM +0100, Giacomo Pati wrote:
> Martin Man wrote:
> 
> <snip/>
> 
> > 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) :-))
> 
> I haven't got the point you are telling us. Could you explain it with some 
> examples?
first I'm sorry for my english :-))

I wanted to tell that (as I understand the concept of actions) the parameters
an action is propagating to the sitemap are hardcoded in a action's source
code... and therefore it seems to me not very comprehensive from where the
parameter is coming to the sitemap (e.g, from which action exactly)

for example, if there is

<map:match patern="xxx/*">

I know that {1} matches the star in pattern attribute, but if there is

<map:act type="lang_select">

then parameter {lang} is being set by this action, o.k. ??

what I propose is the possibility to declare the "lang" name also from the
sitemap, not like now when it's hardcoded in a java sourcecode,

<map:act type="lang_select" set="xxx">

so that I can use xxx defined by me as a sitemap developer..

maybe even beter to declare these parameter names in 
<map:action name=".." src="...">
  <propagate-parameter name="lang" as="my_language"/>
</map:action>

than I would be able to rename parameter names without affecting source code

first point I can see is name conflict, what if I will write an action that
would propagate parameter with the same name as any other action provided by
third party person ???


hope it's clear now :-)))

> 
> Giacomo
> 

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

Re: [C2] xsp proposal

[Giacomo Pati <gi...@apache.org>]

Martin Man wrote:

<snip/>

> 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) :-))

I haven't got the point you are telling us. Could you explain it with some 
examples?

Giacomo