Rails - Oct 2005 - (long) dynamic content in a form, design question

Hi,

I am not sure how to design this, so I would like to have some advice
before I start coding.

The scenario is that the user is asked to insert a value in a form;
when the form is submitted  the controller for the form calls a Perl
script that will return an unknown number of results string. The Perl
script is wrapped in some ruby code, and it is inherently slow, doing
a lot of processing. Results are returned at an unpredictable pace, as
soon as a result string is produced the ruby wrapper reads the string
in and pushes it in some data structure.
In the next step the user is asked to select one of the result and
submit a final form, this time an ActiveRecord will be stored in the
DB.

I think the simple approach to this would be to prompt the user with a
waiting page while the result from the script are being collected, and
after X sec redirect the user to final form.

However the longer the script runs the more results might be
collected, giving the user more choices. If results from the script
are shown live on the final form webpage, then the user could stop the
script when the desidered result shows up and submit the final form on
the fly.

This sounds fun to implement,I could use periodically_call_remote to
display the results as soon as they are collected. However I am not
sure how to implement the controller, whether I need a separate thread
to run the script/wrapper or not, and how to insert the value fetched
from periodically_call_remote into the form.

As someone done something like this before?

Thanks
.giulio

Hi !

2005/10/15, Giulio Mola <lamola@gmail.com>:
> As someone done something like this before?
Nope, haven't done anything like this, but here's a strategy:

1. User submits form
2. Controller initiates the long running process by forking
3. Controller returns a "waiting for results" view, with a
periodically_call_remote to know how many results are returned
4. The long running process saves rows to the database
5. "waiting for results" calls into "how_many_results",
which returns
the number of rows and other intersting bits of data
6. When the user selects the results, delete the temporary rows, and
kill the long process

When I say long process here, you could always replace with DRb.  And
then you could save results in RAM instead of going to the DB - less
cruft.

Hope that helps !
François

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails