cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <>
Subject Re: [RT] Improving Sitemap and Flowscript
Date Tue, 19 Aug 2003 20:35:31 GMT
Stefano Mazzocchi wrote:

> I propose the creation of "virtual pipeline components" by aggregating 
> two or more components into a virtual one.

Love it.  Love it.  Love it!

>   Moving Sitemap components into cocoon.xconf
>  -------------------------------------------
> the default sitemap is too verbose and this scares people away. I 
> would like to move the default sitemap component definitions into the 
> cocoon.xconf.
> Note that with blocks, the definitions of those components will be in 
> the block.xconf as well and this will be aggregated by the block manager.

Except for the fact that cocoon.xconf is too verbose and this scares 
people away.  While for the most part the contents of cocoon.xconf have 
no direct impact on the sitemap, the components are intimately tied.  
What is the problem with specifying a new file like "components.xconf" 
or specifying it in the sitemap?  For example

<map:sitemap xmlns:map="">
  <map:components src="components.xconf"/>


Doesn't RelaxNG allow differing element content depending on attribute 
value?  (I think so.)  This would allow validation for this example and 
putting component definitions in the map:components element as it is today.

In other words, if the components are in the sitemap.xmap file, nothing 
changes;  But in the cases where having the components in a separate 
file make sense, it is clear where these definitions are located.  (An 
often overlooked issue.)

Imagine this:  A new user fires up Cocoon and wonders where the sitemap 
components are defined or, more likely, wonders what sitemap components 
are available.  Off goes a question to the mailing list.  (People don't 
read docs, remember?  ;-)  An option here would be to add a comment here 
to the effect of "Sitemap component definitions are in 
WEB-INF/cocoon.xconf."  So the newbie goes to cocoon.xconf and is 
confronted with not just the sitemap component definitions, but all of 
the components in use by the system and their configurations, roles, 
etc.  The complexity and intimidation is still there, just shifted off 
to another file.

- or -

A new user fires up Cocoon and wonders where the components are defined 
or, more likely, wonders what components are available.  At the top of 
the sitemap in the map:components element is a reference to the file 
that contains the definitions (and only the definitions).

Am I completely off-base here?

>   Pluggable Request Factories
>  ---------------------------
> Cocoon needs a simple way to deal with complex HTTP usages, such as 
> binary uploading, XML-RPC, WebDAV or SOAP.


> After a lot of discussion with Sylvain and input from many other 
> people, I propose the introduction of a new sitemap element named 
> "map:adaptRequest" that works by adapting the Request object into a 
> more specific object that will parse the request and provide API-level 
> access to the request.

Very nice!

>   Interception in Flowscript
>  ----------------------------
> While writing flowscripts, you realize how many things can be applied 
> to many of the various flowscript functions that are called by the 
> sitemap. In Linotype, I ended up using the ability that javascript 
> gives you of using functions as native objects and then invoquing them 
> by passing a modified argument vector.
> It came to me that what I did with linotype was a really-poor-man 
> interception mechanism. Interception is the ability to "intercept" a 
> method call and execute some code before or after the execution of the 
> intercepted method.


>  1) the addition of a function call to the "cocoon" object, which 
> indicates that intercepting function calls should be imported.
>  cocoon.apply("blah.js");
> where "blah.js" contains the intercepting functions.
>  2) the addition of a function call to context that continues the 
> intercepted invocation:
>   ...
>   continueExecution(arguments);
>   ...
>  3) the introduction of wildcars for function names.
>  function get*() {
>    ...
>  }

<snip-great-authorization-example />

Is only one interception possible?  Authentication is one use case for 
an interception.  Authorization could be another.  I'm sure there are 
others.  Would multiple calls to cocoon.apply(...) be possible?  Would 
they be order dependent?

Also, am I correct in the assumption that the wildcard is intended to 
match target functions?  Doesn't that tie the two files too closely 
together?  Or is this a change to the sitemap calling syntax.  Does the 
sitemap call getwhatever(...), a get* function intercepter catches it 
and then eventually passes the call down to whatever(...)?

- Miles Elam

View raw message