I don't think John wants hard reference. He just wants an actual
contianer as a must, as opposed to cripled SL.
Fully utilizing IoC principle, which means with no hard reference to the
container.
John, correct me if I'm wrong but from my understanding that is the case.
You will be able to use MEF, Autofac, StructureMap, or any other actual
container. You will HAVE to use one.
Krzysztof
On 17/07/2010 1:57 AM, hammett wrote:
John, users always want everything. It's up to your judgment to settle
what is indeed best for them and for us. I'd be opposed to this hard
dependency.
I'd pretty much prefer to use MEF, as it's in the box and is
lightweight enough to enable extensibility scenarios without perf
impacts and increasing the complexity.
2010/7/14 Henry Conceição<[email protected]>:
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/issuesbrowser ASAP.
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=view%3DOpened%20Issues%26%26p%3D1%26psize%3D10%26f.Status%3DOpen%26f.Status%3DWork%20Started%26f.Status%3DWork%20Stopped%26f.Status%3DReopened
and read
http://stw.castleproject.org/How-to-submit-a-fix-to-any-Castle-Project.ashx
.
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-part-1-introduction.html
(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
on
http://weblogs.asp.net/rashid/archive/2009/11/09/web-asset-enhancements-in-telerik-extensions-for-asp-net-mvc.aspx
- Planning to ship Samples in zip package, these samples will be
using
NVelocity as the view engine (hope everyone is happy with this
decision?)
- VS2010 templates + resharper templates, this is not intellisense!
- Windsor upgraded to v2.5
- Thinking of using Windsor container as the default IoC container in
MR,
but I need Krzysztof's help with this one, and it may be a big task
for
this
release
Also, I'm planning to reduce the number of assemblies in MR. So the
plan
is
to merge Castle.MonoRail.TestSupport,
Castle.MonoRail.TransformFilters
and
Castle.Components.Binder into Castle.Monorail.Framework.
If you are using Castle.Components.Binder on its own please let us
know!
Finally, if you have any other suggestions, ideas or want to help the
development of any of these new features let us know here, we do need
your
help!
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.
--
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.
--
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.
--
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.
--
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.
--
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.
--
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.
--
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.
--
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.
--
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.
--
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.
