and if MVC was brought up - I'd like to raise the question: do we actually need MR to continue as a full framework, or did MVC with version 2 became good enough as a basis for web development, and MR can work as an added value package, (much like mvc-contrib, or even be an addition to mvc-contrib)
I'm not saying that this *is* what I think we should do. However it is an interesting question, and we need to be able to give a good answer for that when asked. Since I do not have experience with MVC2 at all, I cannot supply with an answer myself. 2010/1/19 SerialSeb <[email protected]> > Note that we use a different routing engine from MVC because it was > written before MVC. It's entirely possible to swap around the > implementation of the URI repository to whatever implementation you > want. > > There's one main reason why I do not want to support MVC's routing > engine, it's greedy, which mean you can't run it side by side with any > other components unless you add all the URIs mapped to another module > as ignored routes. > > And of course, it's asp.net specific and OpenRasta is not, so we can't > rely on it being there when we're running in-process or in our own > managed AppDomain. > > > > On Jan 18, 9:16 pm, Krzysztof Koźmic <[email protected]> > wrote: > > inline, > > > > On 2010-01-18 22:05, John Simons wrote: > > > > > > > > > Inline > > > > > On Jan 18, 11:31 pm, Krzysztof Ko mic (2)<[email protected]> wrote: > > > > >> inline > > > > >> On 18 Sty, 13:05, John Simons<[email protected]> wrote: > > > > >>> Now that Monorail v2 is out, is time to start thinking about what is > > >>> next from Monorail v3. > > > > >>> I've already created a uservoice for Monorail v3: > http://castle.uservoice.com/forums/38553-monorail-v3 > > > > >>> But there is a list that I've started working on (this list is still > > >>> growing and there will be more added), most of these are just by > going > > >>> through the source code of Monorail: > > > > >>> - Need to break the coupling that Monorail currently has on other > > >>> libs, at the moment Monorail is dependant on nearly all other Castle > > >>> projects. I think to do this we need to enforce the same mechanism > > >>> that Windsor uses by the use of facilities to extend the container. > > > > >> As long as we don't end up with tens of small assemblies with very few > > >> types. > > >> I'm all for breaking dependencies where it makes sense, but think > > >> three time before creating yet another assembly for that. > > > > > My idea is to make it their own packages with their own release > > > schedules. > > > > It feels like micromanagement to me, and I don't think we have enough > > resources to play this game.I would try to avoid it, unless there's > > really good reason to do so. > > > > goodnight, > > Krzysztof > > > > > > > > > > > > >>> - MonoRail routing, well this is a grey area that currently is not > > >>> totally complete, my view on this is lets just use the > > >>> System.Web.Routing > > > > >> This would be a major breaking change. And while my experience with > > >> Monorail routing is none, does it not offer any advantages > > >> over System.Web.Routing? OpenRasta for example, is a framework that > > >> deliberately does not use SWR providing its own routing engine > > >> While SWR has the advantage of being part of BCL and being very well > > >> documented by books, blogs and MSDN, I would be very careful > > >> when introducing such change. > > > > > I would actually not consider it a major change. > > > The benefit of using System.Web.Routing vs our own (which btw we have > > > 2 implementations, so we would be breaking code anyway!) is that would > > > be less code to maintain and an easier migration from someone coming > > > from either ASP.Net MCV or FubuMVC. > > > As it stands, our implementation does not offer any advantages over > > > System.Web.Routing, actually I find the System.Web.Routing a lot more > > > extendible than ours. > > > > >>> - javascript support, I think we are supporting too many different > > >>> frameworks in this area, we are trying to maintain prototype, > > >>> jquery,delicious,... > > > > >> I'd say due to immense popularity, we should put major emphasis on > > >> JQuery > > > > > I agree, we should concentrate our efforts on one javascript library. > > > > >>> - Scaffolding, why is this tight to ActiveRecord? > > > > >>> - How do we stay in business now with other offers like ASP.Net MVC, > > >>> FubuMVC,... ? > > > > >> We release more often :) > > > > > Agree > > > > >>> - The whole code base needs a clean-up, remove obsolete code, ... > > > > >> Perhaps before v3.0 we should have a minor release first, with little > > >> breaking changes > > >> and mostly concentrated on clean up and polish? > > > > > Agree > > > > >>> The list is not finished, it is a work in progress. > > > > >>> Cheers > > >>> John- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text - > > -- > 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]<castle-project-devel%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > > > > -- Ken Egozi. http://www.kenegozi.com/blog http://www.delver.com http://www.musicglue.com http://www.castleproject.org http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם--
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.
