Ok, there seems to be a bit of misunderstanding of what I'm proposing, so 2nd try!
Imagine you have a webpage that requires you to show: - User name (logged on user) on the top right corner - A navigation on the left had side - A product in the middle (you looking at the product) - The shopping cart items on the right had side - The customer comments after the product - And finally purchasing history (of the current logged on user) You may have guessed, Yes I'm kind of talking about Amazon! Currently to implement this in Monorail you would have something like this in your action method: PropertyBag["username"] = GetUsername(); PropertyBag["navigation"] = GetNavigation(currentLocation) PropertyBag["product"] = GetProduct(id); PropertyBag["cart"] = GetShoppingCart(); PropertyBag["customerComments"] = GetCustomerComments(id); PropertyBag["purchasingHistory"] = GetHistory(); As you can see, a big mess! No separation of concerns! Yes I know you can use ViewComponents for eg navigation, but then you are adding complexity to your view. One good and clean way to separate each one of these concerns is to use ajax, so in this case we would have 6 ajax calls to MonoRail. Each one of these ajax calls would call an action and would render html in our website page, the advantage is also that they can run in parallel :) Much faster rendering a web page in this style. So what I'm proposing is pretty much what the ajax is doing, except we would be doing it all server side. So there would be 6 controller/action running in parallel and then everything would come together server side. Does this makes it more clear? Cheers John On Jan 23, 4:44 pm, Gauthier Segay <[email protected]> wrote: > Hi Jonathan, thanks for fueling the discussion, some points bellow > > > I think there is still a market for MonoRail, but is not going to be > > an easy ride! > > as for me, the code is not rusting, I agree that MSMVC has the masses > attention, but MR will live as long as it's user base and maintainers > keeps it moving forward. > > there are other .net web frameworks in various states of maturation > (bistro, fubu, ...), not a compeling reason for MR to fade away > because MS has a competing implementation. > > From my point of view (using MR since 2007) What would be interesting > is to leverage some parts of the ASP.MVC third part "market" if such > thing develop: I mean reusing some of the work done with typed form > helpers or other things. > > I don't know if it actually mean a really complex work now that > System.Web.Mvc bits are in the standard .net distribution, but that > would mean that most of the tutorial / samples talking about MS bits > would be transposable. > > routing engine abstraction supporting System.Web.Routing along side > with MR and other implementations would be a step in this direction. > > Thinking about how to leverage VS / MD tooling for MSMVC could also > enhance the end user experience, looking up with them integration > points would be huge (I think they done so with some parts choosing > unit test frameworks). > > > Our down point is in the doco/samples. > > As for documentation, I'm not sure if the goal is to have MRDN (MSDN > is great but style used in most sample could give me headaches), but I > agree that some clear sample tutorials using nested model binding of > request params in action signature, basic formhelper client automatic > validation would help the newcommers. > > The problem is not the lack of discoverability, to me the castle doc > site is ok, looking at the test coverage of the various parts allow to > learn a great deal. > > I agree that for further material there is some kind of inference > required because of the timespan theses bits were published (and the > evolution of MR and other parts API), but that would be the same in a > year or so for MSMVC. > > > And yes, I agree we will never be able to draw the masses of > > developers that ASP.NET MVC is able to, but hey do we really want > > that, I don't think so! > > +1, I think Ken (or someone else) made some statements about > opensource userbase and project healthyness > > > Hamilton just quickly mentioned the word on another thread, > > "Composition". > > +1, too bad for SmartDispatchController ;) > > > As far as I know at the moment no other .Net MVC framework has the > > concept of "Web page composition" server side. > > RenderAction idea came from actual MSMVC (google search lead to > article such > ashttp://blogs.intesoft.net/post/2009/02/renderaction-versus-renderpart...) > > I think the implementation is a way to circumvent viewcomponents (or > porting problem of the UserControl away from Webforms), and I'm not > sure it's the right abstraction in most cases, but that would surely > deserve it's purpose if technical implication is not huge. > > > The idea is simple, and I've already started looking at the source > > code to see what is involved in doing this. > > So my proposal is: > > - We change the routing to support the idea of "composite routing", so > > that we can tell the routing engine that we do not want to just > > execute one action/controller, but instead we want to execute > > multiple. > > - We then create a new HttpHandler that handles this by instead of > > instantiating only one controller and calling its action, it > > instantiates as many as were defined (this could be done sequential or > > in parallel or support both). > > - Once all action execute, we bring it all together into one single > > response. > > looking at pointed article and your description, I'm now unsure if > I've keep up with your idea. > > is the rendering and calling being arbitrated by the view markup or is > it something completely separated which purpose is to populate the > view data context? > > IMHO, first is best achieved via viewcomponents or using view engine > features (eg. spark have include with named typed parameters), second > is something I'm not sure I would like to use in a web context (just > me) > > > If we go this path we could also implement what ASP.NET MVC does > > where they only support one model per view(ViewModel) and get rid of > > the PropertyBag to pass data to the view. > > to me, using the dictionary adapter is as clean (and enforce I'm using > plain dto interface) and view model independant. > > if extending MR using ViewModel, we still need access to the plain > property bag, which is the case in MSMVC > > http://msdn.microsoft.com/en-us/library/system.web.mvc.viewdatadictio...http://msdn.microsoft.com/en-us/library/dd470798(loband).aspx > > Nitpicking on MS: what is sad in MSMVC API is that ViewPage<TModel> > doesn't implement a polymorph able signature that would help > abstracting and share things accross viewengine, as is this semantic > it is strictly bound to webform viewengine... > > Back to MR: I'm not sure of the implication on the viewengine > behaviour and API refactor required, it may require implementing some > semantics in the view engine to have that integrate nicely. > > Still unsure if this is a one size fit all problem > > I'm not in favor or against both of your propositions, I think looking > at MSMVC is required for the evolution, but there are also other > projects / ideas to seek. > > I'll try to add some suggestion in MR UV next time, all theses words > just made me think at a naughty thing about dynamic actions: > > this.DynamicActions["someaction"] = (enginecontext, controller, > controllercontext) => { do something } > or another one > this.DynamicActions["someaction"] = (FooForm form) => { do something > with idatabinder processed FooForm } > > On 23 jan, 04:19, John Simons <[email protected]> wrote: > > > I think there is still a market for MonoRail, but is not going to be > > an easy ride! > > We have learned a lot, from developing such a framework, and at the > > moment I have to say with confidence that in terms of features we are > > still ahead of the game in comparison to ASP.NET MVC. > > Our down point is in the doco/samples. > > And yes, I agree we will never be able to draw the masses of > > developers that ASP.NET MVC is able to, but hey do we really want > > that, I don't think so! > > > Regarding using ASP.NET MVC code base or extend it, my question is > > what for? What are we going to get from that, is not that we need it > > (we have already got the code written in MonoRail). > > > Hamilton just quickly mentioned the word on another thread, > > "Composition". > > As far as I know at the moment no other .Net MVC framework has the > > concept of "Web page composition" server side. > > The way developers are achieving this is by using Ajax to load > > sections of their web page, but this is done client side. > > My proposal is for us to change Monorail to do this on the server > > side. > > > The idea is simple, and I've already started looking at the source > > code to see what is involved in doing this. > > So my proposal is: > > - We change the routing to support the idea of "composite routing", so > > that we can tell the routing engine that we do not want to just > > execute one action/controller, but instead we want to execute > > multiple. > > - We then create a new HttpHandler that handles this by instead of > > instantiating only one controller and calling its action, it > > instantiates as many as were defined (this could be done sequential or > > in parallel or support both). > > - Once all action execute, we bring it all together into one single > > response. > > > If we go this path we could also implement what ASP.NET MVC does > > where they only support one model per view(ViewModel) and get rid of > > the PropertyBag to pass data to the view. > > > Thoughts? > > > Cheers > > John > > > On Jan 20, 11:20 pm, Krzysztof Ko¼mic (2) <[email protected]> wrote: > > > > Just a reference link. Not everyone is happy with ASP.NET MVC... > > > >http://spmason.com/post/343293206/why-aspnetmvc-2-is-broken > > > > On 19 Sty, 20:10, Krzysztof Ko 1/4 mic <[email protected]> wrote: > > > > > I didn't mean to imply anything. But contributions are always welcome > > > > :-) Especially for people > > > > who are well known for their skills and have good understanding of the > > > > codebase. > > > > Being an active user is also a big plus, but that goes without saying. > > > > Dogfooding FTW! > > > > > Krzysztof > > > > > On 2010-01-19 20:05, Ian Cooper wrote: > > > > > > On Jan 19, 6:35 pm, Krzysztof Ko mic<[email protected]> > > > > > wrote: > > > > > >> I'm not a web developer, so I am even less in a position to make > > > > >> opinionated statements here, > > > > > > Probably implies that as a consumer of the goods I should try to give > > > > > more back though. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
