cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
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?

sendPageWhateverSuffixThatDoesntWait("foo");
sendPageWhateverSuffixThatDoes("bar");

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

would offer you the same dillema

as would even:
sendPageWhateverSuffixThatDoesntWait("foo");
sendPageWhateverSuffixThatDoesntWait("bar");

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.. ?

Anyone?
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. 

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org                              mpo@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message