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