Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mike Murray
    @mkmurray
    Impressed with how Glimpse has progressed as a diagnostic tool. I feel like we could benefit from complimenting the data and context it provides with what we've done with diagnostics specific to Fubu. If the extensibility story is mature enough, how do others feel about FubuDiagnostics becoming largely a plugin for Glimpse?
    Jeremy D. Miller
    @jeremydmiller
    Mike, if you wanna take that on, start by looking into their OWIN integration. Next thing would be to figure out how to integrate fubu/jasper’s nested container lifecycle w/ their model so you can get the request tracing working
    Mike Murray
    @mkmurray
    You definitely have the voice of experience on this matter; those are both things that would have to be worked out in order for this idea to be successful
    Jeremy D. Miller
    @jeremydmiller
    @mkmurray I looked at what they have documented here: http://getglimpse.com/Extensions. It’s the same model I thought was inadequate 2 years ago and their OWIN support isn’t yet released as far as I can tell. I think it’s going to be much more bang for the buck to run Glimpse in parallel w/ the existing fubu diagnostics
    Mike Murray
    @mkmurray
    I see, yeah I haven’t had a chance to research myself yet…thanks
    Ron Lloyd
    @rlloyd2001
    public class ApplyAjaxContinuationErrorHandling : IConfigurationAction
    {
        public void Configure(BehaviorGraph graph)
        {
            graph
                .Behaviors
                .OfType<RoutedChain>()
                .Where(routedChain => routedChain.ResourceType().CanBeCastTo<AjaxContinuation>())
                .Each(routedChain => routedChain.InsertFirst(Wrapper.For<AjaxContinuationErrorBehavior>()));
        }
    }
    Question on behavoirs.
    in fubu
    • [0] {FubuMVC.Core.Diagnostics.Runtime.DiagnosticNode} FubuMVC.Core.Registration.Nodes.BehaviorNode {FubuMVC.Core.Diagnostics.Runtime.DiagnosticNode}
    • 1 {FubuMVC.Core.Diagnostics.Runtime.BehaviorTracerNode} FubuMVC.Core.Registration.Nodes.BehaviorNode {FubuMVC.Core.Diagnostics.Runtime.BehaviorTracerNode}
    • 2 {Wrapped by ExtendHealth.OneExchange.Infrastructure.AjaxContinuationErrorBehavior} FubuMVC.Core.Registration.Nodes.BehaviorNode {FubuMVC.Core.Registration.Nodes.Wrapper}
    • 3 {FubuMVC.Core.Diagnostics.Runtime.BehaviorTracerNode} FubuMVC.Core.Registration.Nodes.BehaviorNode {FubuMVC.Core.Diagnostics.Runtime.BehaviorTracerNode}
    • [4] {Wrapped by FubuMVC.RavenDb.TransactionalBehavior} FubuMVC.Core.Registration.Nodes.BehaviorNode {FubuMVC.Core.Registration.Nodes.Wrapper}
    Even though 'InsertFirst' is configured for AjaxContinuationErrorBehavior, can a DiagnosticNod or BehaviorTracerNode still get inserted in front of that Behavior in the graph?
    Jeremy D. Miller
    @jeremydmiller
    @rlloyd2001 The diagnostic behaviors are inserted at the very last minute in the bootstrapping specifically to avoid problems with ordering rules. Or put another way, the behavior node ordering happens before the diagnostics are inserted into the chain.
    Ron Lloyd
    @rlloyd2001
    Here's the test that's failing for more context:
            var graph = BehaviorGraph.BuildFrom<TestRegistry>();
            var behavior = graph.Behaviors
                .First(x => x.IsWrappedBy(typeof(AjaxContinuationErrorBehavior)));
            behavior.First().BehaviorType.ShouldEqual(typeof(AjaxContinuationErrorBehavior));
    Jeremy D. Miller
    @jeremydmiller
    Sure, you just need to account for the diagnostic behaviors being there.
    Ron Lloyd
    @rlloyd2001
    Weird thing is this test passes on the CI.
    Jeremy D. Miller
    @jeremydmiller
    Remember that FubuMode thing we did yesterday on your box?
    Do this, in your test, force FubuMode to not be in development mode before you build the behavior graph
    Ron Lloyd
    @rlloyd2001
    I've done a git clean -dfx on a different branch that is passing on the CI and still same issue.
    Sounds good, I'll let you know if that fixes is.
    fixes it
    Ron Lloyd
    @rlloyd2001
            PackageRegistry.Properties.Remove(FubuMode.Development);
            var graph = BehaviorGraph.BuildFrom<TestRegistry>();
            var behavior = graph.Behaviors
                .First(x => x.IsWrappedBy(typeof(AjaxContinuationErrorBehavior)));
            behavior.First().BehaviorType.ShouldEqual(typeof(AjaxContinuationErrorBehavior));
    I'm trying that, but it's still not passing. What do you think about just ignoring those behaviors in the test?
    Jeremy D. Miller
    @jeremydmiller
    Use FubuMode Ron
    Ron Lloyd
    @rlloyd2001
            FubuMode.Mode("none");
            //PackageRegistry.Properties.Remove(FubuMode.Development);
            var graph = BehaviorGraph.BuildFrom<TestRegistry>();
            var behavior = graph.Behaviors
                .First(x => x.IsWrappedBy(typeof(AjaxContinuationErrorBehavior)));
            behavior.First().BehaviorType.ShouldEqual(typeof(AjaxContinuationErrorBehavior));
    This works...
    And actually FubuMode.Mode(""); works also...
    Jeremy D. Miller
    @jeremydmiller
    @CoreyKaylor @RyanHauert @jmarnold and everyone else, FubuMVC 3 work starts any day now. This is the preliminary roadmap for 3.0: https://docs.google.com/document/d/1pQLEJRYDNYiwJbEnkH5EGfyF3TTqldDpdTou3Pts6nc
    3.0 is meant to be a stepping stone to Jasper. It’s really an effort to make things easier to work with and get incremental improvements ready this summer before doing the bigger work to switch to the CoreCLR and the envisioned “Jasper” architecture.
    Ryan Hauert
    @RyanHauert
    @jeremydmiller Thanks! I’ll take a look at the roadmap.
    Jeremy D. Miller
    @jeremydmiller
    Alright, I’ll know if anybody is watching this room because it’s impossible not to have an opinion about what I’m going to say next;) —>
    How awful do y’all think it would be if FubuMVC.Core took a public dependency on Newtonsoft.Json? I’m going to have to take the dependency to pull Bottles & FubuMVC.Json into FubuMVC.Core anyway, but my thinking is that users could start to take advantage of Newtonsoft customizations if the dependency is public. The other option is to ilrepack the dependency into FubuMVC.Core. This does not have to be decided today by any means.
    Jeremy D. Miller
    @jeremydmiller
    btw, FubuMVC 3.0 work started this morning: https://github.com/DarthFubuMVC/fubumvc/tree/three
    Nothing but cleaning out old, to be discontinued features so far. If the day goes well, I might have Bottles effectively removed as a dependency in FubuMVC.Core.
    Andres Hernandez
    @andhernand
    I'm cool with adding it as a public dependency.
    Jeremy D. Miller
    @jeremydmiller
    @andhernand One of the things that came out of the work on your project and doing that is that I’m gonna recommend we cease all usage of Projections in favor if custom DTO’s, database projections, or JSON.Net serialization customizations
    Andres Hernandez
    @andhernand
    @jeremydmiller I've never been a huge fan of how we used Projections. Json.Net serialization customization would be a huge step in the right direction.
    The way we used Projections added unnecessary ceremony.
    Jeremy D. Miller
    @jeremydmiller
    @andhernand I built it originally to go from ADO data readers to json w/o bouncing through a DTO. And yeah, it looks ugly in usage.
    Colten Rouska
    @rizowski
    I would totally be in support of that. After hearing that projections were being used for variable transformations and that projections were not meant to be used in that fasion :+1: from me.
    Jeremy D. Miller
    @jeremydmiller
    The big 3.0 cleanup effort is going okay so far. See the last commit of the day: https://github.com/DarthFubuMVC/fubumvc/commits/three
    I’m removing a lot of obsolete/obsolescent stuff and getting pretty far in the effort to collapse a simplified version of Bottles directly into FubuMVC.Core
    Jeremy D. Miller
    @jeremydmiller
    @gbrunton wrote:
    "

    Not interested in it if it is complete framework that basically replaces MVC.
    Is interested in it if it is more of a library built on top of or works side by side with MVC.

    Would love to see

    • behavior chains (russian doll modelled)
    • one model in / one model out controllers
    • routes derived off of input models
    • automatic content negotiation (view discovery)
    • view editors and displays and the ability to apply html conventions
    • localization support (much like fubu did)
    • validation somewhat similar to what was attempted in fubuvalidation
    "
    Ok, so:
    Suhas Chatekar
    @schatekar
    @jeremydmiller tagging things as "up for grabs" is a good idea
    Jeremy D. Miller
    @jeremydmiller
    Right now, my thinking is that Jasper has to be in charge of routing, diagnostics, modularity, IoC integration, and the assembly of OWIN middleware/the BehaviorGraph to effectively do what we want to accomplish. I think we should commit to being able to use most of the MVC6 functionality within a Jasper application, and we’ll definitely support the usage of external OWIN middleware. So in a way, you could absolutely use Jasper all by itself as a whole other FX but still take advantage of MVC6 things. Jasper as an addon to MVC6 probably doesn’t work.
    • behavior chains / Russian doll model — definitely, but this time “behavior” will be the OWIN signature func
    • one model in / one model out controllers — agreed, but I think we need to support other patterns this time too