I'm not "against" embeding windsor / revamping default service provider , but I'm not sure to see the point:
- if other people want to use another container, it's become less obvious how to do so (I'd rather stick with the IMonoRailServiceProvider interface and not leak windsor, just use it internally if maintaining the DefaultServiceProvider is a pain), Like Ken said, people leaning to MVC frameworks are not far from using another container, and there are a lot of windsor - if the matter is to remove code, I find that the controller and smartdispatchercontroller classes have higher priority for refactor (duplicated exception management, and duplicated action execution logic for sync/async), I think these problems are hindering the move of the framework (any change to this logic has to be done really carefully, and is becoming more risky with the time) However, the topic is interesting. There are issues with the interaction with service provider: it currently hasn't the extension hooks to "specialize" the bits against the request context, it's a big factory which knows only one way, it is possible to specialize by implementing it's own factory, but I don't see it be straightforward or clear what to do. Also, about merging the binder, any reason to not include into castle.core? I'm sure it has uses outside of MR (I remember it's working with the TreeNode defined in Castle.Core). On Jul 14, 9:34 pm, John Simons <[email protected]> wrote: > Maybe we delay it to MR v3 > > Cheers > John > > ________________________________ > From: Henry Conceição <[email protected]> > To: [email protected] > Cc: Krzysztof Koźmic <[email protected]> > Sent: Thu, 15 July, 2010 2:09:46 PM > Subject: Re: Replacing MR Service Provider > > But if you want to mess with the controller factory and stuff, imho, > it'll be better to start from scratch. Also to do something > impressive, you'll need to mess with the descriptor, > action/filters/components execution in a way that would break all the > existing applications... > > Cheers, > Henry Conceição > > 2010/7/14 John Simons <[email protected]>: > > > > > Thanks Henry for starting a new thread. > > >>I'm not against the replacing, I'm questioning if the effort will worth. > > That is something we need to take a leap of faith and see. > > >>How replacing the ServiceProvider will lead to a more composable scenario, > >> if we are stuck with the controllerfactory? > > Who said that we will not change that as part of the refactoring ;) > > I'm sure Krzysztof will be pushing to use Windsor new Factory capabilities. > > >> In terms of functionality, what Monorail Facility can't offer, that the > >> Monorail powered by Windsor will do? > > That is exactly what I want, I want the Monorail Facility installed by > > default. > > > Cheers > > John > > > ________________________________ > > From: Henry Conceição <[email protected]> > > To: [email protected] > > Sent: Thu, 15 July, 2010 11:57:42 AM > > Subject: Replacing MR Service Provider > > > I've thought that would be better to start a dedicated thread to this > > discussion. > > > I'm not against the replacing, I'm questioning if the effort will worth. > > > How replacing the ServiceProvider will lead to a more composable > > scenario, if we are stuck with the controllerfactory? > > In terms of functionality, what Monorail Facility can't offer, that > > the Monorail powered by Windsor will do? > > > Cheers, > > Henry Conceição > > > On Wed, Jul 14, 2010 at 8:23 PM, John Simons <[email protected]> > > wrote: > >> Henry, > > >> I actually disagree with you, for composability vs inheritance the > >> container > >> makes this a lot simpler. > >> Actually, it would be nice to hear your thoughts on the future of MR? > >> The way I see it, MS MVC2 has pretty much caught up with MR features and > >> the > >> way things are going MS MVC3 is pretty much going to blow MR out of the > >> water, so if we don't do massive refactoring and improvements, what should > >> we do? > > >> Cheers > >> John > > >> ________________________________ > >> From: Henry Conceição <[email protected]> > >> To: [email protected] > >> Sent: Thu, 15 July, 2010 8:45:26 AM > >> Subject: Re: Monorail v2.1 roadmap > > >> My point is: It'll be a lot of work, I think so, and I can't foresee > >> it resolving the major problems (routing and composability vs > >> inheritance) of mr. But perhaps I'm don't seeing the big picture here. > > >> Cheers, > >> Henry Conceição > > >> 2010/7/14 Henry Conceição <[email protected]>: > >>> And do you think that the ability of constructor injection for the > >>> Monorail's internal classes worth the massive refactoring? > > >>> Cheers, > >>> Henry Conceição > > >>> On Wed, Jul 14, 2010 at 6:25 PM, John Simons <[email protected]> > >>> wrote: > >>>> Henry, > > >>>> The SL in MR is used to abstract the implementation of an IoC > >>>> Container(common practice), is not used as a replacement for one. > >>>> I'm looking forward to things like: > >>>> - constructor injection > >>>> - Autowiring (Controllers, Helpers, ViewComponents, Filters, Services, > >>>> ....) > >>>> - Reuse of container to register my own services with my own choice of > >>>> lifecycles > >>>> - Nice C# fluent registration API > >>>> - ... > > >>>>>The Monorail Framework doesn't depends on AR and/or Windsor. Only the > >>>>> integrations. > >>>> I'm referring to the project being dependant on these other projects > >>>> when > >>>> it > >>>> comes to releasing it. > >>>> And I'm not intending to have an explicit reference to Windsor in > >>>> Castle.Monorail.Framework. > >>>> The best way to look at it is by looking at the current MR Windsor > >>>> integration. > > >>>> Cheers > >>>> John > > >>>> ________________________________ > >>>> From: Henry Conceição <[email protected]> > >>>> To: [email protected] > >>>> Sent: Wed, 14 July, 2010 11:42:49 PM > >>>> Subject: Re: Monorail v2.1 roadmap > > >>>> Alright, MS MVC and Fubu did it. But how the current MR impl can be > >>>> benefit by start using Windsor instead his own ServiceLocator? > > >>>> The Monorail Framework doesn't depends on AR and/or Windsor. Only the > >>>> integrations. > > >>>> Cheers, > >>>> Henry Conceição > > >>>> 2010/7/14 Krzysztof Koźmic <[email protected]>: > >>>>> +1 > > >>>>> Jeremy went down the same path with Fubu. > >>>>> He requires IoC container, using SM out of the box, but there's no hard > >>>>> reference to it in the framework. If we do the same I think we're all > >>>>> good. > >>>>> We might want to provide a sample of using MR with other container in > >>>>> the > >>>>> doco BTW, or have a sample app that uses Autofac for example.. > > >>>>> Krzysztof > > >>>>> On 14/07/2010 5:22 PM, Ken Egozi wrote: > > >>>>> I really do not think that MR targets people that do not use IoC at > >>>>> all. > >>>>> so, replacing the internal container with Windsor is a reasonable move, > >>>>> as > >>>>> long as it would still be easy enough to hook in there one of the > >>>>> others > >>>>> (which should happen as contributions from actual OtherIoC users). > > >>>>> On Wed, Jul 14, 2010 at 10:10 AM, John Simons > >>>>> <[email protected]> > >>>>> wrote: > > >>>>>> Henry, > > >>>>>> According to the poll I did a while back, users do want it - > >>>>>>http://twtpoll.com/zr1tt0 > > >>>>>> I also believe this will make the code a lot simpler and easier to > >>>>>> extend > >>>>>> in the long run. > >>>>>> It also looks like MS MVC v3 is going down that path by integrating > >>>>>> MEF > >>>>>> and of course FubuMVC has already done it using StructureMap, so why > >>>>>> have > >>>>>> a > >>>>>> custom service provider in MR(which doesn't provide all the benefits a > >>>>>> fully > >>>>>> fledged IoC does) if we can have Windsor? > > >>>>>> Regarding interdependency, since users are already d/l Windsor as part > >>>>>> of > >>>>>> d/l the MR package, all there is for the users is an extra reference > >>>>>> in > >>>>>> VS. > >>>>>> As for the MR project itself, its release is already dependent on > >>>>>> Windsor > >>>>>> + ActiveRecord and I don't see that changing anytime soon. > > >>>>>> But happy to hear more comments/concerns. > > >>>>>> Cheers > >>>>>> John > > >>>>>> ________________________________ > >>>>>> From: Henry Conceição <[email protected]> > >>>>>> To: [email protected] > >>>>>> Sent: Wed, 14 July, 2010 3:19:24 PM > >>>>>> Subject: Re: Monorail v2.1 roadmap > > >>>>>> -1 for the substitution of the custom mr service provider by windsor. > >>>>>> It'll couple both projects and increase the project interdependency. > > >>>>>> Also, which benefits do you foresee with this move? > > >>>>>> Cheers, > >>>>>> Henry Conceição > > >>>>>> On Wed, Jul 14, 2010 at 12:01 AM, John Simons > >>>>>> <[email protected]> wrote: > >>>>>> > Dear Monorail users, > > >>>>>> > This upcoming release is mostly (see below) a bugfix release, > >>>>>> > therefore, > >>>>>> > there shouldn't be any breaking changes unless is part of a bug fix > >>>>>> > but > >>>>>> > even > >>>>>> > those will be documented as part of the release. > >>>>>> > So if you are using v2.0 or earlier and have one or more pesty bugs > >>>>>> > annoying > >>>>>> > you, please submit it here > >>>>>> >http://support.castleproject.org/projects/MR/issuesbrowserASAP. > > >>>>>> > If you feel like stepping in and help us fix some of the opened > >>>>>> > issues, > >>>>>> > have > >>>>>> > a look at this issues list - > > >>>>>>http://support.castleproject.org/projects/MR/issuesbrowser#criteria=v... > > >>>>>> > and read > > >>>http://stw.castleproject.org/How-to-submit-a-fix-to-any-Castle-Projec... > >>>>>> > . > > >>>>>> > But because it would be too boring to only have bug fixes in this > >>>>>> > release, > >>>>>> > here is a list of new features (not all features are complete yet): > >>>>>> > - Added support for inferred actions, If you have controller actions > >>>>>> > that > >>>>>> > their sole purpose is to render a view, then you are going to love > >>>>>> > this. > >>>>>> > You > >>>>>> > no longer have to declare empty actions, MR will look in your views > >>>>>> > folder > >>>>>> > and display that view automatically. If view is not found a 404 is > >>>>>> > thrown. > >>>>>> > - Added new helper called ActionHelper that invokes the specified > >>>>>> > child > >>>>>> > action and returns the result inline or as an HTML string, aka MS > >>>>>> > MVC > >>>>>> > Html.RenderAction and Html.Action see > >>>>>> >http://haacked.com/archive/2009/11/18/aspnetmvc2-render-action.aspx > >>>>>> > - Action Filter attributes - Gauthier Segay is working on this one > >>>>>> > :) > >>>>>> > - Support for anti-forgery token in post backs - - Gauthier Segay is > >>>>>> > also > >>>>>> > working on this one :) > >>>>>> > - ForHelper, this one is still a work in progress but the idea is to > >>>>>> > replicate this > > >>>>>>http://bradwilson.typepad.com/blog/2009/10/aspnet-mvc-2-templates-par... > > >>>>>> > (I'll be committing the first cut very shortly, and this may end up > >>>>>> > replacing the existing scaffolding) > >>>>>> > - Planning to add a few enhancements to CombineJSViewComponent based > > ... > > 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.
