Re: Form validation in insert() and update()?

* Dave Rolsky <autarchurth.org> [2007-05-20
16:40]:
> If the action is a create or update, you want to
redirect to
> the URI for the thing being created or updated. You may
_also_
> want to include some form "successfully
updated" message, so
> this pattern works well for this. That's not very
RESTful,
> though, which is making me think about this some more
for my
> latest project.

Why not stash the message in the query string for the
redirect
target? Or a hash key.

    303 See Other
    Location: /article/why-webarch-matters?msg=created

Then have infrastructure for an `msg` param to cause a
message
box to be shown, with the content “Your article was
successfully
created” as found under the `created` key of your message
phrasebook (which also gives you a convenient hook for
i18n).

It looks a bit crude, but it’s actually a rather good
solution in
REST terms. (Eg. intermediaries won’t cache that resource
as the
same you can retrieve from /article/why-webarch-matters
where the
message box is missing; etc.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/&g
t;

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

A. Pagaltzis wrote:
> * Dave Rolsky <autarchurth.org> [2007-05-20
16:40]:
>> If the action is a create or update, you want to
redirect to
>> the URI for the thing being created or updated. You
may _also_
>> want to include some form "successfully
updated" message, so
>> this pattern works well for this. That's not very
RESTful,
>> though, which is making me think about this some
more for my
>> latest project.
> 
> Why not stash the message in the query string for the
redirect
> target? Or a hash key.
> 
>     303 See Other
>     Location: /article/why-webarch-matters?msg=created
> 
> Then have infrastructure for an `msg` param to cause a
message
> box to be shown, with the content “Your article was
successfully
> created” as found under the `created` key of your
message
> phrasebook (which also gives you a convenient hook for
i18n).
> 
> It looks a bit crude, but it’s actually a rather good
solution in
> REST terms. (Eg. intermediaries won’t cache that
resource as the
> same you can retrieve from /article/why-webarch-matters
where the
> message box is missing; etc.)

Except then the end-user can bookmark that success URL,
which
isn't ideal. I've used that approach before and it worked
okay,
but I think the flash message makes more sense for this.

Maurice


_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

On Sun, 20 May 2007, A. Pagaltzis wrote:

> * Dave Rolsky <autarchurth.org> [2007-05-20
16:40]:
>> If the action is a create or update, you want to
redirect to
>> the URI for the thing being created or updated. You
may _also_
>> want to include some form "successfully
updated" message, so
>> this pattern works well for this. That's not very
RESTful,
>> though, which is making me think about this some
more for my
>> latest project.
>
> Why not stash the message in the query string for the
redirect
> target? Or a hash key.
>
>    303 See Other
>    Location: /article/why-webarch-matters?msg=created
>
> Then have infrastructure for an `msg` param to cause a
message
> box to be shown, with the content $B!H(JYour article
was successfully
> created$B!I(J as found under the `created` key of
your message
> phrasebook (which also gives you a convenient hook for
i18n).
>
> It looks a bit crude, but it$B!G(Js actually a rather
good solution in
> REST terms. (Eg. intermediaries won$B!G(Jt cache that
resource as the
> same you can retrieve from /article/why-webarch-matters
where the
> message box is missing; etc.)

A couple problems. The biggest is that besides messages, I
also pass along 
the submitted form data, so the form can be displayed with
what the user 
submitted. That won't fit in a query string in many cases.

I also like the fact that reloading the page gets rid of the
messages that 
were being displayed, but that's really a small point
compared to the the 
form data issue.


-dave

/*===================================================
VegGuide.Org                        www.BookIRead.com
Your guide to all that's veg.       My book blog
===================================================*/
_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/