FAQ
Hi.

I'm working on the project request section of our new project tracking system. The request form is broken up into 12 pages-yes, lots and lots of data to be submitted.

Anyone have any experience / advice on how to handle that many fields? Should I use a single subroutine to handle it all based on a "page" variable? Or, should I simply have a subroutine per page? How about going back to correct something the user messed up during initial entry-we want to show a summary of the data before final submission.

Any help is appreciated.

Thanks,

bill

CONFIDENTIALITY NOTICE: This E-Mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute and delete the original message. Please notify the sender by E-Mail at the address shown. Thank you for your compliance

Search Discussions

  • Thiago Rondon at Nov 16, 2010 at 10:42 pm

    Em 16-11-2010 20:01, Hauck, William B. escreveu:
    Hi.

    I'm working on the project request section of our new project tracking system. The request form is broken up into 12 pages-yes, lots and lots of data to be submitted.

    Anyone have any experience / advice on how to handle that many fields? Should I use a single subroutine to handle it all based on a "page" variable? Or, should I simply have a subroutine per page? How about going back to correct something the user messed up during initial entry-we want to show a summary of the data before final submission.

    Any help is appreciated.
    Where is the data between pages ?

    -Thiago Rondon
  • Victor Churchill at Nov 16, 2010 at 10:50 pm
    Put it all on one page and use JS in the template to toggle different divs?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20101116/2a6d8213/attachment.htm
  • Kieren Diment at Nov 16, 2010 at 11:02 pm

    On 17/11/2010, at 9:50 AM, Victor Churchill wrote:

    Put it all on one page and use JS in the template to toggle different divs?
    Having dealt with some large forms recently(and depending on how heavy the JS is on the page), this can result in browser slowdowns in some environments. Probably the simplest approach is to incrementally update the database, and keep the current primary key for the record somewhere in the form (in a hidden field) or in the url. If you don't want to insert until everything is finished, then storing everything previously entered in hidden fields is also a reasonable approach in some situations.
  • Eric Berg at Nov 16, 2010 at 11:14 pm
    What about breaking the form up logically and saving each section in a session object as they move through the form.

    That or incrementally save and maintain a db flag that indicates doneness. Frankly, with.a form that long, it'd be rude to require the user to start from scratch if they couldn't finish in one session.

    Eric
    -----Original Message-----
    From: Victor Churchill <victor@softwareshack.eu>
    Date: Tue, 16 Nov 2010 22:50:06
    To: The elegant MVC web framework<catalyst@lists.scsys.co.uk>
    Reply-To: The elegant MVC web framework <catalyst@lists.scsys.co.uk>
    Subject: Re: [Catalyst] Suggestions on how to handle 12 page form

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Eden Cardim at Nov 17, 2010 at 12:31 am
    "Eric" == Eric Berg writes:
    Eric> What about breaking the form up logically and saving each
    Eric> section in a session object as they move through the form.
    Eric> That or incrementally save and maintain a db flag that
    Eric> indicates doneness. Frankly, with.a form that long, it'd be
    Eric> rude to require the user to start from scratch if they
    Eric> couldn't finish in one session.

    Be careful with how you implement it using the session though, if they
    give up on the process and come back later, they'll land in the middle
    of the previous process and possibly not remember why. Also, if you just
    stash the values in the session, you can't do useful things like passing
    a URI pointing to a half-filled form for someone else to fill in.

    One way to do it and not break HTTP's stateleness that much is to create
    a token for each "form fill" attempt, and resubmit it throughout each
    page of the form in order to get to the session-stashed data and prefil
    the form from it, then the app figures out what's the next step based on
    how much of the form is filled. It's basically the same thing as a
    regular form except that you write to the session using the token you
    got from the current request. At the final step, you commit the data to
    the storage and clear the token/data from the session.

    If you want to get sophisticated, you can create a new token for each
    step and create a linked list of tokens, in order to create a
    bread-crumb-like behaviour.

    I've been wanting to write a module with that logic for some time now,
    but I always find myself lacking the tuits.

    --
    Eden Cardim Need help with your perl Catalyst or DBIx::Class project?
    Software Engineer http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://blog.edencardim.com http://www.shadowcat.co.uk/servers/
  • Octavian Rasnita at Nov 17, 2010 at 6:38 am
    From: "Hauck, William B." <William.Hauck@ibx.com>
    Hi.

    I'm working on the project request section of our new project tracking
    system. The request form is broken up into 12 pages-yes, lots and lots of
    data to be submitted.

    Anyone have any experience / advice on how to handle that many fields?
    Should I use a single subroutine to handle it all based on a "page"
    variable? Or, should I simply have a subroutine per page? How about going
    back to correct something the user messed up during initial entry-we want to
    show a summary of the data before final submission.

    Any help is appreciated.

    Thanks,

    bill




    Hi Bill,

    I think the best approach is to create an action for each "page" of the form
    and after each form submission partially update one or more database tables,
    saving a marker that shows which was the last page completed.

    And after each form submission, depending on some options chosen by the user
    you can redirect to the next form or to display a certain form which is
    displayed only in some conditions.

    After the user submitted the first form, in which you may ask him/her for
    his/her email, you can automaticly send him/her an email with a link that
    can be used to access this "wizard" where he/her left it, maybe even from
    another computer.
    This way, it is not a problem if the user's computer has frozen after he/she
    completed 99% of the wizard or he/she should continue only after a certain
    period.

    You can also put "previous links in every page that would display the
    previous filled form, pre-filled with the values this user already filled
    (which are taken from the database).

    For creating the forms you can use a tool like HTML::FormFu or
    manually-created forms... it doesn't matter.

    Octavian
  • Mike Raynham at Nov 17, 2010 at 7:36 am

    On 16/11/10 22:01, Hauck, William B. wrote:
    Hi.

    I'm working on the project request section of our new project tracking system. The request form is broken up into 12 pages-yes, lots and lots of data to be submitted.

    Anyone have any experience / advice on how to handle that many fields? Should I use a single subroutine to handle it all based on a "page" variable? Or, should I simply have a subroutine per page? How about going back to correct something the user messed up during initial entry-we want to show a summary of the data before final submission.

    Any help is appreciated.

    Thanks,

    bill

    CONFIDENTIALITY NOTICE: This E-Mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute and delete the original message. Please notify the sender by E-Mail at the address shown. Thank you for your compliance

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    In the UK, HMRC tax self assessment forms can be completed online. The
    process comprises many pages - essentially one big form that has been
    split into logical sections. I last completed this a few months ago, so
    what follows may not be entirely accurate...

    The user is able to advance through the form one page at a time. At the
    end of each page there is an option to save the current page, and an
    option to continue to the next page. I think it is possible to
    partially complete pages (where, for example, the user doesn't have all
    the information to hand), and return to them later. The save option
    allows the user to save the form in its current state, logout, and
    return at a later date.

    Each page is validated in real time using JS and also when the page is
    submitted. There is a vertical menu which shows all the sections.
    Completed sections are highlighted, and it is possible to return to
    these at any time to make amendments.

    Once the whole form has been completed, you have the option to finalise
    and submit it. After this final submission, it is not possible to go
    back and make any changes. From my experiences, the system works quite
    well. Completing the whole form can be a lengthy process, so being able
    to move around between the pages, and complete the form over multiple
    sessions is very useful.
  • Rippl, Steve at Nov 17, 2010 at 3:48 pm

    On Tue, Nov 16, 2010 at 10:38 PM, Octavian Rasnita wrote:


    Hi Bill,

    I think the best approach is to create an action for each "page" of the form and after each form submission partially update one or more database tables, saving a marker that shows which was the last page completed.

    And after each form submission, depending on some options chosen by the user you can redirect to the next form or to display a certain form which is displayed only in some conditions.

    After the user submitted the first form, in which you may ask him/her for his/her email, you can automaticly send him/her an email with a link that can be used to access this "wizard" where he/her left it, maybe even from another computer.
    This way, it is not a problem if the user's computer has frozen after he/she completed 99% of the wizard or he/she should continue only after a certain period.

    You can also put "previous links in every page that would display the previous filled form, pre-filled with the values this user already filled (which are taken from the database).

    For creating the forms you can use a tool like HTML::FormFu or manually-created forms... it doesn't matter.

    Octavian
    I use the same controller for the whole form but point to a different
    html::formfu .yml file for each page of the form. ?I then put tabs
    across the top of the form for each "page" so the user can go back and
    forth, each submission saving that part of the form, the tabs linking
    back to the same page with a different additional arg ($form_id) that
    links to the corrent .yml file. ?Something along the lines of...

    sub index : Path {
    ?? ?my ( $self, $c, $id, $form_id, $hash ) = @_;

    [-- validation etc --]

    $form = $self->form;
    $form->load_config_filestem($c->config->{root}."/forms/students/info$form_id");
    $form->process;
    $c->stash->{form} = $form;

    if ( $form->submitted_and_valid ) {
    [-- save stuff --]
    }

    [-- display stuff --]
    }

    The $hash variable is so I can email them a unique link back to the
    form so they can complete it later (for folks not authenticated into
    the system, ie. the public).


    --
    Steve Rippl
    Technology Director
    Woodland Public Schools
    360 841 2730
  • Nicholas Wehr at Nov 17, 2010 at 3:58 pm
    I did the same as Mark, saving the form in progress was a product
    requirement but also a good user experience.

    I used extjs to make a pretty slick wizard, with questions dynamically
    created based on previous answers. Caveat: significant learning curve -
    http://dev.sencha.com/deploy/ext/examples/

    cheers,
    -nw

    On Tue, Nov 16, 2010 at 11:36 PM, Mike Raynham
    wrote:
    On 16/11/10 22:01, Hauck, William B. wrote:

    Hi.

    I'm working on the project request section of our new project tracking
    system. The request form is broken up into 12 pages-yes, lots and lots of
    data to be submitted.

    Anyone have any experience / advice on how to handle that many fields?
    Should I use a single subroutine to handle it all based on a "page"
    variable? Or, should I simply have a subroutine per page? How about going
    back to correct something the user messed up during initial entry-we want to
    show a summary of the data before final submission.

    Any help is appreciated.

    Thanks,

    bill

    CONFIDENTIALITY NOTICE: This E-Mail is intended only for the use of the
    individual or entity to which it is addressed and may contain information
    that is privileged, confidential and exempt from disclosure under applicable
    law. If you have received this communication in error, please do not
    distribute and delete the original message. Please notify the sender by
    E-Mail at the address shown. Thank you for your compliance

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    In the UK, HMRC tax self assessment forms can be completed online. The
    process comprises many pages - essentially one big form that has been split
    into logical sections. I last completed this a few months ago, so what
    follows may not be entirely accurate...

    The user is able to advance through the form one page at a time. At the
    end of each page there is an option to save the current page, and an option
    to continue to the next page. I think it is possible to partially complete
    pages (where, for example, the user doesn't have all the information to
    hand), and return to them later. The save option allows the user to save
    the form in its current state, logout, and return at a later date.

    Each page is validated in real time using JS and also when the page is
    submitted. There is a vertical menu which shows all the sections. Completed
    sections are highlighted, and it is possible to return to these at any time
    to make amendments.

    Once the whole form has been completed, you have the option to finalise and
    submit it. After this final submission, it is not possible to go back and
    make any changes. From my experiences, the system works quite well.
    Completing the whole form can be a lengthy process, so being able to move
    around between the pages, and complete the form over multiple sessions is
    very useful.


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20101117/ada27739/attachment.htm
  • Octavian Rasnita at Nov 17, 2010 at 7:11 pm
    Hi,

    Thanks for the example. I think that the following line could be improved:

    $form->load_config_filestem($c->config->{root}."/forms/students/info$form_id");

    to be (untested):

    $form->load_config_filestem($c->uri_for("root/forms/students/info$form_id"));

    Octavian

    ----- Original Message -----
    From: "Rippl, Steve" <rippls@woodlandschools.org>
    To: "The elegant MVC web framework" <catalyst@lists.scsys.co.uk>
    Sent: Wednesday, November 17, 2010 5:48 PM
    Subject: Re: [Catalyst] Suggestions on how to handle 12 page form


    On Tue, Nov 16, 2010 at 10:38 PM, Octavian Rasnita
    wrote:

    Hi Bill,

    I think the best approach is to create an action for each "page" of the form and after each form submission partially update one or more database tables, saving a marker that shows which was the last page completed.

    And after each form submission, depending on some options chosen by the user you can redirect to the next form or to display a certain form which is displayed only in some conditions.

    After the user submitted the first form, in which you may ask him/her for his/her email, you can automaticly send him/her an email with a link that can be used to access this "wizard" where he/her left it, maybe even from another computer.
    This way, it is not a problem if the user's computer has frozen after he/she completed 99% of the wizard or he/she should continue only after a certain period.

    You can also put "previous links in every page that would display the previous filled form, pre-filled with the values this user already filled (which are taken from the database).

    For creating the forms you can use a tool like HTML::FormFu or manually-created forms... it doesn't matter.

    Octavian
    I use the same controller for the whole form but point to a different
    html::formfu .yml file for each page of the form. I then put tabs
    across the top of the form for each "page" so the user can go back and
    forth, each submission saving that part of the form, the tabs linking
    back to the same page with a different additional arg ($form_id) that
    links to the corrent .yml file. Something along the lines of...

    sub index : Path {
    my ( $self, $c, $id, $form_id, $hash ) = @_;

    [-- validation etc --]

    $form = $self->form;
    $form->load_config_filestem($c->config->{root}."/forms/students/info$form_id");
    $form->process;
    $c->stash->{form} = $form;

    if ( $form->submitted_and_valid ) {
    [-- save stuff --]
    }

    [-- display stuff --]
    }

    The $hash variable is so I can email them a unique link back to the
    form so they can complete it later (for folks not authenticated into
    the system, ie. the public).


    --
    Steve Rippl
    Technology Director
    Woodland Public Schools
    360 841 2730

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Bogdan Lucaciu at Nov 17, 2010 at 7:44 pm

    On Wed, Nov 17, 2010 at 9:11 PM, Octavian Rasnita wrote:

    Thanks for the example. I think that the following line could be improved:
    $form->load_config_filestem($c->config->{root}."/forms/students/info$form_id");
    to be (untested):
    ? ?$form->load_config_filestem($c->uri_for("root/forms/students/info$form_id"));
    Do you mean path_to instead of uri_for ?

    --
    Bogdan Lucaciu
  • Octavian Rasnita at Nov 18, 2010 at 6:24 am
    From: "Bogdan Lucaciu" <bogdan@sinapticode.ro>
    On Wed, Nov 17, 2010 at 9:11 PM, Octavian Rasnita wrote:

    Thanks for the example. I think that the following line could be improved:
    $form->load_config_filestem($c->config->{root}."/forms/students/info$form_id");
    to be (untested):
    $form->load_config_filestem($c->uri_for("root/forms/students/info$form_id"));
    Do you mean path_to instead of uri_for ?

    --
    Bogdan Lucaciu


    Oh yes, I'm sorry. Of course path_to().

    Thanks for correction.

    Octavian

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedNov 16, '10 at 10:01p
activeNov 18, '10 at 6:24a
posts13
users12
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase