Glen Ezkovich wrote:
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!
I think of composing an application out of flow calls:
function myF() {
var newAccount = [here call a flow function of another block]
e.g. cocoon.blocks.blockB.createNewAccount();
if(newAccount.type == "xyz") {
cocoon.sendPage("xyz");
}
else {
cocoon.sendPage("abc");
}
}
So calling another block has to return a Java(script) object (a stream of
SAX
events doesn't help here!) and I don't want to care which flowscript files have
to be loaded to make my call work.
If we go this way we have to solve the problem that the flowscript of the other
block runs completly isoluated from the calling the block. This has the
advantage that we don't have to work around the missing namespace concept of
Javascript but has the disadvantage that we have to find a way that in the other
block (runs isolated from the first block) continuations are created and that we
have to return the result of this function to the calling block.
I fear that this isn't possible ...
If I'm right that we can't find a way to make this "isolated flowscript call"
work, we can still think of including other blocks flowscripts the usual way in
the <map:flow>-sections. But it looks more like a hack.
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.
see above
--
Reinhard
