For me, it appears to be just a rename. What we used to call controller, is now called handler. With the downside that now I'm obligated to implement an extra class honoring the web call contract. But perhaps I didn't get the big picture...
Cheers, Henry Conceição On Sun, Mar 21, 2010 at 9:38 PM, John Simons <[email protected]> wrote: > Jan, > My line of thought at the moment is why have a controller at all? > See Chad Myers post on it: > http://www.lostechies.com/blogs/chad_myers/archive/2009/06/18/going-controller-less-in-mvc-the-way-fowler-meant-it.aspx > > I have been hacking MR to bend it the way I want, so far I'm able to > convert a request into a command (using convention over configuration) > and execute that command with a simple interface. > Eg. > Assume a request comes in for /Products/List > I then convert this request into ProductsListWebCall > And then I go to my container and do the following: > var webCallHandlers = > windsorContainer.ResolveAll<Handles<TWebCall>>(new { EngineContext = > engineContext, ControllerContext = context}); > var webCall = Activator.CreateInstance<TWebCall>(); > > foreach (var handler in webCallHandlers) > { > handler.Handle(webCall); > } > And the Handle interface is: > public interface Handles<T> where T: WebCall > { > void Handle(T command); > } > > public interface WebCall > { > } > > As u can see I'm also injecting the ControllerContext and > EngineContext so that in the Handler I can do this: > public class ProductsListHandler : > Handles<ProductsListWebCall> > { > public IEngineContext EngineContext { get; set; } > public IControllerContext ControllerContext { get; set; } > > public void Handle(ProductsListWebCall webCall) > { > ControllerContext.PropertyBag["message"] = "Hello from > handler"; > } > } > > Sorry about the formatting of the code, I'll try to write a blog post > about it soon. > > Cheers > John > > On Mar 16, 1:26 pm, Jan Limpens <[email protected]> wrote: >> From my point of view, I hope nobody minds my late involvement in this >> discussion, MR's future should concentrate less in features and more >> in architecture. >> >> After all, functionality like the one provided by >> SmartDispatcherController should be (and mainly is) provided as an >> aspect. >> >> The aforementioned functionality to render multiple controller actions >> into a single view inverts the mvc paradigm and is no good idea in my >> point of view. The view should not be able to make such decisions, >> that's the controllers job. >> The controller how it is today is a point of very low cohesion and one >> of the points that should be implemented in a very different way. >> Fortunately, with the availability of DynamicActions, the controller >> could actually become the aspect providing Action-registration node, >> it ought to be, imho. >> This would make reuse much more efficient and would allow for better >> composibility. Imagine, one has (fake MEF style) >> >> public class MyController { >> >> [Import] >> public void MyAction { >> } >> >> } >> >> [Export("MyController.MyAction")] >> public class MyActionContent : DynamicAction{ >> //impl >> >> } >> >> [Export("MyController")] >> public class MyActionLayout : DynamicAction{ >> //impl >> >> } >> >> this would solve composition pretty well - on the controller side. >> >> On the view side, I completely dig OpenRasta's codec and content >> negotiation paradigm. It is sad, MR does not offer such a clean >> implementation. >> >> Composite UI is much more difficult to envision, in my eyes, because, >> contrary to WebForms, we do not have externally programmable views (we >> can not say "Body.Insert(new Whatever())"). But from a separation of >> concerns point of view, this is a good thing, probably. Still all >> frameworks offering composite GUIs have this somewhere. The problem >> is, that a view in a composite world cannot know of what parts it >> consists, but probably the solution ought to be similar to the >> controller: the view as a registration point for sub views based on >> some conventions. >> >> <% SubViews >> .For(v => v.ForNode = "contentNode") >> .With(v => viewData.GetData(v)) >> .OrderedBy(v => layout.ApplyOrder(v)) %> >> >> Composition is a big deal (I'd love to read hammett's take on this, >> but both of his blogs seem abandoned...) and is something really >> difficult to implement currently. >> >> Probably I should have said IMHO, much more often, so please take this >> as the opinion this is. >> >> --Jan >> >> On Jan 24, 8:15 pm, 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, 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 >> >> ... >> >> 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. > > -- 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.
