FAQ
Catalystry:

We have a ticketing system where the managers can add new data and update
the form. This uses a normal "submit" button. But now and then they want to
close an incident, so we have a "save-and-close" submit button as well. One
form, two ways to submit.

So there's a second page where they fill out some finalization options (with
the original data in hidden fields) and there they have a final "submit"
button for the purpose. And they should be able to use their browser's
"back" button to get back to the edit form.


What's the elegant way to handle this in Catalyst?


The problem we're wrestling with is that the "edit" action should have a URL
distinct from the close action so that the user can hit the "back" button if
need be.

/item/# <= view item
/item/#/edit <= edit form
/item/#/close <= confirm-close form

We're using HTML::FormHandler and DBIC. And the solution shouldn't rely on
javascript.

All pointers welcome!

--
The first step towards getting somewhere is to decide that you are not going
to stay where you are. -- J.P.Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110207/624dcc53/attachment.htm

Search Discussions

  • Len Jaffe at Feb 7, 2011 at 7:29 pm

    On Mon, Feb 7, 2011 at 11:41 AM, will trillich wrote:

    Catalystry:

    So there's a second page where they fill out some finalization options
    (with the original data in hidden fields) and there they have a final
    "submit" button for the purpose. And they should be able to use their
    browser's "back" button to get back to the edit form.


    The problem we're wrestling with is that the "edit" action should have a
    URL distinct from the close action so that the user can hit the "back"
    button if need be.

    /item/# <= view item
    /item/#/edit <= edit form
    /item/#/close <= confirm-close form

    Nah. I wouldn't have two URLs. I'd have one URL, and determine whether to
    save or save+close based on the value of the submit button.
    Furthernore, after a successful submit (assuming http POST) I'd redirect the
    user to a new display page via GET so that they can hit the refresh button
    all the like without attempting to repost the submission.

    Len.

    --
    lenjaffe@jaffesystems.com 614-404-4214
    Asst. Scoutmaster Troop 156 - www.bsatroop156.org -
    webmaster@bsatroop156.org
    Proprietor: http://www.theycomewithcheese.com/ - An Homage to Fromage
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110207/3365b42b/attachment.htm
  • Francisco Obispo at Feb 7, 2011 at 7:42 pm
    Well, what I would do, is keep the underlying 'save' and 'close' methods as private:


    sub save : Private {
    my ($self,$c)=@_;

    # your save code goes here

    }

    sub close : Private {
    my ($self,$c)=@_;

    # your close code goes here

    }


    That way you could have:

    sub action : Local {
    my ($self,$c)=@_;
    $c->forward('save');
    $c->forward('close') if $c->request->param("close"); # or something
    }


    Francisco












    On Feb 7, 2011, at 11:29 AM, Len Jaffe wrote:



    On Mon, Feb 7, 2011 at 11:41 AM, will trillich wrote:
    Catalystry:

    So there's a second page where they fill out some finalization options (with the original data in hidden fields) and there they have a final "submit" button for the purpose. And they should be able to use their browser's "back" button to get back to the edit form.


    The problem we're wrestling with is that the "edit" action should have a URL distinct from the close action so that the user can hit the "back" button if need be.

    /item/# <= view item
    /item/#/edit <= edit form
    /item/#/close <= confirm-close form


    Nah. I wouldn't have two URLs. I'd have one URL, and determine whether to save or save+close based on the value of the submit button.
    Furthernore, after a successful submit (assuming http POST) I'd redirect the user to a new display page via GET so that they can hit the refresh button all the like without attempting to repost the submission.

    Len.

    --
    lenjaffe@jaffesystems.com 614-404-4214
    Asst. Scoutmaster Troop 156 - www.bsatroop156.org - webmaster@bsatroop156.org
    Proprietor: http://www.theycomewithcheese.com/ - An Homage to Fromage
    _______________________________________________
    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/
    Francisco Obispo
    Hosted@ Programme Manager
    email: fobispo@isc.org
    Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
    Key fingerprint = 532F 84EB 06B4 3806 D5FA 09C6 463E 614E B38D B1BE
  • Will Trillich at Feb 7, 2011 at 8:03 pm
    Dang, this is really quite spiffy. Thanks for the idea!

    On Mon, Feb 7, 2011 at 1:42 PM, Francisco Obispo wrote:

    Well, what I would do, is keep the underlying 'save' and 'close' methods as
    private:


    sub save : Private {
    my ($self,$c)=@_;

    # your save code goes here

    }

    sub close : Private {
    my ($self,$c)=@_;

    # your close code goes here

    }


    That way you could have:

    sub action : Local {
    my ($self,$c)=@_;
    $c->forward('save');
    $c->forward('close') if $c->request->param("close"); # or something
    }


    Francisco












    On Feb 7, 2011, at 11:29 AM, Len Jaffe wrote:



    On Mon, Feb 7, 2011 at 11:41 AM, will trillich <
    will.trillich@serensoft.com> wrote:
    Catalystry:

    So there's a second page where they fill out some finalization options
    (with the original data in hidden fields) and there they have a final
    "submit" button for the purpose. And they should be able to use their
    browser's "back" button to get back to the edit form.

    The problem we're wrestling with is that the "edit" action should have a
    URL distinct from the close action so that the user can hit the "back"
    button if need be.
    /item/# <= view item
    /item/#/edit <= edit form
    /item/#/close <= confirm-close form


    Nah. I wouldn't have two URLs. I'd have one URL, and determine whether
    to save or save+close based on the value of the submit button.
    Furthernore, after a successful submit (assuming http POST) I'd redirect
    the user to a new display page via GET so that they can hit the refresh
    button all the like without attempting to repost the submission.
    Len.

    --
    lenjaffe@jaffesystems.com 614-404-4214
    Asst. Scoutmaster Troop 156 - www.bsatroop156.org -
    webmaster@bsatroop156.org
    Proprietor: http://www.theycomewithcheese.com/ - An Homage to Fromage
    _______________________________________________
    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/
    Francisco Obispo
    Hosted@ Programme Manager
    email: fobispo@isc.org
    Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
    Key fingerprint = 532F 84EB 06B4 3806 D5FA 09C6 463E 614E B38D B1BE





    _______________________________________________
    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/


    --
    The first step towards getting somewhere is to decide that you are not going
    to stay where you are. -- J.P.Morgan
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110207/380136ef/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedFeb 7, '11 at 4:41p
activeFeb 7, '11 at 8:03p
posts4
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase