On Wednesday 19 December 2001 03:49 pm, you wrote:
> On Tue, 18 Dec 2001 20:57:22 -0600, Judson Lester <[EMAIL PROTECTED]> wrote:
<snip/>
> a) If you look closely at the get-user function, you will notice an
> interesting fact, which is a non-local exit to a totally different
> context, in case the user doesn't enter valid information:
>
> function get-user()
> {
> // get-user() returns only with valid credentials.
> // If no valid credentials are found, this function never returns.
>
> for (count = 0; count < 3; count++) {
> send-page("get-username.xml");
>
> user = request.getParameter("username");
> passwd = request.getParameter("password");
>
> usersDB = UsersDatabase.newConnection();
> if (!usersDB.isUserKnown(user, passwd))
> registration();
> else
> return userDB.credentialsForUser(user, passwd);
> }
>
> // This shows the user a sorry page with a single link that points to
> Home. // This is an example of a non-local exit, where the computation will
> // continue at a different location in the program.
> send-page("sorry-page.xml");
> }
>
> What this essentially means for the caller of get-user is that it's
> guaranteed that the returned value is a useful. Otherwise the flow of
> the program continues in a different part of it, and never returns to
> the caller.
>
> This can make the applications potentially easier to write for a
> developer doesn't have to explicitly handle error conditions. It's a
> bit difficult to follow if you're not aware of the special
> functionality of the send-page() function, but as you understand it,
> it's much clear.
Actually, I like this idea very much. See my response further down the
thread for some querrelsome points about send-page() exits.
However, I'd more propose that functions that <emp>do</emp> return a value
not be allowed. Java methods can be called, and their results used, etc,
(which does broach the questions of exceptions thrown into a flow...), and
I'd envision objects designed to serve the logic of a flowmap. This would
put the control of the business logic in one person's hands (or the same
person with a different hat) and the flow of the webapp in another's.
or instance, picture
function get-user(credentials)
{
for (count = 0; count < 3; count++) {
send-page("get-username.xml");
verifier=new userVerifier(request);
if (!verifier.isValid)
registration();
else
{
credentials=verifier.getCredentials();
return;
}
}
send-page("sorry-page.xml");
}
I will admit that this requires a pass by reference architecture, but that
would be simpler to implement, and obviate the need for an actual call stack.
Ultimately, if the flowmap is processed in any way, a function that returns
could be inlined anywhere it's called.
>
> b) A continuation captures the whole state of the program, which means...
<snip/>
> With continuations, going back in the processing history using the
> "back" button in the browser, means reverting to old values of
> variables in your program. This is very difficult to achieve with
> session objects.
>
A trivial side-note of an implementation detail:
I'm assuming the continuation URLs you were proposing would be above and
beyond other methods of session tracking. That ultimately, the container of
Cocoon would maintain a user's session, which would include a map of URLs to
continuations, or something along those lines?
> So to answer your question about the servlet model, I think there's
> little value in maintaining the session object idea. And I don't think
> of anything else from the servlet programming model that needs to be
> kept around. The request object is passed to the flow program, but not
> the response, who is generated by the send-page() indirectly.
So, yes, flowmaps imply the abandoning of Servlets as a webapp development
unit. (However, I also assume that Stefano's comments about Actions still
holds.)
<snip/>
> > In the buy() example, oughtn't a> ship-to-address and charge-credit-card
> > fall more into Servlets? (Perhaps not entirely, but some portion...) and
> > b> where does buy() lead, eventually?
>
> The intent of the ship-to-address was to collect the address where the
> shipment should be sent, and not to do the actual shipment. It should
> perhaps be renamed to get-address-for-shipping instead to avoid any
> confusions.
It was reading this section that led to the above suggestion about pass by
reference and functions that return, but don't return a value.
But I feel like my earlier comment's thrust may have missed it's mark. It
seems to me that usually, "functions" in a flow map are never going to
return, that the typical flow is going to be a series of function calls that
eventually exit, with perhaps a few calls to functions that could adequately
be modeled as inline/macro style units. And so for the meat of the flow, the
notion of returning to your caller would be wrong.
For example:
function head() //some link starts flow here
{
return;
}
This seems like a wrong thing. An error. The result would be something like
the user pushing a Submit button and getting a 40x error.
I make again the analogy to
...
switch(blah)
{
case 1: x=1;
case 2: x=2;
default throw(new Error("blah must be 1 or 2"));
}
...
It's only the entrenched nature of the switch statement that makes default
flow-through accepted by anyone, and <select/>'s syntax is much more sensible.
<strong>So,</strong> I propose that the fundamental unit of a flow map not be
a function that can return. (I do agree that for purposes of clean, neat,
reusable code, some sort of at least macro-style function be available, but I
strongly suggest that the power of such functions be controlled.)
<snip/>
>
> > I'd tentatively suggest that returns not be allowed, since it would be
> > incredibly difficult to implement logic in the flowmap without them.
>
> I'm not sure I understand this: should return be or not be allowed?
My thinking was that they not be allowed, but on reflection I think that
might be too much of a restriction, and that a proceedural unit that takes
parameters passed by referenced and doesn't return a value would be a
requirement for flowmaps to be useful, but such functions not be the
legitimate terminators for any proceedural unit.
>
> > Of course "continuations" as they exist in Scheme rely on them, but
> > the idea of an object to keep track of the current position doesn't
> > strictly require a call stack.
>
> As I've shown above, a continuation maintains everything, including
> the call stack.
My point is that my intuition of use is that the typical call stack would be
very long and never returned to, and so only the last level need be kept
track of.
> Thanks for you insightful comments!
Don't mention it. Thanks for your insightful responses!
Judson
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
