I forgot to mention that I really would like to hear Hamilton's view on this, since he mentioned it ;)
On Jan 25, 4:53 pm, John Simons <[email protected]> wrote: > Inline > > On Jan 25, 10:15 am, Mauricio Scheffer <[email protected]> > wrote: > > > 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, > > Not really, in my example I have "WithLayout("productlayout")" > But I see this layout as being very dumb, agnostic to models or data, > the really only thing it would do is render the small areas in the > right places. > But yes, I haven't figure out everything yet, things like title of the > page, .... > All I want is to put this idea out there, so that we can discuss it > and see if it is something we want to move towards. > > There are other things I have been thinking about, like we could have > Caching on a per Controller/Action, so eg the navigation doesn't > really change that frequently so it would be a very good candidate to > cache for a specific amount of time. > > > 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). > > Not sure if I follow you, you would still have this ability, your > action can access whatever it needs to do its job in the current > context. > With RenderAction on the view you would have to hardcode the > parameters/querystring right? > > > 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? > > Well, the question is, is it the responsibility of the Product/View > action to work out if it should be displayed? Separation of concerns. > Maybe we do require some kind of way of running Filters/Rules before/ > after the compositeview? > > > PropertyBag would still be needed to render each sub-action. > > > Or maybe I got it all wrong and didn't understand you... > > No, you are in the right track :) , I'm the one that is probably > trying to do something that is out there and simply doesn't make > sense! > > > > > 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. > > Yes you can, but if the main controller does the final composition > then this controller needs to be aware of the others. > > > > > 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. > > Haven't looked at Seaside, but will research it, to see how they do > it. > I also like the approach that FubuMVC took, convention over > configuration. > > Cheers > John > > > > > 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 > > ... > > 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.
