Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3DF09AA4.1030104@outerthought.org>
Date: Fri, 06 Dec 2002 13:40:04 +0100
From: Marc Portier <mpo@outerthought.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Changes made to flow system.js
References: <20021205101316.GA27326@fztig938.bank.dresdner.net>
 <5462E91E-08E6-11D7-941D-00039398D61E@apache.org>
 <20021206100908.GA24270@fztig938.bank.dresdner.net>
 <20021206105546.GD1153@bremen.dvs1.informatik.tu-darmstadt.de>
In-Reply-To: <20021206105546.GD1153@bremen.dvs1.informatik.tu-darmstadt.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

disclaimer:
this is at the danger of making a complete fool of myself
have only been following this discussion from a distance

so here is the fool's thought:
1. Given the fact that: you could still do things according to:

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

2. My experience with method-names containing "and" is that they 
point out some bad SoC... typically if you have multiple ones it 
actually shows the semantics are to be split up into two methods:

So from a clueless end-user-point of view (just seeking semantics 
per se) I guess

	sendPage(); //doing just that, leaving plenty of room to do 
other stuff (while the client gets an answer back already?)

either or not followed by

	continue();
	wait();
	saveState();
	prepareForContinuation();
	noneOfTheAbove();

would make the most common sense... but maybe is changing a bit 
the use cases/current approach?


>>
>>Interesting, didnt think of that. So does this mean you can send
>>multiple pages back to the client without client intereaction.. ?
> 
> 
> Don't think so (because the browser is not listening). But you could
> write a document locally (to a file) or if we had an EmailSerializer
> one could send an email or ... like
> 
>    ....
>    sendPageAndContinue("Confimation.email");
>    sendPageAndBlock("Confirmation.xml"); // or whatever name it is currently
>    ....
> 
> 	Chris.

multiple sendPage()'s after each other should then result in some 
exception since the first one would of have done something like 
'closed' the Httpresponse's printStream (or at least sent out the 
HTTP response header, I think the servlet API has a method for 
checking this)


as for sending email: I think it makes sense to call that 
sendEmail() (from a semantical point of view... but this is 
probably blasphemy to anyone that ever considered an 
emailSerializer as something usefull)

regards,
-marc=
PS: don't flame my stupidity here, pointers to obvious stuff I 
missed are welcome
-- 
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