cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Changes made to flow system.js
Date Sun, 08 Dec 2002 00:33:38 GMT
Stefano Mazzocchi wrote:
> Giacomo Pati wrote:
>> On Fri, 6 Dec 2002, Marc Portier wrote:
>>> Christian Haul wrote:
>>>> On 06.Dec.2002 -- 04:07 PM, Marc Portier wrote:
>>>>> Giacomo, Sylvain,
>>>>> I see my remark wasn't that stupid after all (taking as an
>>>>> argument the fact the statistic unlikeliness of having exact
>>>>> equal idiots) Sorry, for not earlier reading deeper down the
>>>>> thread though...
>>>>> only I'm not ready to give in yet...
>>>>> is making a continuation really atomicly linked to sending a
>>>>> page?  Your argumentation makes me see that:
>>>>> Rather then 2 there are 3 concerns covered in the sendPageAnd...
>>>>> I guess it's more like
>>>>> makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest
>>>>> :-)
>>>> The problem is that you need to have something to place on the page
>>>> that links to the continuation id. Thus you need to have your
>>>> continuation before sending the page. Hence suspending and sending is
>>>> one atomic operation.
>>>>     Chris.
>>> Now I see it: when the page is sent the links are available to be
>>> clicked upon and thus the 'state' should be there.
>>> I only considered the creation part ATM (and there I argumented
>>> that for creating the URI-links you don't need to save the state
>>> yet)
>>> Think I got it now, so we are back to the straightforward naming
>>> discussion... thinking back of my highschool-basic-time this
>>> kinda boils down to finding the equivalent of
>>>  0 CLS
>>> 10 PRINT "This is only out:"
>>> 20 INPUT "This prompt asks you to enter something:" , answer
>>> which would make me advocate
>>> for the output only:
>>>   sendPage("name-o-page") or even
>>>   printPage(...) or
>>>   echoPage(...)
>>> for the input kind of page
>>>   getFormInput("name-o-form") or
>>>   getFormReply(...)
>> And thus we are back to my lastly proposed method names:
>>    sendPage( page ) // without waiting
>>    getAnswerFor( page )
>> or
>>    getReplyFor( page )
> Hmmm, what happens if I do
>  sendPage("foo")
>  getAnswerFor("bar")
> ???
> I think that sendPageAndWait() *is* atomic once you get it. Separating 
> the two doesn't sound like SoC anymore if you can mess up like above, it 
> becomes FoC (fragmentation of concerns) which is bad
good argument, but do you only solve this with naming?


sendNextPage(); //sorry, wasn't the last after all?

would offer you the same dillema

as would even:

a discussion we also had earlier in the thread...
and which you pointed out so clearly with the remark that *this 
all* keeps on being a servlet generating a simple response (not a 
screen we can add a line to)

The question Michael posed keeps on being not solved:
> On 06.Dec.2002 -- 11:09 AM, Michael Melhem wrote:
>>> On Thu, Dec 05, 2002 at 10:45:38PM -0800, Ovidiu Predescu wrote:
>>>> > "Finish" what? The problem with that is that you could still do things

>>>> > after the page was sent back to the client. Advanced users might want

>>>> > to use this fact to do all sorts of nasty things.
>>> Interesting, didnt think of that. So does this mean you can send
>>> multiple pages back to the client without client intereaction.. ?

For me, as for Miles Elam:
> I don't mean to butt in when I haven't contributed to flow, but as I will be a user of
this API, obscure function semantics aren't going to make my life easier when I teach others
how to use it. 

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center                    

To unsubscribe, e-mail:
For additional commands, email:

View raw message