cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <g...@hard-bop.com>
Subject Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Mon, 10 Jan 2005 05:09:17 GMT

On Jan 9, 2005, at 7:33 PM, Mark Lundquist wrote:

>
>> From: Glen Ezkovich [mailto:glen@hard-bop.com]
>> On Jan 9, 2005, at 4:17 PM, Mark Lundquist wrote:
>>> Do we really want inter-block flowscript function calls?
>
> Actually, I guess we do... there are some blocks that are meant to be 
> used
> from flow, for which passing requests and SAX streams isn't the best 
> model.
> Think of an authentication module, for instance.  Or, to use your 
> example,
> Forms!

Of course. But you want to use a service not invoke a javascript 
function. What you would want is to get the service, make a request and 
get the result. Not knowing what the intricacies of the block system 
will be, I would imagine something along the lines of
	
	var authService = 
cocoon.get("block://authentication/authenticationService");
	var isAuthorized = authService.authorize(user, pwd);

would make more sense. Or more likely this still might be done by the 
current service lookup methods but the service will be provided by the 
authentication block. (Though I do like the simplicity of the above.) 
If you implemented you app's authentication in javascript and deployed 
it as a block you could just use it from flow like

	cocoon.sendPageAndWait("block://authentication/authenticate", 
"block://currentBlock/loginPage");

Where all you are essentially doing is redirecting to the 
authentication blocks sitemap. It really just depends on what exactly 
it is you want the block to do.

The way I understand it, one of the main points of blocks is to make it 
easier to configure Cocoon with just the components you need for your 
application. Once the various components are wired together we 
shouldn't really need to do anything differently. If a block has a 
dependency on another block it should be able to use the existing 
methods to realize that dependency. All of the magic should be done by 
Cocoon and the Block Manager.

> So, I withdraw my question... but I guess I would like to see what 
> block
> contracts would look like at the flow level!

Can you explain what a contract between blocks is? I'm lost here. I 
thought a contract was between the client and the 
method/function/pipeline it invokes. The client agrees to meet certain 
requirements of the method/function/pipeline before invoking it and the 
method/function/pipeline then agrees to perform certain tasks and/or 
return correct and valid results.

> Perhaps a flowscript object
> that encapsulates the flowscript API for the block?
> Actually, a Java interface could express that...

Seems like overkill.

>
> ~ml
>
>
>
>

Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com



A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow


Mime
View raw message