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