moreover I would like to suggest making mandatory documenting all
breaking changes, along with clear migration path. This concerns not
just Monorail, but all existing projects.
I suggest we maintain next to changes.txt a upgrade.txt (or similar
name) in the following format:
- Short description/justification of the change (along with revision
numbers where it was committed)
- Description of the suggested migration paths, best with code
samples.
For example:
===============================================================================================
- removed "UsingFactory" method from IoC fluent registration API,
because it provides no real
value over "UsingFactoryMethod" method, and only confuses users
(r666)
- All calls to UsingFactory can be replaced corresponding calls to
UsingFactoryMethod.
- sample:
kernel.Register(
Component.For<ICarProvider>()
.UsingFactory((AbstractCarProviderFactory f) => f.Create
(kernel.Resolve<User>()))
);
The above call can be replaced with semantically identical call to
UsingFactoryMethod:
kernel.Register(Component.For<ICarProvider>()
.UsingFactoryMethod(
k => k.Resolve<AbstractCarProviderFactory>()
.Create(k.Resolve<User>()))
);
=======================================================================================
On 18 Sty, 13:31, 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.
>
> > - 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.
>
>
>
> > - 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
>
>
>
> > - 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 :)
>
>
>
> > - 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?
>
>
>
> > The list is not finished, it is a work in progress.
>
> > Cheers
> > John
>
>
--
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.
