>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 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
>
> ...
>
> 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.
