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="http://apache.org/cocoon/sitemap/1.0";> <map:components src="components.xconf"/>
... </map:sitemap>
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.
Indeed.
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.
Interesting...
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
