[Israel.pm] Talk: A natural flow for web apps

Ran Eilam eilara at cortext.co.il
Tue Mar 23 23:02:53 PST 2004

You get a well deserved beer. I would have never thought of this evil
hack: partially executing flow() again and again. Crazy.

If I understood correctly, both solutions split prompt() into 2 parts,
and run one part each time prompt() is called. The part to run is
determined by some computation on the call history. One part returns the
correct param from the web browser, the other prints a message and

But you get a small beer, because my example was not representative. I
did not think of your solution, so did not think of how to eliminate the
special cases it does solve. Here are better examples, that will all
fail using the proposed solutions:

This one is for migo (OT: checkout www.4migo.com, despite the name it is
NOT 'for migo', it is for windows), who said- "The script is partially 
executed again and again (why not?)". Here is why not:

  sub flow_replace_product {
     my $old_name= prompt('Enter old product name:');
     delete_product_from_database($old_name); # don't want to call this
     my $new_name= prompt('Enter new product name:');  


  sub flow_counted {
     increase_counter_file(); # should be increased by ONE per session
     prompt("1st page of message");
     prompt("2nd page of message");

I think the proposed solutions only work if flow() has no side effects
on anything, at least until the last prompt() call.

And in terms of performance, you would need to memoize every sub and
hope it is memoizable, because the 1st lines in flow() could be called
many times per request.

In the next example $time is supposed to be the time that the flow
started, but will instead be the time the flow ended:

  sub flow_time_a_was_created {
     my $time = time; # using proposed solutions, time will be wrong
     my $a = prompt('Enter a number:');
     my $b = prompt('Enter another number:');
        "$a was created on $time. Sum is: ".
        ($a + $b).
        '. Hit Enter to continue.'

This one is especially for Zohar:

  sub flow_one_liner { prompt(prompt('enter a') + prompt('enter b')) }

So we have cool (some would say evil) solutions, but for the wrong
problem. The new (correct) problem is- make ANY dialog-style command
line app work on the web, as long as it depends only on some form of
prompt() for user interaction. While changing only the prompt() sub.

You are not allowed to exploit oversights made by the problem author! ;)

Don't worry about the state- just imagine you are running in mod_perl,
and that you are given the same Perl interpreter for all requests in a
session. So anything you store will remain- no need to put it in a file
or a hidden form field.

The issue here is not state. It is flow.


More information about the Perl mailing list