The ideia looks nice, but it doesn't scale. Imagine a page that has thousands of pageviews, then multiply it by 6. Also, you'll multiplying the number of requests, nh/ar sessions, transactions and etc.
Cheers, Henry Conceição On Sat, Jan 23, 2010 at 5:07 AM, John Simons <[email protected]> wrote: > 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. > > -- 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.
