On Jan 9, 2005, at 7:33 PM, Mark Lundquist wrote:
From: Glen Ezkovich [mailto:[EMAIL PROTECTED] 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
