On Jan 15, 2005, at 12:57 PM, Stefano Mazzocchi wrote:
Glen Ezkovich wrote:
On Jan 14, 2005, at 2:38 PM, Stefano Mazzocchi wrote:
Good luck! :-)
And in case you emerge back from the sea of email alive and you feel
like writing a summary, I'm sure a lot of people will love you for
that eheh :-)
O
Glen Ezkovich wrote:
On Jan 14, 2005, at 2:38 PM, Stefano Mazzocchi wrote:
Good luck! :-)
And in case you emerge back from the sea of email alive and you feel
like writing a summary, I'm sure a lot of people will love you for
that eheh :-)
Or hate me ;-)
for some philosophers there is no differe
On Jan 14, 2005, at 2:38 PM, Stefano Mazzocchi wrote:
Good luck! :-)
And in case you emerge back from the sea of email alive and you feel
like writing a summary, I'm sure a lot of people will love you for
that eheh :-)
Or hate me ;-)
--
Stefano.
Glen Ezkovich
HardBop Consulting
glen at hard-bo
Glen Ezkovich wrote:
On Jan 13, 2005, at 6:53 PM, Stefano Mazzocchi wrote:
Glen Ezkovich wrote:
By the way, I'm curious what you think about making a block's
resources available. There are two conflicting wiki pages.
there is this
A block exposes a sitemap and Avalon Components (both optiona
On Jan 13, 2005, at 6:53 PM, Stefano Mazzocchi wrote:
Glen Ezkovich wrote:
By the way, I'm curious what you think about making a block's
resources available. There are two conflicting wiki pages.
there is this
A block exposes a sitemap and Avalon Components (both
optionally)
from http://wiki
Glen Ezkovich wrote:
By the way, I'm curious what you think about making a block's resources
available. There are two conflicting wiki pages.
there is this
A block exposes a sitemap and Avalon Components (both optionally)
from http://wiki.apache.org/cocoon/GT2003RealBlocks
and this
A blo
On Jan 12, 2005, at 4:53 PM, Stefano Mazzocchi wrote:
Glen Ezkovich wrote:
After rereading much of this discussion and the various wiki pages
concerning blocks I withdraw almost everything I said. Its now
obvious to me that the way to achieve everything we are talking about
is to allow for multi
Glen Ezkovich wrote:
After rereading much of this discussion and the various wiki pages
concerning blocks I withdraw almost everything I said. Its now obvious
to me that the way to achieve everything we are talking about is to
allow for multiple inheritance. I am not recommending this since I ha
After rereading much of this discussion and the various wiki pages
concerning blocks I withdraw almost everything I said. Its now obvious
to me that the way to achieve everything we are talking about is to
allow for multiple inheritance. I am not recommending this since I have
not thought deepl
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Answer: It depends on the order of declaring your scripts in
. The first helper() method declared will be found.
But there is only one helper() method per block!?
Yes. Therefore we need something more sohpisticated than imports.
I'm having a hard
I really hate to say anything about this but ...
On Jan 11, 2005, at 8:57 AM, Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Answer: It depends on the order of declaring your scripts in
. The first helper() method declared will be found.
But there is only one helper() method per block!?
Yes. Ther
Reinhard Poetz wrote:
Answer: It depends on the order of declaring your scripts in
. The first helper() method declared will be found.
But there is only one helper() method per block!?
Yes. Therefore we need something more sohpisticated than imports.
I'm having a hard time following this convers
On Jan 11, 2005, at 3:57 AM, Torsten Curdt wrote:
k ...then I did understand correctly.
the "callFunction" proposal got me
a bit off the track ;)
I seem to be good at that. Since it was not something that I seriously
support, I will refrain from explaining. ;P
Glen Ezkovich
HardBop Consulting
gle
ok ...what version of javascript does
rhino implement? I could not find that
information...
http://www.mozilla.org/rhino/overview.html
(in trunk we use Rhino 1.6pre1)
bummer ...must have missed that one
ok ...so 1.5 it is
cheers
--
Torsten
Torsten Curdt wrote:
that's the goal. But with imports in you will get into
trouble:
In this case print(blockBFunc()); will return "A".
k ...then I did understand correctly.
the "callFunction" proposal got me
a bit off the track ;)
But there is only one helper() method per block!?
that's the goal. But with imports in you will get into
trouble:
In this case print(blockBFunc()); will return "A".
k ...then I did understand correctly.
the "callFunction" proposal got me
a bit off the track ;)
But there is only one helper() method per block!?
Yes. Therefore we need
Torsten Curdt wrote:
Problem:
flow.js of blockA
--
function blockAFunc() {
return helper();
}
function helper() {
return "A";
}
flow.js of blockB
-
function blockBFunc() {
return helper();
}
function helper() {
return "B";
}
flow.js of blockC
---
Problem:
flow.js of blockA
--
function blockAFunc() {
return helper();
}
function helper() {
return "A";
}
flow.js of blockB
-
function blockBFunc() {
return helper();
}
function helper() {
return "B";
}
flow.js of blockC
-
function blockCFun
On Jan 10, 2005, at 10:35 AM, Daniel Fagerstrom wrote:
Glen Ezkovich wrote:
I've been thinking about why one would want to isolate a blocks
flowscripts from other blocks. So far I see two reasons:
1.) some flowscript functions are simply helper functions and
should not be directly callled.
Glen Ezkovich wrote:
I've been thinking about why one would want to isolate a blocks
flowscripts from other blocks. So far I see two reasons:
1.) some flowscript functions are simply helper functions and
should not be directly callled.
2.) a block may use its own classloader and therefore
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
A somewhat unrelated thing that we have to think about is the web
continuations created in the block, do we need to shield the web
continuations created in the block or not?
shielded from what? The
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
A somewhat unrelated thing that we have to think about is the web
continuations created in the block, do we need to shield the web
continuations created in the block or not?
shielded from what? The user should be able to r
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
A somewhat unrelated thing that we have to think about is the web
continuations created in the block, do we need to shield the web
continuations created in the block or not?
shielded from what? The user should be able to resume a continuation
cre
On Jan 10, 2005, at 9:32 AM, Reinhard Poetz wrote:
Torsten Curdt wrote:
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
Glen Ezkovich wrote:
On Jan 10, 2005, at 9:07 AM, Torsten Curdt wrote:
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 t
Torsten Curdt wrote:
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.
Yes, and when sendPageAndWait returns
On Jan 10, 2005, at 9:07 AM, Torsten Curdt wrote:
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.
Yes, and w
I've been thinking about why one would want to isolate a blocks
flowscripts from other blocks. So far I see two reasons:
1.) some flowscript functions are simply helper functions and should
not be directly callled.
2.) a block may use its own classloader and therefore possibly use
different ve
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.
Yes, and when sendPageAndWait returns the calling blocks fl
On Jan 10, 2005, at 7:24 AM, Reinhard Poetz wrote:
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.
Yes, and w
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
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 ma
Glen Ezkovich wrote:
On Jan 10, 2005, at 3:50 AM, Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
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(
On Jan 10, 2005, at 3:50 AM, Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
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.t
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
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.
Maybe we
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
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.s
Reinhard Poetz wrote:
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");
}
e
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
us
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 whic
38 matches
Mail list logo
