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 is http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/18/the-filter-viewdata-anti-pattern.aspx 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 > > > > >> 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... > > > > > >> Nitpicking on MS:... > > 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.
