Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4264B68F.9040003@nada.kth.se>
Date: Tue, 19 Apr 2005 09:43:11 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Java components in blocks
References: <20050409083134.46541.qmail@minotaur.apache.org>
 <425A7094.8040906@apache.org> <425A8A7A.1030203@nada.kth.se>
 <425A8EAF.7090502@apache.org>
 <255a9c1e1ee0934507a1f5447f3ef066@betaversion.org>
 <425BDF4B.8040705@apache.org>
 <3e1766b0f6774aa2f9b7a26a729043ae@betaversion.org>
 <425D0549.80401@apache.org>
 <9c28f5a45d1ec41b74503c823fa64351@betaversion.org>
 <425D5202.6050001@reverycodes.com>
 <c7fe51acb43d85bc70f9d75149201807@betaversion.org>
 <425E34D8.1070800@nada.kth.se>
 <394529d891516efa895dc2746c77cf58@betaversion.org>
 <425E8B81.3040105@apache.org> <425E8D37.7030106@dslextreme.com>
 <0f996695454c3cc853208a9a66041284@apache.org> <4260FA7A.8030001@apache.org>
 <42610B89.4060208@nada.kth.se>
 <ff2f18d8a42fe961c0daccbc0f090379@betaversion.org>
 <42628446.9000502@dslextreme.com> <42629EB8.4050500@nada.kth.se>
 <42637150.3010200@apache.org> <4263A9A3.3060104@nada.kth.se>
 <4263ADFF.5020806@apache.org> <4263B05B.4020404@nada.kth.se>
 <426496FA.4080509@apache.org>
In-Reply-To: <426496FA.4080509@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>
>> Reinhard Poetz wrote:
>>
>>> Daniel Fagerstrom wrote:
>>>
>>>> Maybe not, but those are areas that are rather vague anyway, we 
>>>> where the only ones who thought it had much importance the last 
>>>> time we discussed it.
>>>
>>> Maybe it had the appearance but I can't believe this. (Recently I 
>>> had a discussion with Sylvain and he really wants this feature too. 
>>> So we are at least three ;-) )
>>
>> Might be, we still need to know the use cases to provide a good 
>> solution. Any comments to what I suggested in my response? BTW I 
>> rather meant:
>> var result = cocoon.sendPageAndWait("block:myblockA://confirmDialog", 
>> {msg: "areYouSure"});
>
>
> A part from that this changes the contract of sendPageAndWait (returns 
> a continuation),

The response object could be made available in an extra argument 
instead. Also we could have VPC flowscript functions as long as their 
return values are restricted to what is part of the "core" classloader.

> I would prefer the explicit call of flowscript functions of other blocks.

Anything else would have been a suprise to me ;)

> I think the usecases are quite clear (reuse a flowscript function of 
> another block and use it the same way as a local function) but we 
> shouldn't discuss this  ATM. Let's wait until Pier and you have set up 
> the base infrastructure (Block[s]Manager + some basic classloader 
> isoluation) and then we will see what is (easily) possible and what not.

Good, it feels rather abstract to discuss whats missing in something we 
haven't implemented or tried.

/Daiel