But you would still have to place these concerns somewhere in the layout or in the view, so it's the same as RenderAction. The only advantage is the possibility of processing all these sub-actions in parallel, but you'd lose the ability to define different parameters for each sub-action (i.e. they would all get the same context, whereas with RenderAction you can define different querystring/parameters/ context for each sub-action). But the main problem I see with this is that I don't know who's really in control of the response. If they all run in parallel and Product/ View decides that the product is offline and the response should be redirected, what happens to the other actions? PropertyBag would still be needed to render each sub-action.
Or maybe I got it all wrong and didn't understand you... With RenderAction screen sections can be easily split among developers since they are orthogonal and ultimately just regular controllers. Then the main controller does the final composition. SubControllers are a similar concept: http://mhinze.com/subcontrollers-in-aspnet-mvc/ Anyone here knows Seaside? I hear it's great at composability, we could borrow some ideas from it. Cheers Mauricio On Jan 24, 6:34 pm, John Simons <[email protected]> wrote: > Mauricio, thank you a lot for finding an article that highlights the > benefits of what I'm proposing. > But in this article the author chose to use RenderAction to separate > the concerns, but by doing that we now have mixed concerns on our view > file(the template itself). > What I'm proposing is to go one step further, and come up with > hopefully total separation of concerns including on the view file. > > And because action takes care of one and only one concern (hence the > reason I said we don't need a PropertyBag any longer), we should be > able to render all these in parallel. > > This way of separation is used quite frequently in Windows > applications where different developer teams take care of different > screen sections. > > My vision to register all this would be something like this: > RoutingModuleEx.Engine.Add( > new CompositeRoute("ProductRoute", "/Products/<productId>/<action>") > .ComposedOf( > Controller("Product").Action("View"), > Controller("Login").Action("Info"), > Controller("ShoppingCart").Action("Summary"), > Controller("CustomerFeedback").Action("List"), > Controller("PurchasingHistory").Action("SummaryList")) > WithLayout("productlayout") > ); > > Cheers > John > > On Jan 25, 1:12 am, Mauricio Scheffer <[email protected]> > wrote: > > > > > It's not about getting data in parallel, but a different way of > > separating concerns. > > > I have found it useful to model reusable, orthogonal concerns to a > > page, things that not only display information but also have an > > associated action. A good example > > ishttp://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/18/the-f... > > > On Jan 23, 7:05 pm, Ken Egozi <[email protected]> wrote: > > > > Nothing is stopping anyone from spawning these calls in parallel, > > > asynchronously, then get it all back, and spill the data into the property > > > bag. > > > > in my view, the Controller's job is exactly that (plus binding data > > > to/from > > > http, and dealing with authentication via filters) > > > and by "that" I refer to "call service layer to grab data, and stuff the > > > data into properyBag". > > > > I have had much success in the past using the CCR to get required data in > > > parallel. > > > the nice thing is that you don't get many concurrency issues - the data > > > querying is parallel, however the Context access is either before (when > > > mining context data and pushing it to the service layer for querying) or > > > *after* querying, when serially pushing the returned data into the > > > prop=bag. > > > > so, I really don't thing that it is the FW responsibility, but rather the > > > programmers. > > > > On Sat, Jan 23, 2010 at 11:39 PM, Gauthier Segay > > > <[email protected]>wrote: > > > > > Henri, > > > > > what John has explained will mean a single http request triggering > > > > multiple actions (potentially on multiple controllers), the difference > > > > of the MSMVC implementation with John proposition is that each action > > > > would be triggered in parallel (which I think need some abstraction/ > > > > encapsulation on what is possible to execute because multiple thread > > > > couldn't share NH ISession or web context) and would possibly defined > > > > via routing instead (I'm unsure about John vision on view template > > > > side) > > > > > Mauricio, > > > > > from your experience with ASP.NET MVC, would you say that this feature > > > > is bringing something usefull considering what viewcomponents can do? > > > > > On Jan 23, 6:58 pm, Mauricio Scheffer <[email protected]> > > > > wrote: > > > > > There's already a suggestion on uservoice to implement RenderAction: > > > >http://castle.uservoice.com/forums/38553-monorail-v3/suggestions/3102... > > > > > > I've used it in ASP.NET MVC (v1 has it in MvcFutures and it will be > > > > > core in v2) and it's a nice, useful feature. > > > > > > It all runs within the same request so there is no scaling / perf > > > > > problem. > > > > > > On Jan 23, 11:03 am, Henry Conceição <[email protected]> > > > > > wrote:> 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 > > > ... > > > read more » -- 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.
