Form validation and conditional redirects

[Garry Shutler]

I've been asking on twitter about how to do a conditional redirect
from an action (ie. have one path that redirects, another than
displays a view). This is a common scenario when working with non-ajax
forms.

Going to give an example of editing a username of an existing user.
This is going to be quite long but should hopefully serve as a good
example of how the approaches contrast with Fubu's. It may be that I
don't fully understand Fubu's approach yet and that I'm missing
something.

Syntax might not be spot on as I'm doing this straight into the text
box but the essence will be correct.

In MVC:

public ViewResult Index()
{
var user = GetUser();
ViewData.Model = new UserViewModel
{
Username = user.Username
};
return View("Index");
}

[AcceptVerbs(HttpVerbs.Post)]
ActionResult Index(UserViewModel model)
{
if (ModelState.IsValid)
{
// update user and save, etc
return Redirect("Somewhere");
}
ViewData.Model = model;
return View("Index");
}

In OpenRasta:

UserViewModel Get()
{
var user = GetUser();
return new UserViewModel
{
Username = user.Username
};
}

OperationResult Post(UserViewModel model)
{
if (IsValid(model))
{
// update user and save, etc
return new OperationResult.SeeOther { RedirectUri =
"somewhere" };
}
return new OperationResult.OK { ResponseResource =
model };
}

Now as I understand it in Fubu you do a FubuContinuation.Redirect or a
FubuContinuation.Transfer which effectively calls the GET side of the
pair again. In this scenario that would mean I lose what the user
entered into the invalid form so I can't show it to them again. Now
this doesn't make sense so is where I think I must be grasping the
sharp and prickly end of the stick.

I haven't looked at the Fubu code in much depth but it seems to me
that if I'm not getting it completely wrong it would be useful to also
have something like FubuContinuation.Render(model) for the path where
you want it render what you have at that point. Then you would have a
trio of redirect, do something else or render what I've got.

Thoughts?

[Jeremy D. Miller]

Garry,

1.) I still owe you that blog post and I'll get to it before the nights over.

2.) The FubuContinuation can either redirect or merely "transfer" which just means "jump into another behavior chain and execute that one."  Essentially doing what you were saying with the "FubuContinuation.Render" model.  You do NOT have to perform the redirect and the second GET unless that's what you want to happen.

3.) You do have three choices.  Redirect, jump over to this other behavior chain, or just continue to the rest of the chain.  The last choice is for mobile type scenarios where to might put conditional interception in front of an existing action after the fact.

The IFubuRequest and the backing IRequestData are the "model bag" and the Fubu abstraction of all the HttpContext goop.  Both those objects are scoped by the Container to the full request lifecycle.  Returning FubuContinuation.Transfer( some model ) pulls out the behavior chain for the input model from the same nested container as the original request and runs that behavior scoped from there (so you're using one single NH ISession for both the FubuContinuation action and whatever happens next).  All of the user input is most definitely available from the IFubuRequest interface throughout the entire execution process.

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: Garry Shutler <ga...@robustsoftware.co.uk>
To: FubuMVC Development Group <fubumv...@googlegroups.com>
Sent: Sun, March 7, 2010 1:04:57 PM
Subject: [fubumvc] Form validation and conditional redirects

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To post to this group, send email to fubumv...@googlegroups.com.
To unsubscribe from this group, send email to fubumvc-devel+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.

[Garry Shutler]

I understand point 2, but transferring in these cases would overwrite model.Username with the saved value, not the attempted one.

How do I set the model to render before telling Fubu to continue with the rest of the chain? I was looking at IFubuRequest.Set(T) which Fubu does with the result of the action, but it looks like that will be overwritten by whatever the action returns.

Garry Shutler

http://blog.robustsoftware.co.uk
http://twitter.com/gshutler

To unsubscribe from this group, send email to fubumvc-deve...@googlegroups.com.

[Jeremy D. Miller]

So just send the "attempted values" as part of the model you send into FubuContinuation.Transfer( input model ).  If you *really* wanted to, you could always reconstitute the original input model from scratch by calling directly to IObjectResolver.

    FubuContinuation Post(UserViewModel model)

    {
        if (IsValid(model))
        {
            // update user and save, etc

            return FubuContinuation.Redirect(   to whatever the next page is  );
        }

        return new FubuContinuation.Transfer( new UserInputModel{ OriginalValues = model });
    }

    SomeOutputModel Edit(UserInputModel inputModel){

      // do whatever
    }

IFubuRequest.Set(T) blows away whatever happened to be there before, but I'm not sure why you'd ever be doing that.

Looking at your OR example, I don't see how FubuContinuation works any differently here.

 

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: Garry Shutler <ga...@robustsoftware.co.uk>

To: fubumv...@googlegroups.com
Sent: Sun, March 7, 2010 1:44:43 PM
Subject: Re: [fubumvc] Form validation and conditional redirects

[Garry Shutler]

OR isn't doing anything after the OperationResult.OK is returned, it just takes the ResponseResource and works out how to render it. It is the same as the MVC example in behaviour as far as that is concern; it's not re-entering the pipeline (OR chain equivalent) in any way.

Garry Shutler

http://blog.robustsoftware.co.uk
http://twitter.com/gshutler

[Garry Shutler]

To put it perhaps a little clearer, when you return a POCO from an operation/action in OpenRasta it ends up being set as the ResponseResource property of an OperationResult.OK. It's just a conventional shortcut for doing it.

Garry Shutler

http://blog.robustsoftware.co.uk
http://twitter.com/gshutler

[Jeremy D. Miller]

What part is it that you're missing then?  Is it just what happens after you return the FubuContinuation?

It's really the same deal as the OR sample you showed.  You return what you want rendered in the FubuContinuation and off it goes.  There's nothing else you need to do to handle the FubuContinuation.  Fubu has an intrinsic convention that automatically puts a behavior behind the Action that returns FubuContinuation to handle all the machinery of what to do next.  All you have to do is just return the FubuContinuation.  The second handler can invoke the proper partial to continue on.  You don't even have to see the second handler.

"Re-entering the pipeline" isn't accurate for Fubu.  The FubuContinuation handler just goes to the underlying container and gets the 2nd set of behaviors it needs to render whatever the model is that you passed along in the FubuContinuation and executes those behaviors.  The behaviors for the "what do I do next" don't even exist until you ask for them.  Fubu doesn't use a bunch of singletons with the weird workflow code like OR does.  It does NOT reenter the Http pipeline or start a new nested container or blow away any of the request data.

 

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: Garry Shutler <ga...@robustsoftware.co.uk>
To: fubumv...@googlegroups.com

Sent: Sun, March 7, 2010 2:27:39 PM

[Garry Shutler]

I don't see how it's the same deal. Fubu calls a second action, OR is done after the first one in the same way MVC is.

I can't see how this isn't going to end up with additional code either for storing attempted values or checking whether you're coming into the Query action fresh or via a Command action.

I still don't understand why this approach has been taken, I'll have to give it some extra thought.

Garry Shutler

http://blog.robustsoftware.co.uk
http://twitter.com/gshutler

[Jeremy D. Miller]

I don't see how it's the same deal. Fubu calls a second action, OR is done after the first one in the same way MVC is.  -- So what?  Fubu doesn't need to enforce the strict 1 action 1 route thing like MVC.  My vision is that you *only* do whatever it is you need to decide whether or not to go left or right in the action that returns a FubuContinuation, then get out of there and let the framework figure out what to do next.

I can't see how this isn't going to end up with additional code either for storing attempted values or checking whether you're coming into the Query action fresh or via a Command action. -- I don't yet see why you think it would.  I think you're overcomplicating what's going on here. 

I still don't understand why this approach has been taken, I'll have to give it some extra thought. -- Where's the question really coming from?  In terms of usage, it's about as simple as it could possibly be.  In terms of implementation, shrug.  Give me a better way. 


If your only real goal is just to say "I like OR's way better (because that's what I already understand)" , then all you get from me is a shrug.

 

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: Garry Shutler <ga...@robustsoftware.co.uk>
To: fubumv...@googlegroups.com

Sent: Sun, March 7, 2010 2:53:57 PM

[Garry Shutler]

Ok, getting bored of you guys thinking I'm on some sort of attack here.

Forget any mention of OR at all. I don't care how OR does it, it's irrelevant as it's mechanically the same way as MVC does it at the action level.

Here's the basic question I can't get my head around: why is calling two actions to do something simpler than doing it in one? Having it as an option is pretty cool but I can't see why it would be the only way.

I've already decided in my action I just want to display the view again with the passed model. Why can't I just do that? Why do I have to transfer through another method? What benefit is that giving me?

Garry Shutler

http://blog.robustsoftware.co.uk
http://twitter.com/gshutler

[Jeremy D. Miller]

Ok, 3 options for you then (and this isn't really the scenario I was thinking for FubuContinuation anyway):

1. Return FubuContinuation.Transfer( the model you want shown ), and it goes right to the view w/ no second action getting put in there.  I need a bit of work to get there to the "Inferred Action" / view w/o a corresponding action, but that's on the plate anyway.  I need to add some conventional and explicit configuration to add behavior chains with no ActionCall, but there's absolutely nothing in the Fubu runtime model that forces you to have one in the first place.

2.) We could go back to the ISupportOverride model, but I hate that.  Too weird, too much indirection.  I like having the action return the FubuContinuation because it makes it obvious that there's a possible split in the workflow. 

3.)  If it's strictly for the Crud scenorio of "go forward if valid", just have a convention in Fubu that puts a behavior in front of every action that would need to be validated that redirects or continues to the basic action/view/output/whatever chain if it's valid or does the redirect for you if it's invalid.  If you're doing a lot of this kind of stuff, that might be worth the extra complexity to avoid the repetitive coding.


We do all of our form submissions w/ Ajax, so we never have to deal with this scenario.

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: Garry Shutler <ga...@robustsoftware.co.uk>
To: fubumv...@googlegroups.com

Sent: Sun, March 7, 2010 3:17:54 PM

[Chad Myers]

We do have this at least one place in Dovetail: The login action and it's an ugly beast for this very reason (valid-and-redirect or invalid-and-show-the-form-again).

The ISupportResultOverride thing was a hack and, for this purpose, FubuContinuation feels like a hack also.  I think they feel like hacks because I've always felt that actions shouldn't be making these kinds of decisions. The "Big If" in the middle of the action just seems to violate MVC and everything Fubu is about.

So I propose that this scenario  (valid-and-go or invalid-and-show-the-form-again) is common/important enough, there should be some first class support for it in Fubu.

How about if you could somehow designate a route as one of these special scenarios and you get three actions:  

1.) An action for rendering the form (with or without initial input)

2.) A validation action (or you could somehow use built-in Fubu validation or something) that validates the input in a POST scenario

3.) An action to run in the event the validation is successful (either a redirect to another route, or an action to execute that renders a view).

When you GET the route, you get Action #1.  When you POST,  #2 executes and either sends it automatically to #1 (if validation fails) or to #3 (if validation succeeds).

This way you can do the "post-back" style from ASP and ASP.NET WebForms, or you can do the POST-and-redirect style (to avoid the browser warning "This page was the result of a FORM DATA post blah blah" when refreshing the page).

Perhaps the class ("controller" though I hate that word) could implement IPostCycleAction or something

public interface IPostActionCycle<TInputModel, TFormModel>

{

     bool ValidateRequest(TInputModel inputModel);

     TFormModel Form(TInputModel inputModel);

     FubuContinuation FormSuccess(TInputModel inputModel)
}

I'm not sure about that "FormSuccess" method returning a FubuContinuation. Perhaps that method shouldn't exist and when you configure it you tell FubuRegistry what to do, like:

PostCycleFor<LoginPostCycle>().RedirectsOnSuccessTo<SomeOtherInputModel>();

or

PostCycleFor<LoginPostCycle>().ExecutesOnSuccess<SomeOtherInputModel>()

Garry, Jeremy, anyone: Thoughts?

-Chad

[Jeremy D. Miller]

I'm permanently ix-naying the ISupportResultOverride thing.  Your solution would work, but maybe we could go with a more general approach to avoid the object template.  I'm not comfortable with baking in the validate, then one way, then another into the framework because we could never possibly come up with a template that works generally w/o compromise.

How about a slightly different model for the redirection. 

Return this from your methods to declare that the action *might* force a redirect but otherwise flows down the normal pipeline:

public class Redirectable<T>{
  public static Redirectable<T> Continue(T model){ // stuff }
  // other methods for redirects and transfers

  public T Model {get;private set;}
  public FubuContinuation Redirect{get; private set;}
}

Make it be like a Nullable<T>.  For the purposes of the view attachment and resolution, we could treat it the same as an action that returns T.  It would still be using the FubuContinuation code behind the scenes.  I'm saying of "T" and not returning a general

 
There are still other scenarios (mobile comes to mind) where we want to keep the FubuContinuation model.

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: Chad Myers <chad....@gmail.com>
To: fubumv...@googlegroups.com
Sent: Sun, March 7, 2010 3:51:48 PM

[Garry Shutler]

Yeah, Joshua mentioned you guys do everything via ajax which is why this scenario hasn't raised it's head before.

I agree on your second point. Having a method returning a FubuContinuation / ActionResult / OperationResult rather than a specific type is a nice way of saying "look more than one type of result might be coming out the other end here". Much more transparent.

Whether you want to alter the behaviour of the current Transfer method rather than add an additional one is a call for yourselves. What you are suggesting seems to fit the bill though.

Your third point is probably where you would end up if you wanted to rely heavily on conventions. This would probably be where I would eventually end up but I would like the option to start off with the stepping stone of your first point before making the leap (as no doubt other people who are new to the framework would). Again, that's your call.

I'm going to mention something in OpenRasta. It's just an approach that might be worth considering:

Poking yesterday around I saw that it appears you currently determine the view to render based on the return type of method being invoked. OR determines the view to render based on the type of the object returned from the method, subtle difference but can be quite powerful. It also leads to (what I think is) a greater separation between the processing of a request and the rendering of it. It's undoubtedly more complicated though so there's a balance to be struck.

Thanks for your time, I'm hitting the sack now so won't be replying for about 9 hours.

Garry Shutler

http://blog.robustsoftware.co.uk
http://twitter.com/gshutler

[Garry Shutler]

Just seen Chad's response and another post from Jeremy came in while I was writing mine. Will review in the morning with extra feedback if applicable.

Garry Shutler

http://blog.robustsoftware.co.uk
http://twitter.com/gshutler

[Adam Schroder]

I had this very same question and was answered very succinctly by
nieve just 12 hours ago. Checkout this blog post. It will explain all.

http://notesdotnet.wordpress.com/2010/03/06/redirecting-in-fubu/

it's a different way of approaching but seems like it will work fine.

Adam

On Monday, March 8, 2010, Garry Shutler <ga...@robustsoftware.co.uk> wrote:
> Just seen Chad's response and another post from Jeremy came in while I was writing mine. Will review in the morning with extra feedback if applicable.Garry Shutler

>
> http://blog.robustsoftware.co.uk
> http://twitter.com/gshutler
>
>
> On 7 March 2010 22:10, Garry Shutler <ga...@robustsoftware.co.uk> wrote:
>
> Yeah, Joshua mentioned you guys do everything via ajax which is why this scenario hasn't raised it's head before.
> I agree on your second point. Having a method returning a FubuContinuation / ActionResult / OperationResult rather than a specific type is a nice way of saying "look more than one type of result might be coming out the other end here". Much more transparent.
>
>
> Whether you want to alter the behaviour of the current Transfer method rather than add an additional one is a call for yourselves. What you are suggesting seems to fit the bill though.
>
>
> Your third point is probably where you would end up if you wanted to rely heavily on conventions. This would probably be where I would eventually end up but I would like the option to start off with the stepping stone of your first point before making the leap (as no doubt other people who are new to the framework would). Again, that's your call.
>
>
> I'm going to mention something in OpenRasta. It's just an approach that might be worth considering:
> Poking yesterday around I saw that it appears you currently determine the view to render based on the return type of method being invoked. OR determines the view to render based on the type of the object returned from the method, subtle difference but can be quite powerful. It also leads to (what I think is) a greater separation between the processing of a request and the rendering of it. It's undoubtedly more complicated though so there's a balance to be struck.
>
>

> Thanks for your time, I'm hitting the sack now so won't be replying for about 9 hours.Garry Shutler

>
> http://blog.robustsoftware.co.uk
> http://twitter.com/gshutler
>
>
> On 7 March 2010 21:32, Jeremy D. Miller <jeremy...@yahoo.com> wrote:
>
> Ok, 3 options for you then (and this isn't really the scenario I was thinking for FubuContinuation anyway):
>
> 1. Return FubuContinuation.Transfer( the model you want shown ), and it goes right to the view w/ no second action getting put in there.  I need a bit of work to get there to the "Inferred Action" / view w/o a corresponding action, but that's on the plate anyway.  I need to add some conventional and explicit configuration to add behavior chains with no ActionCall, but there's absolutely nothing in the Fubu runtime model that forces you to have one in the first place.
>
> 2.) We could go back to the ISupportOverride model, but I hate that.  Too weird, too much indirection.  I like having the action return the FubuContinuation because it makes it obvious that
> there's a possible split in the workflow.
>
> 3.)  If it's strictly for the Crud scenorio of "go forward if valid", just have a convention in Fubu that puts a behavior in front of every action that would need to be validated that redirects or continues to the basic action/view/output/whatever chain if it's valid or does the redirect for you if it's invalid.  If you're doing a lot of this kind of stuff, that might be worth the extra complexity to avoid the repetitive coding.
>
>
> We do all of our form submissions w/ Ajax, so we never have to deal with this scenario.
>
>
> Jeremy D. Miller

> The Shade Tree Developer <http://codebetter.com/blogs/jeremy.miller>
> jeremy...@yahoo.com

[SerialSeb]

> "Re-entering the pipeline" isn't accurate for Fubu.  The FubuContinuation handler just goes to the underlying container and gets the 2nd set of behaviors it needs to render whatever the model is that you passed along in the FubuContinuation and executes those behaviors.  The behaviors for the "what do I do next" don't even exist until you ask for them.  Fubu doesn't use a bunch of singletons with the weird workflow code like OR does.  It does NOT reenter the Http pipeline or start a new nested container or blow away any of the request data.

Just to clarify what OpenRasta actually does and does not do...

OpenRasta has a reentrant pipeline in only one scenario, which is the
one where the system itself trips over, and we still want to do
content negotiation on the resulting error. It's a corner case that
exists as a fail safe.

As for the "weird workflow" code you talk about, not sure what you
refer to. I assume it's the ordering of pipeline contributors within a
pipeline. I believe you guys use a policy to inject your behaviors at
known points by doing it yourself, OR uses a fluent api to give
ordering guarantee to components, and platform-level known stages that
are guaranteed to exist for people not to trip over themselves by
taking on too many expectations.

Starting nested container scopes is only done when the system wants to
execute sub-requests, as opposed to simply execute other operations
within the same context, for server-side aggregation of content.

But as you say, because of some defaults that existed in RC, we have a
lot of singletons, which makes reexecuting a new pipeline on a new
resource a bit bad. This is corrected in RTM, so you can simply ask
for the IPipeline, and call one of the extension methods to execute
whatever you want on wahtever new input data you have found, and get /
replace the result...

Seb

[Garry Shutler]

For what it's worth Jeremy's Redirectable<T> sounds a good solution. I would echo his reservations about Chad's suggestion, not that it's a bad idea but it forces a bit more on the developer. Redirectable<T> would probably play a bit nicer with a conventional behaviour too.

I've tried to think of other scenarios there might be so you don't end up with RedirectableAndBlahable<T> and an explosion of combinations but at the moment I can't think of any. At least not any I use on a regular basis.

Garry Shutler

http://blog.robustsoftware.co.uk
http://twitter.com/gshutler

[Nieve .]

Just one last question:
I've seen on Joshua's blog (AFAIR) a few posts in which he describes the way things are done with ajax/json to solve these sort of situations, and now after reading that you guys stick to this solution, I would like to know what is the benefit in comparison to the Continuation/Redirect option you've discussed here? Apart of the obvious user experience that is. Is it also easier to code/maintain/refactor/reduces repeats or what have you..?

We're doing things (working with MSMVC) only by redirecting / returning the current view on validation/failures of edits and creates, and I remember seeing that post by HAACK (http://haacked.com/archive/2010/01/01/jquery-undoable-plugin.aspx) and feeling really gutted for having done things the way we did/still do...

nieve

[jdc]

Seeing how Nieve did it, it looks pretty simple to me. You might get
duplication between actions, but isn't this exactly the kind of code
that's supposed to go in your controllers anyway? If we genericize to
the point that all of the actions are one liners, then you'll end up
with no actions at all. Not necessarily a bad thing (just configure
everything conventionally up front and create a bunch of input/output
classes) but would be significantly different than how we're all used
to doing things so far.

On Mar 7, 4:54 pm, Adam Schroder <adamschro...@gmail.com> wrote:
> I had this very same question and was answered very succinctly by
> nieve just 12 hours ago. Checkout this blog post. It will explain all.
>
> http://notesdotnet.wordpress.com/2010/03/06/redirecting-in-fubu/
>
> it's a different way of approaching but seems like it will work fine.
>
> Adam
>
>
>
> On Monday, March 8, 2010, Garry Shutler <ga...@robustsoftware.co.uk> wrote:
> > Just seen Chad's response and another post from Jeremy came in while I was writing mine. Will review in the morning with extra feedback if applicable.Garry Shutler
>
> >http://blog.robustsoftware.co.uk
> >http://twitter.com/gshutler
>
> > On 7 March 2010 22:10, Garry Shutler <ga...@robustsoftware.co.uk> wrote:
>
> > Yeah, Joshua mentioned you guys do everything via ajax which is why this scenario hasn't raised it's head before.
> > I agree on your second point. Having a method returning a FubuContinuation / ActionResult / OperationResult rather than a specific type is a nice way of saying "look more than one type of result might be coming out the other end here". Much more transparent.
>
> > Whether you want to alter the behaviour of the current Transfer method rather than add an additional one is a call for yourselves. What you are suggesting seems to fit the bill though.
>
> > Your third point is probably where you would end up if you wanted to rely heavily on conventions. This would probably be where I would eventually end up but I would like the option to start off with the stepping stone of your first point before making the leap (as no doubt other people who are new to the framework would). Again, that's your call.
>
> > I'm going to mention something in OpenRasta. It's just an approach that might be worth considering:
> > Poking yesterday around I saw that it appears you currently determine the view to render based on the return type of method being invoked. OR determines the view to render based on the type of the object returned from the method, subtle difference but can be quite powerful. It also leads to (what I think is) a greater separation between the processing of a request and the rendering of it. It's undoubtedly more complicated though so there's a balance to be struck.
>
> > Thanks for your time, I'm hitting the sack now so won't be replying for about 9 hours.Garry Shutler
>
> >http://blog.robustsoftware.co.uk
> >http://twitter.com/gshutler
>

> > On 7 March 2010 21:32, Jeremy D. Miller <jeremydmil...@yahoo.com> wrote:
>
> > Ok, 3 options for you then (and this isn't really the scenario I was thinking for FubuContinuation anyway):
>
> > 1. Return FubuContinuation.Transfer( the model you want shown ), and it goes right to the view w/ no second action getting put in there.  I need a bit of work to get there to the "Inferred Action" / view w/o a corresponding action, but that's on the plate anyway.  I need to add some conventional and explicit configuration to add behavior chains with no ActionCall, but there's absolutely nothing in the Fubu runtime model that forces you to have one in the first place.
>
> > 2.) We could go back to the ISupportOverride model, but I hate that.  Too weird, too much indirection.  I like having the action return the FubuContinuation because it makes it obvious that
> >  there's a possible split in the workflow.
>
> > 3.)  If it's strictly for the Crud scenorio of "go forward if valid", just have a convention in Fubu that puts a behavior in front of every action that would need to be validated that redirects or continues to the basic action/view/output/whatever chain if it's valid or does the redirect for you if it's invalid.  If you're doing a lot of this kind of stuff, that might be worth the extra complexity to avoid the repetitive coding.
>
> > We do all of our form submissions w/ Ajax, so we never have to deal with this scenario.
>
> > Jeremy D. Miller
> > The Shade Tree Developer <http://codebetter.com/blogs/jeremy.miller>

> > jeremydmil...@yahoo.com

>
> > From: Garry Shutler <ga...@robustsoftware.co.uk>
> > To: fubumvc-de...@googlegroups.c
>
> > --
> > You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
> > To post to this group, send email to fubumv...@googlegroups.com.
> > To unsubscribe from this group, send email to fubumvc-deve...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/fubumvc-devel?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Nieve .]

Just to get a few things clear-
AFAIC, the way I did things was just to see how things *could* be done; Not only, as Garry said, does passing through two actions can be redundant, but also (and I remember noticing it when I wrote the code) it may force you to have logic in your GET action that takes care of handling the situation after the POST action, which breaks the separation of concern (an action for handling POSTs and one for GETs).

And again, if anyone can talk a bit more on the why should you prefer ajax/json on Redirecting/Displaying failures messages, I'd be more than grateful :)

nieve