Deciding Flowscript <-> Sitemap hooks [was: Re: Changes made to flow system.js]

[Stefano Mazzocchi <st...@apache.org>]

Ovidiu, I know that some of you are somewhat frustrated by this 
'apparently nonsense' discussion on some trivial things like function 
names, but I personally think that a great deal of information was 
exchanged between people on flow and this is a great thing.

Also, I think Chris is right on target with this, so, if you don't mind, 
I'll continue the discussion until we have reached consensus.

I know that javascript allows you to redefine your function names 
easily, but that's working around the problem and it doesn't help to 
create consensus, without with the community might develop friction and 
frustration even more than during the discussions.

Anyway, feel free to ignore this discussion if you don't care about it.

Christopher Oliver wrote:
> Yes, another way of looking at it is that (from the flow script's point 
> of view) sendPageAndWait()
> 
> 1) displays a form page in the client's browser
> 2) waits for the form to be submitted (which becomes available to the 
> script as the cocoon.request property)
> 3) returns
> 
> So this function describes a round trip interaction.

Yep.

> I believe in 
> Christian Queinnec's original (scheme) code he called this function 
> simply "show". Thus like "sendPage" his name focused on the first leg of 
> the trip. Other names like,
> 
>  getReply()
>  getUserInput(uri, bizData)
> 
> focus on the return leg of the round trip. I think both are valid 
> (partial) descriptions of the function's behavior. I don't think one or 
> the other is superior. And combined names like sendPageAndWait or 
> sendPageAndGetUserInput() seem overly explicit and ugly.

Very good description.

> So here are some other possibilities:
> 
> 1)  Revert to the nice
> 
>   sendPage(uri, bizData);
> 
> instead of the ugly sendPageAndWait() and use something ugly and 
> explicit like
> 
>   sendPageNoWait(uri, bizData);
> 
> instead of sendPageAndContinue();
> 
> 2) Explicitly identify the input page, such as
> 
>    sendForm(uri, bizData); // block waiting for user input; 
> cocoon.request contains the submitted request after this returns
> 
> and
> 
>    sendPage(uri, bizData); // send a page that won't return here; 
> cocoon.request is invalid after this returns

Ohhhh, nice!!!

What I like about this is that semantics are abstract enough to mean 
anything, but they don't confuse people!

more about this below.

> 3) Punt on distinguishing this behavior with the name of the function. 
> Just add a third (optional) boolean parameter to indicate if it should 
> block
> 
>    sendPage(uri, bizData, waitForInput);

I like the above better.

What I mostly like is the distinction between a 'form' and a 'page'.

The way I've been programming web application is that POST and GET 
actions should be connected to the same resource.

I mean, if I have to POST something, first of all I GET it, then fill up 
the form, then POST it, then get results. All good webapp frameworks try 
to enforce the notion of this in-resource roundtripping.

This is also because a page can contain *more* than one form.

For this reason, I would propose to change the notion from 'form' to 
'screen' to avoid having the semantic collision between what a 'form' is 
for flow and what a form is for HTML.

So, my proposal would be

  sendScreen(uri, data);

    - sends the screen containing a form that will trigger a POST action 
that will go back here
    - blocks the execution of the flow until a request with the matching 
continuation ID comes back
    - returns with the cocoon.* objects filled with the latest client data

  sendPage(uri, data);

    - sends a page
  (no further rountripping is expected from that page so no state is 
transparently preserved)

                                     - o -

I have an alternative proposal, even if this requires more changes to 
the system:

Instead of "sendScreen", why don't we do:

  var objectModel = getClientInput(uri,data);

then

  sendPage(uri);

getClientInput will *implicitly* have a blocking semantics. I know this 
explicitly outlines the third step, but IMO this solves one cognitive 
problem that I had when Ovidiu first described the flow: how I get the 
client data back from sendPage()?

Having the data *explicitly* returned from the method invocation is, 
IMO, a *GREAT* help.

What do you think?

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------



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

Re: Deciding Flowscript <-> Sitemap hooks [was: Re: Changes made to flow system.js]

[Ovidiu Predescu <ov...@apache.org>]

On Tuesday, Dec 10, 2002, at 12:36 US/Pacific, Stefano Mazzocchi wrote:

> Ovidiu, I know that some of you are somewhat frustrated by this 
> 'apparently nonsense' discussion on some trivial things like function 
> names, but I personally think that a great deal of information was 
> exchanged between people on flow and this is a great thing.

Yes, indeed, this discussion helped clarify a lot of misunderstanding 
people had about flow. I've never said it was nonsense, I just wanted 
to reach a logical conclusion. I'm concerned about the bandwidth we 
spend on such unimportant issues, instead of discussing the real meat 
of the problem. It's getting more and more a discussion about form 
instead of content.

> Also, I think Chris is right on target with this, so, if you don't 
> mind, I'll continue the discussion until we have reached consensus.

Chris helped indeed a great deal in clarifying the misunderstanding I 
mentioned above. It looks like some of them still persist, I'll reply 
to some of those later in this message.

> I know that javascript allows you to redefine your function names 
> easily, but that's working around the problem and it doesn't help to 
> create consensus, without with the community might develop friction 
> and frustration even more than during the discussions.

I don't think naming conventions will create frictions in the nice 
community of people we have here, it's the design issues which usually 
create frictions. From this thread however, I see discussed only 
function names, and not the design aspects of the control flow. I don't 
a consensus can be reached on names, so IMO it's better to decide on 
something good enough and stick with it.

> Anyway, feel free to ignore this discussion if you don't care about it.

Ahem, but would you ignore a discussion that consumes such a bandwidth? 
;)

>> So here are some other possibilities:
>> [...]
>> 2) Explicitly identify the input page, such as
>>    sendForm(uri, bizData); // block waiting for user input; 
>> cocoon.request contains the submitted request after this returns
>> and
>>    sendPage(uri, bizData); // send a page that won't return here; 
>> cocoon.request is invalid after this returns
>
> [...]
>
> So, my proposal would be
>
>  sendScreen(uri, data);
>
>    - sends the screen containing a form that will trigger a POST 
> action that will go back here
>    - blocks the execution of the flow until a request with the 
> matching continuation ID comes back
>    - returns with the cocoon.* objects filled with the latest client 
> data
>
>  sendPage(uri, data);
>
>    - sends a page
>  (no further rountripping is expected from that page so no state is 
> transparently preserved)
>
>                                     - o -
>
> I have an alternative proposal, even if this requires more changes to 
> the system:
>
> Instead of "sendScreen", why don't we do:
>
>  var objectModel = getClientInput(uri,data);
>
> then
>
>  sendPage(uri);
>
> getClientInput will *implicitly* have a blocking semantics. I know 
> this explicitly outlines the third step, but IMO this solves one 
> cognitive problem that I had when Ovidiu first described the flow: how 
> I get the client data back from sendPage()?
>
> Having the data *explicitly* returned from the method invocation is, 
> IMO, a *GREAT* help.

The original sendPage() function already returns something: it's the 
continuation object. This object cannot be returned in any other way 
from sendPage(). Even though normal users will never use it, it's still 
a good idea to have that object available for advanced scripts.

Stefano, all the API change proposals I've seen so far can be 
implemented easily in few lines of code in JavaScript. My take on this 
is that is not worth spending our time (not to mention eating Apache's 
bandwidth ;) analyzing each and every possible API we can come up with. 
Instead of doing that, we can have the simple API already in place, and 
build on top of it, or rip it apart and implement a custom one in 
various applications. We'll see later what works and what not. And 
since each application is unique, experienced developers will come up 
with their own higher level abstractions on top of what is already 
here. This is not an issue at all, there are always better ways to do 
things.

We desperately need some documentation for the current features and 
various other things to be finished, before this stuff can become 
production quality. I'd suggest these naming discussions to stop here, 
and instead focus on the places where the real work still needs to be 
done. My time is limited, so I'd really appreciate any help in those 
areas.

I hope this doesn't sound offensive, it's certainly not meant to be so.

Best regards,
Ovidiu

-- 
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/


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