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 as http://blogs.intesoft.net/post/2009/02/renderaction-versus-renderpartial-aspnet-mvc.aspx) 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.viewdatadictionary(loband).aspx http://msdn.microsoft.com/en-us/library/dd470798(loband).aspx Nitpicking on MS: what is sad in MSMVC API is that ViewPage<TModel> doesn't implement a polymorph able signature that would help abstracting and share things accross viewengine, as is this semantic it is strictly bound to webform viewengine... Back to MR: I'm not sure of the implication on the viewengine behaviour and API refactor required, it may require implementing some semantics in the view engine to have that integrate nicely. Still unsure if this is a one size fit all problem I'm not in favor or against both of your propositions, I think looking at MSMVC is required for the evolution, but there are also other projects / ideas to seek. I'll try to add some suggestion in MR UV next time, all theses words just made me think at a naughty thing about dynamic actions: this.DynamicActions["someaction"] = (enginecontext, controller, controllercontext) => { do something } or another one this.DynamicActions["someaction"] = (FooForm form) => { do something with idatabinder processed FooForm } On 23 jan, 04:19, John Simons <[email protected]> wrote: > I think there is still a market for MonoRail, but is not going to be > an easy ride! > We have learned a lot, from developing such a framework, and at the > moment I have to say with confidence that in terms of features we are > still ahead of the game in comparison to ASP.NET MVC. > Our down point is in the doco/samples. > 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! > > Regarding using ASP.NET MVC code base or extend it, my question is > what for? What are we going to get from that, is not that we need it > (we have already got the code written in MonoRail). > > Hamilton just quickly mentioned the word on another thread, > "Composition". > As far as I know at the moment no other .Net MVC framework has the > concept of "Web page composition" server side. > The way developers are achieving this is by using Ajax to load > sections of their web page, but this is done client side. > My proposal is for us to change Monorail to do this on the server > side. > > 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. > > 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. > > Thoughts? > > Cheers > John > > On Jan 20, 11:20 pm, Krzysztof Ko¼mic (2) <[email protected]> wrote: > > > > > Just a reference link. Not everyone is happy with ASP.NET MVC... > > >http://spmason.com/post/343293206/why-aspnetmvc-2-is-broken > > > On 19 Sty, 20:10, Krzysztof Ko 1/4 mic <[email protected]> wrote: > > > > I didn't mean to imply anything. But contributions are always welcome > > > :-) Especially for people > > > who are well known for their skills and have good understanding of the > > > codebase. > > > Being an active user is also a big plus, but that goes without saying. > > > Dogfooding FTW! > > > > Krzysztof > > > > On 2010-01-19 20:05, Ian Cooper wrote: > > > > > On Jan 19, 6:35 pm, Krzysztof Ko mic<[email protected]> > > > > wrote: > > > > >> I'm not a web developer, so I am even less in a position to make > > > >> opinionated statements here, > > > > > Probably implies that as a consumer of the goods I should try to give > > > > more back though. -- 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.
