Can anybody share how they're using FubuContinuation?

[Jeremy Miller]

We (Dovetail) don't use enough conditional handling to really push the
FubuContinuation usage, but it's a common source of questions. Could
some of you who are using FubuContinuation in anger share what you're
using it for so I can get some feedback?

Thanks,

Jeremy

[Mike O'Brien]

I've been using it to redirect after an add/edit/delete. I've also been using it to transfer back to the query action if there was an error.

public OutputModel Query(OutputModel output)

{

    return output;

}

        

public FubuContinuation Command(InputModel input)

{

    try

    {

        // Try doing something

    }

    catch (DuplicateFubarException)

    {

            var output = new OutputModel

                {

                    Name = input.Name,

                    Message = "Srry chief, there was a duplicate fubar."

                };

            return FubuContinuation.TransferTo(output);

        }

    }

    return FubuContinuation.RedirectTo<QueryHandler>(x => x.Query());

}

I have no idea if this is the way I should be doing it.

--
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 at http://groups.google.com/group/fubumvc-devel?hl=en.

[Michael Murray]

We do basically the same thing for POSTs and GETs on form submission scenarios. We also use IContinuationDirector in our behavior chains when we want to stop the chain and transfer or redirect before getting to the controller action.

[Mike O'Brien]

Interesting, I'll have to check that out. I've just been using IOutputWriter.RedurectToUrl() but that takes a string url.

[Michael Murray]

Actually, IContinuationDirector is not registered in StructureMap by default. There is one implementation of that interface in the Fubu codebase, ContinuationHandler, which you can bring in as a constructor argument and StructureMap will provide you that class. Unfortunately, when you have diagnostics on and because it inherits from BasicBehavior, it will become wrapped by a BehaviorTracer node and then will throw exceptions when it attempts to pass it to your constructor because of the type mismatch. Bob described the issue in full detail and what line is causing the wrapping with BehaviorTracer in this discussion thread:

https://groups.google.com/forum/#!topic/fubumvc-devel/HGszR5l0WUw

Bob had some ideas on how to fix it and suggested putting together a pull request, but the issue went silent and it appears we put together our own work around in the meantime. 

The workaround we came up with was to put together another implementation of IContinuationDirector called ContinuationDirector that had all of the same implementation of ContinutationHandler, but didn't inherit from BasicBehavior. We left InvokeNextBehavior blank, since we weren't going to be using this new implementation as a proper behavior node in the chain. We just wanted the ability to transfer and redirect by model types and have the dependency be passed in by constructor injection. The last step was to wire up our new implementation as the return of asking StructureMap for IContinuationDirector.

So yeah, there you go; hope that more clearly describes what I meant by that statement. We welcome any feedback.

[Mike O'Brien]

Ok, thanks for the explanation. 

[Rex Morgan]

I use it for POSTing, for example, after a user posts changes, I redirect them to the edit page for that item, or back to their dashboard, etc.

I also use it for something I called a "FrontLoaderEndpoint" which will decide where a request needs to go based on the HTTP_HOST. So I can redirect users to their personal section of the site if the url is like {username}.domain.com and show the homepage if the url is just domain.com.

[Mike Murray]

Jeremy, I thought of another use of FubuContinuation that we did. But we felt some friction with returning FubuContinuation from our action method, and being locked into every code path of the controller action being some type of continuation action (transfer, redirect, etc.).

We had a controller action that needed to either transfer to another route or continue and return the view model for rendering the associated view. However, you can't really return FubuContinuation and the view model type from the same method. So we ended up abusing FubuContinuation a bit (in my opinion) and always transferring to one of two routes. The controller action tied to the one route intended to handle the "continue and return the view model" use case became a trivial implementation; it was noisy and felt like we were fighting the framework.

We just remembered that there is a pending pull request for a Redirectable implementation that from a cursory look seems it may do the trick. In looking at the implementation, it appears to be what we were thinking about putting together, some kind of view model type and FubuContinuation pair. I'll be trying it out over the weekend to make sure it's what we need. It's now a pretty old pull request; would it help to have these changes were rebased to the current codebase? Are there any hangups with this particular implementation? Or is it just a pull request you've been meaning to get to?

Your comments and/or concerns are appreciated.

[Adam Schröder]

Can the return type just be object so you can return either a viewmodel or a FubuContinuation depending on the logic?

--

You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.

To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/PRRS44ExRiYJ.

[ahjohannessen]

We don't use FubuContinuation very much. In one app we follow a "Query" and "Command" pattern and use a "statemachine" (inside a GoForwardBehavior) to keep track of where to go next. So the commands don't have responsibility to know where to go next - that is a configuration matter.

[Adam Schröder]

Have you got a small example of this @ahjoannessen? Sounds interesting.

On Sat, Jul 16, 2011 at 11:18 PM, ahjohannessen <ahjoha...@gmail.com> wrote:

We don't use FubuContinuation very much. In one app we follow a "Query" and "Command" pattern and use a "statemachine" (inside a GoForwardBehavior) to keep track of where to go next. So the commands don't have responsibility to know where to go next - that is a configuration matter.

--

You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.

To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/UbP6kX2dxUwJ.

[Chad Myers]

Struts had this and it was pretty cool for the 80% case simple stuff, but it was static defined through XML (Java, of course) and it was a nightmare for anything complex.

But I've always thought the pattern could work if it were more dynamic like what you describe.  I wonder if we should evolve this a little more and bake it into Fubu as a pattern ppl could follow.

Chad

[ahjohannessen]

@Schotime - I can try to see if I can dig something up.


@Chad I think it would be awesome if we somehow could "connect endpoints" as state machines through FubuRegistry in a general way that all of us could take advantage of.

[Mike Murray]

@Schotime: It's an interesting thought; we do something similar for routes that return JSON by having the return type be dynamic and then having a convention that will JSONify the object and send it down on the response. However, I'm not so sure that returning Object will help in the case I've described above because of view location. With the old Spark View Engine bits, it for sure wouldn't have worked; but the new Spark integration depends on the view specifying the type of view model it can render, so it could possibly work. On the other hand, I suppose you could lose some code readability by returning Object.

[ahjohannessen]

@Chad not necessarily "state machines" but something that could function as some sort of a navigation graph. I assume many people need something like this, be it for wizards, application navigation and so on..

[ahjohannessen]

The phrase "viewmodel or a FubuContinuation" makes me wonder if the action is having too much responsibility a la "in ms mvc actions know what view to return etc". I think this can be solved by policy and behavior, or some other orchestration.

[Mike Murray]

I disagree. Sometimes you want to detect a certain case and transfer somewhere else for a particular route. To make a behavior for this purpose for just one unique route seems like overkill. I have used this technique before however and it works fine, but I don't really need a reusable behavior node that contains such specific logic to just one route in the entire system. I don't think it's too much responsibility to detect one border case and redirect, and otherwise continue the normal path to the view model creation and view rendering. I like the idea of Redirectable for these type of use cases.

I do agree with the MS MVC returning ActionResult comment though, and definitely wouldn't encourage heading that direction.

[ahjohannessen]

@Mike I can follow you with that comment, I have also used continuation in some edge cases - What I question is whether an action should generally be in control of "where to go next" - Some built-in stuff in fubu for this would not require you to make a new behavior for this "one-off" scenario.

[ahjohannessen]

@Mike

"Sometimes you want to detect a certain case and transfer somewhere else for a particular route."

Is the detection not something that you would delegate to an "orchestration" part? Or, why should an action know anything about where to redirect to?

I agree to some extend that creating a new behavior for each edge case is overkill - Would it be smarter if there was some built-in support for this kind of scenario?

[Jeremy D. Miller]

Sorry I'm coming into this late, but the entire purpose of putting FubuContinuation into FubuMVC was so that you had a one-off orchestration mechanism for branching route handling.  An action returning FubuContinuation *is* the orchestration piece.  In that case, you are using the action to play the Controller stereotype in the Wirfs-Brock sense (not in the MSMVC / Monorail inherit this gigantic base class way) to fulfill a cohesive responsibility for determining "what should I do next"
 

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

---

From: ahjohannessen <ahjoha...@gmail.com>
To: fubumv...@googlegroups.com
Sent: Sat, July 16, 2011 10:20:39 AM
Subject: Re: [fubumvc] Re: Can anybody share how they're using FubuContinuation?

--

You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.

To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/7XhXm3on2PcJ.

[ahjohannessen]

Yep, I understand that. What I am wondering is that we might be able to get away with "fubu continuation" as the orchestration piece if we have this part moved to a behavior + configuration setup.

[Mike Murray]

@Jeremy: Did you see the comments earlier in this thread about the pending Redirectable pull request? Before I go off and use it, I just want to make sure there isn't some reason to steer clear of it or if there's some reason it has never been pulled in yet.

@Alex: I'm not sure I understand the purpose of trying to build conventions and configurations around one-off scenarios. It defeats the purposes of conventions, which are to help with reuse of behavior/code around some aspect of the type or its properties being consistent to some made up rule you can enforce.

[ahjohannessen]

@Mike I am not saying this is a convention but rather a configuration aspect - I still fail to understand why an action should be responsible of dictating where to go next. That can be done through configuration that enables IoC for decision making. I think the general issue boils down to whether actions should be in control of "where to go next". I don't think it is necessary if you have a way to do that via configuration.

[jmarnold]

Sorry for the delay, guys. We've got our baby shower going so I don't
have time to contribute to this conversation right now but I've got
some ideas brewing in the back of my mind. I promise I'll get to it
tonight and give my 2 cents.

[ahjohannessen]

I guess FubuContinuation is convenient for simple one-offs - like for login.

However looking at it from a broader perspective I think being able to set up "navigation graphs" would be *really* cool.

- Via DSL ability to apply convention.

- For instance, if output model has "Next" and/or "Previous" on it then this could be model bound by way of the navigation graph semantic model.

- ActionCall (or input type + category) could function as a "state" in a statemachine.

- We can have a Director concept (like a transition function) with a default one that does not consider branching (a director behavior that gets injected a director). However, we can overrule and register a specific director for a group of actions, for instance - and this guy can operate on CommandResult or whatever you choose + get IoC for decision making.

That would make fubumvc even cooler :) it is somewhat similar to HATEOAS ( http://timelessrepo.com/haters-gonna-hateoas )

[Mike Murray]

Just to follow up...I've tried out the Redirectable pull request and it works pretty great for that occasional one-off scenario. I did have to merge the pull request a bit to make it work since it was so old, so it might be worth me reissuing the pull request from my codebase if it is something we want into master. I wouldn't be surprised if Jeremy is asking because he has other plans for FubuContinuation though. :) I guess I'm trying to get a feel for if I should go to the effort or not, though it's basically there now and the pull request would just be a formality at this point for getting it into master.

[alistairc]

Hi,

We had a bit of strange use case that has stopped working with recent
Fubu builds. I've worked around it, but maybe it should be supported?

We've got a NavigationBar partial that is included at the top of every
page (in a master page). We want to display two different views
depending on whether the user is logged in or not, so the action
Transfers to one of two other actions, which return different model
types.

It seems like the FubuContuation doesn't work for a partial in the
current build, but I think we might have been abusing it a bit anyway!

Thanks
Alistair

[Martin Larsen]

I did the Redirectable implementation half a year back or something like that and we use it ourself without problems. We're a couple of months behind Fubu so that's the reason why I haven't rebased the pull request. 

I don't know we it haven't been applied - I guess Jeremy's been to busy with more important things. It doesn't scratch their itch as can be seen from his posts initiatin this thread. On the other hand I haven't really pushed it myself.

But the patch should be okay. We use it with good results and it really simplified some of our code. There might be some truth in that using it usually is a violation of SRP - but on the other hand it is a nice pragmatic solution which does the job easily. 

- Martin