Glen Ezkovich wrote:
On Jan 10, 2005, at 3:50 AM, Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
<snip/>
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 it seems, flow replaces components? If createNewAccount() gathers
sends pages, collects information, creates an Account, etc. then why not
just use cocoon.sendPageAndWait?
because this is done in the called block, not by the callee.
So calling another block has to return a Java(script) object (a
stream of SAX
events doesn't help here!)
Of course. Thats why you should be using be invoking a method on a Java
object. If you do not know how to use a Java object from flow you
shouldn't be writing flowscripts. Once you have written a flowscript in
your Account block you should be able to use that flow script from any
block directly. Its just a script.
and I don't want to care which flowscript files have
to be loaded to make my call work.
Then load(block://account/flowscript.js); or something similar.
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.
I think that is the way to go.
The important thing IMO is that when we use a flowscript today, it has
access to a global context in terms of the cocoon object. When we
introduce blocks each block must have a own cocoon object.
hmm...
This block local cocoon object has access to global stuff as before
but also to such things that are internal to the block. Also all
relative URIs must be resolved by relative the block rather than
relative the user. There might be internal pipelines that the block
resolver has access to but that not are exported.
Thats why a block manager is needed, not individual local cocoon objects.
This means that we cannot consider the exported flow calls as normal
java script functions anymore, they are more like methods that are
invoked at a certain object. And the syntax:
I still don't see this. Then you should be creating objects and invoking
methods on them.
cocoon.blocks.blockB.createNewAccount();
illustrates that interpretation in a nice way.
This just seems like a very complex way to implement the invocation of a
function in flow.
A question here is what flowscript functions that should be exported
from a block. I would prefer to explictly enumerate the functions and
possibly whole scripts that are exported rather than exporting
everything in the map:flow sections.
I guess this makes sense but if you use java flow you have method access
modifiers to handle this.
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 ...
Can you expand on why you fear that it is impossible. Concerning web
continuations I would assume that the normal case is that they are
local to the block that creates them and handled by rules in the
blocks sitemap, and that links are handled with the block link
rewriting mechanism. Then it is the block writers choice to put the
continuation handling sitemap rule in the external or the internal
pipeline.
Seems like you want a round peg in a square hole. Just invoke the
function by loading its file and this problem goes away.
If Javascript supported namespaces, I would agree with you.
--
Reinhard
