As we get close to the release of the Asp.Net mvc framework it is time to take a look at what the contrib project has grown into organically and match that up with what we want to get out of the project to make sure everything is aligning.
The goals of the project:
*Ease of use/adoption:* We want to position the MvcContrib project so that it is easy for someone new to the ASP.Net MVC framework to include and use the MvcContrib functionality. The goal here is for frictionless and painless adoption.
*Drive to conventions:* We want to provide some opinions on how we think the framework should be used. This means making the conventions easy to discover and use.
*Provide nice to have functionality: *We are also willing to allow for some features that are infrequently used to still be easy to access, but this must be balanced with the first two goals.
So, that leads us to the question of why are we bringing this up and what does that mean?
We do see the MvcContrib project site being a central place to look for alternative implementations. We may not host all of these in our project, but we could at least list all of them, view engines and IoC, than have links to their project homepages. I see a lot of value in maintaining a complete list of known extensions.
Here is a list of actions we want to take on the code base to support the goal.
1. Consolidate the existing mvc projects/assemblies down to four (4) projects.
· MvcContrib
· MvcContrib.Extras
· MvcContrib.TestHelpers
· MvcContrib.UnitTests
2. Add a dependency on the CommonServiceLocator to replace all of the IoC containers in the MvcContrib project.
3. Remove old dependencies that are available in their home projects:
· Ninject
· StructureMap – provide links to the CSL implementation
· Unity – provide links to the CSL implementation
· Castle / Windsor – the Controller register could be pulled into documentation on the contrib project website.
· Spark – It is being maintained as a separate project, we should be pushing developers to it home page to get the most recent version of the project.
4. Deprecate and remove the following projects:
· Xslt View Engine
· Nvelocity
· Brail
· Spring
At this point I would like to open up the discussion. Please make it know if you are relying on any of the functionality that is planned for removal.
On Fri, Feb 20, 2009 at 12:07 PM, Eric Hexter <eric.hex...@gmail.com> wrote:
> As we get close to the release of the Asp.Net mvc framework it is time to
> take a look at what the contrib project has grown into organically and match
> that up with what we want to get out of the project to make sure everything
> is aligning.
> The goals of the project:
> Ease of use/adoption: We want to position the MvcContrib project so that it
> is easy for someone new to the ASP.Net MVC framework to include and use the
> MvcContrib functionality. The goal here is for frictionless and painless
> adoption.
> Drive to conventions: We want to provide some opinions on how we think the
> framework should be used. This means making the conventions easy to
> discover and use.
> Provide nice to have functionality: We are also willing to allow for some
> features that are infrequently used to still be easy to access, but this
> must be balanced with the first two goals.
> So, that leads us to the question of why are we bringing this up and what
> does that mean?
> We do see the MvcContrib project site being a central place to look for
> alternative implementations. We may not host all of these in our project,
> but we could at least list all of them, view engines and IoC, than have
> links to their project homepages. I see a lot of value in maintaining a
> complete list of known extensions.
> Here is a list of actions we want to take on the code base to support the
> goal.
> 1. Consolidate the existing mvc projects/assemblies down to four (4)
> projects.
> · MvcContrib
> · MvcContrib.Extras
> · MvcContrib.TestHelpers
> · MvcContrib.UnitTests
> 2. Add a dependency on the CommonServiceLocator to replace all of the
> IoC containers in the MvcContrib project.
> 3. Remove old dependencies that are available in their home projects:
> · Ninject
> · StructureMap – provide links to the CSL implementation
> · Unity – provide links to the CSL implementation
> · Castle / Windsor – the Controller register could be pulled into
> documentation on the contrib project website.
> · Spark – It is being maintained as a separate project, we should be
> pushing developers to it home page to get the most recent version of the
> project.
> 4. Deprecate and remove the following projects:
> · Xslt View Engine
> · Nvelocity
> · Brail
> · Spring
> At this point I would like to open up the discussion. Please make it know if
> you are relying on any of the functionality that is planned for removal.
On Fri, Feb 20, 2009 at 2:10 PM, Will Shaver <will.sha...@gmail.com> wrote:
> So FluentHTML would be going where?
> There are a couple of things in Castle -> Perhaps we should have an
> MvcCastleContrib project separate?
> On Fri, Feb 20, 2009 at 12:07 PM, Eric Hexter <eric.hex...@gmail.com>
> wrote:
> > As we get close to the release of the Asp.Net mvc framework it is time to
> > take a look at what the contrib project has grown into organically and
> match
> > that up with what we want to get out of the project to make sure
> everything
> > is aligning.
> > The goals of the project:
> > Ease of use/adoption: We want to position the MvcContrib project so that
> it
> > is easy for someone new to the ASP.Net MVC framework to include and use
> the
> > MvcContrib functionality. The goal here is for frictionless and
> painless
> > adoption.
> > Drive to conventions: We want to provide some opinions on how we think
> the
> > framework should be used. This means making the conventions easy to
> > discover and use.
> > Provide nice to have functionality: We are also willing to allow for some
> > features that are infrequently used to still be easy to access, but this
> > must be balanced with the first two goals.
> > So, that leads us to the question of why are we bringing this up and what
> > does that mean?
> > We do see the MvcContrib project site being a central place to look for
> > alternative implementations. We may not host all of these in our
> project,
> > but we could at least list all of them, view engines and IoC, than have
> > links to their project homepages. I see a lot of value in maintaining a
> > complete list of known extensions.
> > Here is a list of actions we want to take on the code base to support the
> > goal.
> > 1. Consolidate the existing mvc projects/assemblies down to four
> (4)
> > projects.
> > · MvcContrib
> > · MvcContrib.Extras
> > · MvcContrib.TestHelpers
> > · MvcContrib.UnitTests
> > 2. Add a dependency on the CommonServiceLocator to replace all of
> the
> > IoC containers in the MvcContrib project.
> > 3. Remove old dependencies that are available in their home
> projects:
> > · Ninject
> > · StructureMap – provide links to the CSL implementation
> > · Unity – provide links to the CSL implementation
> > · Castle / Windsor – the Controller register could be pulled into
> > documentation on the contrib project website.
> > · Spark – It is being maintained as a separate project, we should
> be
> > pushing developers to it home page to get the most recent version of the
> > project.
> > 4. Deprecate and remove the following projects:
> > · Xslt View Engine
> > · Nvelocity
> > · Brail
> > · Spring
> > At this point I would like to open up the discussion. Please make it know
> if
> > you are relying on any of the functionality that is planned for removal.
On Fri, Feb 20, 2009 at 12:13 PM, Eric Hexter <eric.hex...@gmail.com> wrote:
> Lets get into some details, about what should stay from the castle
> dependencies and which portions are "dead" code.
> On Fri, Feb 20, 2009 at 2:10 PM, Will Shaver <will.sha...@gmail.com> wrote:
>> So FluentHTML would be going where?
>> There are a couple of things in Castle -> Perhaps we should have an
>> MvcCastleContrib project separate?
>> On Fri, Feb 20, 2009 at 12:07 PM, Eric Hexter <eric.hex...@gmail.com>
>> wrote:
>> > As we get close to the release of the Asp.Net mvc framework it is time
>> > to
>> > take a look at what the contrib project has grown into organically and
>> > match
>> > that up with what we want to get out of the project to make sure
>> > everything
>> > is aligning.
>> > The goals of the project:
>> > Ease of use/adoption: We want to position the MvcContrib project so that
>> > it
>> > is easy for someone new to the ASP.Net MVC framework to include and use
>> > the
>> > MvcContrib functionality. The goal here is for frictionless and
>> > painless
>> > adoption.
>> > Drive to conventions: We want to provide some opinions on how we think
>> > the
>> > framework should be used. This means making the conventions easy to
>> > discover and use.
>> > Provide nice to have functionality: We are also willing to allow for
>> > some
>> > features that are infrequently used to still be easy to access, but this
>> > must be balanced with the first two goals.
>> > So, that leads us to the question of why are we bringing this up and
>> > what
>> > does that mean?
>> > We do see the MvcContrib project site being a central place to look for
>> > alternative implementations. We may not host all of these in our
>> > project,
>> > but we could at least list all of them, view engines and IoC, than have
>> > links to their project homepages. I see a lot of value in maintaining a
>> > complete list of known extensions.
>> > Here is a list of actions we want to take on the code base to support
>> > the
>> > goal.
>> > 1. Consolidate the existing mvc projects/assemblies down to four
>> > (4)
>> > projects.
>> > · MvcContrib
>> > · MvcContrib.Extras
>> > · MvcContrib.TestHelpers
>> > · MvcContrib.UnitTests
>> > 2. Add a dependency on the CommonServiceLocator to replace all of
>> > the
>> > IoC containers in the MvcContrib project.
>> > 3. Remove old dependencies that are available in their home
>> > projects:
>> > · Ninject
>> > · StructureMap – provide links to the CSL implementation
>> > · Unity – provide links to the CSL implementation
>> > · Castle / Windsor – the Controller register could be pulled
>> > into
>> > documentation on the contrib project website.
>> > · Spark – It is being maintained as a separate project, we
>> > should be
>> > pushing developers to it home page to get the most recent version of the
>> > project.
>> > 4. Deprecate and remove the following projects:
>> > · Xslt View Engine
>> > · Nvelocity
>> > · Brail
>> > · Spring
>> > At this point I would like to open up the discussion. Please make it
>> > know if
>> > you are relying on any of the functionality that is planned for removal.
> Add a dependency on the CommonServiceLocator to replace all of the IoC
containers in the MvcContrib project.
As I've mentioned in the past, swapping the current controller factory implementations for one based on the CSL is not as simple as it seems as the CSL does not support releasing components (so it is not possible to implement IControllerFactory.ReleaseController properly). This can be mitigated with the use of child containers which can be disposed at the end of a request, but this is adding an extra level of complexity. I guess the question is: is having a leaner codebase worth the extra complexity and higher learning curve? Personally I'm OK with this, but I'm thinking of new users in particular who are not as familiar with the specifics of the various containers.
> So FluentHTML would be going where?
You could easily turn FluentHTML into a separate project entirely (I believe it was separate originally?) as it has no dependencies on MvcContrib. Personally, I much prefer having several smaller projects that can be mixed and matched rather than one mammoth 'one contrib to rule them all'. I'd particularly like to hear Tim's thoughts on this...
> Deprecate and remove the following projects: Nvelocity, Brail
Is this really a good idea? I know several people use these and there are no alternative implementations out there. The version of Brail in the Castle trunk is completely incompatible with aspnetmvc. Again, these could be moved to separate projects if there was someone willing to maintain them, but I'm not sure that getting rid of them completely is necessarily wise if there are people using them.
Other thoughts...
There are several different styles used for naming/writing tests. I propose that we come up with a standard style for testing, and I'd also like to see a move towards fluent test extensions (foo.ShouldEqual(bar)) and away from the Assert.That(...) style. The same also goes for mocking - we have some places using the old record/replay model and others use the new AAA style. I'd like to see everything moved over to the AAA approach.
I think it is also important to come up with some guidelines for what should actually be included in the project. Currently I apply pretty much every patch that is submitted unless there's an obvious reason not to. Perhaps we should resurrect the use of the mvccontrib-developers mailing list for discussing patches?
You have been key to the success of MvcContrib up to this point. You have
been so responsive in applying patches and upgrading the project. THANK YOU
for all your hard work. You are an asset to this project.
We need to start being a little more picky about what we include, so Eric
and I are trying to flesh out a strategy for market adoption. I'm glad you
are part of this discussion because you have been the most active committer
on MvcContrib.
Let's get opinions from everyone for about a week and then we (you, me and
Eric) can decide what course of action to take.
Best regards,
Jeffrey Palermo, Microsoft MVP, MCSD.Net
CTO, Headspring Systems
agile. software. consulting.
512-459-2260 x 712
On Fri, Feb 20, 2009 at 2:43 PM, Jeremy Skinner
<jer...@jeremyskinner.co.uk>wrote:
> > Add a dependency on the CommonServiceLocator to replace all of the IoC
> containers in the MvcContrib project.
> As I've mentioned in the past, swapping the current controller factory
> implementations for one based on the CSL is not as simple as it seems as the
> CSL does not support releasing components (so it is not possible to
> implement IControllerFactory.ReleaseController properly). This can be
> mitigated with the use of child containers which can be disposed at the end
> of a request, but this is adding an extra level of complexity. I guess the
> question is: is having a leaner codebase worth the extra complexity and
> higher learning curve? Personally I'm OK with this, but I'm thinking of new
> users in particular who are not as familiar with the specifics of the
> various containers.
> > So FluentHTML would be going where?
> You could easily turn FluentHTML into a separate project entirely (I
> believe it was separate originally?) as it has no dependencies on
> MvcContrib. Personally, I much prefer having several smaller projects that
> can be mixed and matched rather than one mammoth 'one contrib to rule them
> all'. I'd particularly like to hear Tim's thoughts on this...
> > Deprecate and remove the following projects: Nvelocity, Brail
> Is this really a good idea? I know several people use these and there are
> no alternative implementations out there. The version of Brail in the Castle
> trunk is completely incompatible with aspnetmvc. Again, these could be moved
> to separate projects if there was someone willing to maintain them, but I'm
> not sure that getting rid of them completely is necessarily wise if there
> are people using them.
> Other thoughts...
> There are several different styles used for naming/writing tests. I propose
> that we come up with a standard style for testing, and I'd also like to see
> a move towards fluent test extensions (foo.ShouldEqual(bar)) and away from
> the Assert.That(...) style. The same also goes for mocking - we have some
> places using the old record/replay model and others use the new AAA style.
> I'd like to see everything moved over to the AAA approach.
> I think it is also important to come up with some guidelines for what
> should actually be included in the project. Currently I apply pretty much
> every patch that is submitted unless there's an obvious reason not to.
> Perhaps we should resurrect the use of the mvccontrib-developers mailing
> list for discussing patches?
I really don't think removing NVelocity and Brails is a good idea. They are both viable solutions and there is no alternative homes for these right now.
Regarding FluentHtml, I'd prefer to keep it with MvcContrib...if it
fits. Doing so leverages the community (this list) and resources (CI,
defect tracking). There's no inherent reason it could not be put into
MvcContrib assembly or Extras. I think we decided to keep it separate
to because it was the simplest path and perhaps to Jeremy's point
about mixing and matching.
I am using MvcContrib.FluentHtml together with some other bits from MvcContrib and MvcContrib.Castle. I agree with Jeremy (and I guess Tim) that keeping it as a separate unit is better for the same reasons mentioned below.
>-----Original Message-----
>From: mvccontrib-discuss@googlegroups.com [mailto:mvccontrib-
>discuss@googlegroups.com] On Behalf Of Tim Scott
>Sent: Friday, February 20, 2009 10:36 PM
>To: mvccontrib-discuss
>Subject: [mvccontrib-discuss] Re: Mvc Contrib – Version 1.0 preparation /
>project restructuring
>Regarding FluentHtml, I'd prefer to keep it with MvcContrib...if it
>fits. Doing so leverages the community (this list) and resources (CI,
>defect tracking). There's no inherent reason it could not be put into
>MvcContrib assembly or Extras. I think we decided to keep it separate
>to because it was the simplest path and perhaps to Jeremy's point
>about mixing and matching.
I don't thinks its been made clear why we need to slim down MvcContrib
or why we need to be a little more picky about applying patches. I
acknowledge the three goals and to the best of my knowledge we meeting
those goals. Is there evidence to the contrary? If we were to drive
to more conventionality we would ship with one IoC implementation
(with the ability for you to substitute your own) and one view engine
(with the ability for you to substitute your own) and one Controller
implementation (with the ability to substitute your own) and one...
If anything removing the current dependencies will make it more
difficult to adopt MvcContrib because now you will have to shop around
for CSL implementations that fit your needs for the IoC of your
choice.
<jeffreypale...@gmail.com> wrote:
> Jeremy,
> (and for everyone listening)
> You have been key to the success of MvcContrib up to this point. You have
> been so responsive in applying patches and upgrading the project. THANK YOU
> for all your hard work. You are an asset to this project.
> We need to start being a little more picky about what we include, so Eric
> and I are trying to flesh out a strategy for market adoption. I'm glad you
> are part of this discussion because you have been the most active committer
> on MvcContrib.
> Let's get opinions from everyone for about a week and then we (you, me and
> Eric) can decide what course of action to take.
> Best regards,
> Jeffrey Palermo, Microsoft MVP, MCSD.Net
> CTO, Headspring Systems
> agile. software. consulting.
> 512-459-2260 x 712
> On Fri, Feb 20, 2009 at 2:43 PM, Jeremy Skinner <jer...@jeremyskinner.co.uk>
> wrote:
>> Some thoughts...
>> > Add a dependency on the CommonServiceLocator to replace all of the IoC
>> > containers in the MvcContrib project.
>> As I've mentioned in the past, swapping the current controller factory
>> implementations for one based on the CSL is not as simple as it seems as the
>> CSL does not support releasing components (so it is not possible to
>> implement IControllerFactory.ReleaseController properly). This can be
>> mitigated with the use of child containers which can be disposed at the end
>> of a request, but this is adding an extra level of complexity. I guess the
>> question is: is having a leaner codebase worth the extra complexity and
>> higher learning curve? Personally I'm OK with this, but I'm thinking of new
>> users in particular who are not as familiar with the specifics of the
>> various containers.
>> > So FluentHTML would be going where?
>> You could easily turn FluentHTML into a separate project entirely (I
>> believe it was separate originally?) as it has no dependencies on
>> MvcContrib. Personally, I much prefer having several smaller projects that
>> can be mixed and matched rather than one mammoth 'one contrib to rule them
>> all'. I'd particularly like to hear Tim's thoughts on this...
>> > Deprecate and remove the following projects: Nvelocity, Brail
>> Is this really a good idea? I know several people use these and there are
>> no alternative implementations out there. The version of Brail in the Castle
>> trunk is completely incompatible with aspnetmvc. Again, these could be moved
>> to separate projects if there was someone willing to maintain them, but I'm
>> not sure that getting rid of them completely is necessarily wise if there
>> are people using them.
>> Other thoughts...
>> There are several different styles used for naming/writing tests. I
>> propose that we come up with a standard style for testing, and I'd also like
>> to see a move towards fluent test extensions (foo.ShouldEqual(bar)) and away
>> from the Assert.That(...) style. The same also goes for mocking - we have
>> some places using the old record/replay model and others use the new AAA
>> style. I'd like to see everything moved over to the AAA approach.
>> I think it is also important to come up with some guidelines for what
>> should actually be included in the project. Currently I apply pretty much
>> every patch that is submitted unless there's an obvious reason not to.
>> Perhaps we should resurrect the use of the mvccontrib-developers mailing
>> list for discussing patches?
>> Jeremy
So, all the external view engine and external IoC containers are going away?
Together with the client-side validation framework?
Something you are planning to remove has it's own home (Ninject, Spark) but
other things don't (Brail, NVelocity, XsltViewEngine).
Personally the only features of mvccontrib I used were the external view
engines and some Controller Factory, but I never used the rest of the
MvcContrib features. You plan will make me stop using that library.
On Fri, Feb 20, 2009 at 9:07 PM, Eric Hexter <eric.hex...@gmail.com> wrote:
> As we get close to the release of the Asp.Net mvc framework it is time to
> take a look at what the contrib project has grown into organically and match
> that up with what we want to get out of the project to make sure everything
> is aligning.
> The goals of the project:
> *Ease of use/adoption:* We want to position the MvcContrib project so that
> it is easy for someone new to the ASP.Net MVC framework to include and use
> the MvcContrib functionality. The goal here is for frictionless and
> painless adoption.
> *Drive to conventions:* We want to provide some opinions on how we think
> the framework should be used. This means making the conventions easy to
> discover and use.
> *Provide nice to have functionality: *We are also willing to allow for
> some features that are infrequently used to still be easy to access, but
> this must be balanced with the first two goals.
> So, that leads us to the question of why are we bringing this up and what
> does that mean?
> We do see the MvcContrib project site being a central place to look for
> alternative implementations. We may not host all of these in our project,
> but we could at least list all of them, view engines and IoC, than have
> links to their project homepages. I see a lot of value in maintaining a
> complete list of known extensions.
> Here is a list of actions we want to take on the code base to support the
> goal.
> 1. Consolidate the existing mvc projects/assemblies down to four (4)
> projects.
> · MvcContrib
> · MvcContrib.Extras
> · MvcContrib.TestHelpers
> · MvcContrib.UnitTests
> 2. Add a dependency on the CommonServiceLocator to replace all of
> the IoC containers in the MvcContrib project.
> 3. Remove old dependencies that are available in their home
> projects:
> · Ninject
> · StructureMap – provide links to the CSL implementation
> · Unity – provide links to the CSL implementation
> · Castle / Windsor – the Controller register could be pulled into
> documentation on the contrib project website.
> · Spark – It is being maintained as a separate project, we should
> be pushing developers to it home page to get the most recent version of the
> project.
> 4. Deprecate and remove the following projects:
> · Xslt View Engine
> · Nvelocity
> · Brail
> · Spring
> At this point I would like to open up the discussion. Please make it know
> if you are relying on any of the functionality that is planned for removal.
My biggest concern with the MvcContrib project is that the binary release
contains 157 dlls in the zip file. While I know which dependencies I am
using in my projects, this is an insane amount of assemblies. Combine that
with the fact that this Open Source project suffers from the problem of
incomplete documentation and I think that we are really hurting producing a
high friction solution, that will reduce the adoption of the project.
As far as the IoC controllers, one of the ideas that was kicked around was
perhaps documenting what the ControllerFactory implementations for each
container look like. In most cases, the ControllerFactories are actually
pretty light and when you weigh that we could provide the same benefit and
not care around and have to maintain/update the project each time a single
container has a new version, it would really be better, IMHO, to provide
guidance through documentation rather than implementations for each
container. Thoughts?
My biggest concern with the view engines is that they are not really being
maintained by anyone. There were originally ported, but no one has taken
ownership over the engines. The engines that have moved out
into separate projects.... like Spark have developed a life of their own
including Visual Studio support. Don't get me wrong, if there is
an audience for some of the view engines I am willing to work out something
that could meet the needs of the project while still leaving some option for
the alternatives. I am really proposing that we let the view engine that
has risen to the top live free and let the one on life support (XSLT) go on
to a better place. The real question is what should we do for the view
engines like brail and nvelocity?. There is a small segment that uses them
but most people are not.
I am glad to here from everyone so far and hope to hear from some people so
that we can make some well informed decisions.
Eric Hexter
Principal Consultant
Headspring Systems | www.HeadspringSystems.com email: ehex...@HeadspringSystems.com
blog: Hex.LosTechies.com
--------------------------------------------------------------------------- ----------------------------------
Director - Austin .Net Users Group | www.ADNUG.org Membership Mentor South Texas - INETA | www.INETA.org Asp Insider | www.ASPInsiders.com
On Fri, Feb 20, 2009 at 4:43 PM, Bill Pierce <wcpie...@gmail.com> wrote:
> I don't thinks its been made clear why we need to slim down MvcContrib
> or why we need to be a little more picky about applying patches. I
> acknowledge the three goals and to the best of my knowledge we meeting
> those goals. Is there evidence to the contrary? If we were to drive
> to more conventionality we would ship with one IoC implementation
> (with the ability for you to substitute your own) and one view engine
> (with the ability for you to substitute your own) and one Controller
> implementation (with the ability to substitute your own) and one...
> If anything removing the current dependencies will make it more
> difficult to adopt MvcContrib because now you will have to shop around
> for CSL implementations that fit your needs for the IoC of your
> choice.
> I second the high praise for Jeremy.
> On Fri, Feb 20, 2009 at 12:59 PM, Jeffrey Palermo
> <jeffreypale...@gmail.com> wrote:
> > Jeremy,
> > (and for everyone listening)
> > You have been key to the success of MvcContrib up to this point. You
> have
> > been so responsive in applying patches and upgrading the project. THANK
> YOU
> > for all your hard work. You are an asset to this project.
> > We need to start being a little more picky about what we include, so Eric
> > and I are trying to flesh out a strategy for market adoption. I'm glad
> you
> > are part of this discussion because you have been the most active
> committer
> > on MvcContrib.
> > Let's get opinions from everyone for about a week and then we (you, me
> and
> > Eric) can decide what course of action to take.
> > Best regards,
> > Jeffrey Palermo, Microsoft MVP, MCSD.Net
> > CTO, Headspring Systems
> > agile. software. consulting.
> > 512-459-2260 x 712
> > On Fri, Feb 20, 2009 at 2:43 PM, Jeremy Skinner <
> jer...@jeremyskinner.co.uk>
> > wrote:
> >> Some thoughts...
> >> > Add a dependency on the CommonServiceLocator to replace all of the IoC
> >> > containers in the MvcContrib project.
> >> As I've mentioned in the past, swapping the current controller factory
> >> implementations for one based on the CSL is not as simple as it seems as
> the
> >> CSL does not support releasing components (so it is not possible to
> >> implement IControllerFactory.ReleaseController properly). This can be
> >> mitigated with the use of child containers which can be disposed at the
> end
> >> of a request, but this is adding an extra level of complexity. I guess
> the
> >> question is: is having a leaner codebase worth the extra complexity and
> >> higher learning curve? Personally I'm OK with this, but I'm thinking of
> new
> >> users in particular who are not as familiar with the specifics of the
> >> various containers.
> >> > So FluentHTML would be going where?
> >> You could easily turn FluentHTML into a separate project entirely (I
> >> believe it was separate originally?) as it has no dependencies on
> >> MvcContrib. Personally, I much prefer having several smaller projects
> that
> >> can be mixed and matched rather than one mammoth 'one contrib to rule
> them
> >> all'. I'd particularly like to hear Tim's thoughts on this...
> >> > Deprecate and remove the following projects: Nvelocity, Brail
> >> Is this really a good idea? I know several people use these and there
> are
> >> no alternative implementations out there. The version of Brail in the
> Castle
> >> trunk is completely incompatible with aspnetmvc. Again, these could be
> moved
> >> to separate projects if there was someone willing to maintain them, but
> I'm
> >> not sure that getting rid of them completely is necessarily wise if
> there
> >> are people using them.
> >> Other thoughts...
> >> There are several different styles used for naming/writing tests. I
> >> propose that we come up with a standard style for testing, and I'd also
> like
> >> to see a move towards fluent test extensions (foo.ShouldEqual(bar)) and
> away
> >> from the Assert.That(...) style. The same also goes for mocking - we
> have
> >> some places using the old record/replay model and others use the new AAA
> >> style. I'd like to see everything moved over to the AAA approach.
> >> I think it is also important to come up with some guidelines for what
> >> should actually be included in the project. Currently I apply pretty
> much
> >> every patch that is submitted unless there's an obvious reason not to.
> >> Perhaps we should resurrect the use of the mvccontrib-developers mailing
> >> list for discussing patches?
> >> Jeremy
Simone,
Thanks for the head-up. We are putting out this message so that lots of
people can provide feedback. We will not act hastily, and we want to do
what is best for everyone. The main goal is to make the primary
distribution of one assembly: mvccontrib.dll. We want to make adoption be
a single assembly. Nice and simple.
Right now the distribution is lots of assemblies, so we want to have two
levels. The first is the just the main mvccontrib.dll. The second is the
larger distro with mvccontrib.extras.dll. It's very conceivable that all
the view engines remain and the controller factories remain and are
consolidated to mvccontrib.extras.dll or perhaps some more to manage
dependencies.
Please continue to provide feedback as to what parts of MvcContrib are most
important to you.
Best regards,
Jeffrey Palermo, Microsoft MVP, MCSD.Net
CTO, Headspring Systems
agile. software. consulting.
512-459-2260 x 712
On Fri, Feb 20, 2009 at 4:54 PM, Simone Chiaretta <
simone.chiare...@gmail.com> wrote:
> So, all the external view engine and external IoC containers are going
> away? Together with the client-side validation framework?
> Something you are planning to remove has it's own home (Ninject, Spark) but
> other things don't (Brail, NVelocity, XsltViewEngine).
> Personally the only features of mvccontrib I used were the external view
> engines and some Controller Factory, but I never used the rest of the
> MvcContrib features. You plan will make me stop using that library.
> Simone
> On Fri, Feb 20, 2009 at 9:07 PM, Eric Hexter <eric.hex...@gmail.com>wrote:
>> As we get close to the release of the Asp.Net mvc framework it is time to
>> take a look at what the contrib project has grown into organically and match
>> that up with what we want to get out of the project to make sure everything
>> is aligning.
>> The goals of the project:
>> *Ease of use/adoption:* We want to position the MvcContrib project so
>> that it is easy for someone new to the ASP.Net MVC framework to include and
>> use the MvcContrib functionality. The goal here is for frictionless
>> and painless adoption.
>> *Drive to conventions:* We want to provide some opinions on how we think
>> the framework should be used. This means making the conventions easy to
>> discover and use.
>> *Provide nice to have functionality: *We are also willing to allow for
>> some features that are infrequently used to still be easy to access, but
>> this must be balanced with the first two goals.
>> So, that leads us to the question of why are we bringing this up and what
>> does that mean?
>> We do see the MvcContrib project site being a central place to look for
>> alternative implementations. We may not host all of these in our
>> project, but we could at least list all of them, view engines and IoC, than
>> have links to their project homepages. I see a lot of value in
>> maintaining a complete list of known extensions.
>> Here is a list of actions we want to take on the code base to support the
>> goal.
>> 1. Consolidate the existing mvc projects/assemblies down to four
>> (4) projects.
>> · MvcContrib
>> · MvcContrib.Extras
>> · MvcContrib.TestHelpers
>> · MvcContrib.UnitTests
>> 2. Add a dependency on the CommonServiceLocator to replace all of
>> the IoC containers in the MvcContrib project.
>> 3. Remove old dependencies that are available in their home
>> projects:
>> · Ninject
>> · StructureMap – provide links to the CSL implementation
>> · Unity – provide links to the CSL implementation
>> · Castle / Windsor – the Controller register could be pulled into
>> documentation on the contrib project website.
>> · Spark – It is being maintained as a separate project, we should
>> be pushing developers to it home page to get the most recent version of the
>> project.
>> 4. Deprecate and remove the following projects:
>> · Xslt View Engine
>> · Nvelocity
>> · Brail
>> · Spring
>> At this point I would like to open up the discussion. Please make it know
>> if you are relying on any of the functionality that is planned for removal.
How do you feel about ILMerging the futures project (Microsoft.Web.Mvc) with mvccontrib? That could provide more functionality while ultimately reduce dll sprawl ? I would need to look into the licensing of that project but those are some of the ideas I would like to explore.
I think it all comes to which market you as team want to address.
My opinion is that you should go on maintaining only the parts of mvccontrib
that are enhancements to the framework itself. I think this probably was not
the original idea of the project (which was, correct me if I'm wrong, to
provide the glue between ASP.NET MVC and the ecosystem of opensource project
that can be integrated with it) but is the best way to go on from here.
*IoC Containers*
I've not idea what the CSL is and how it is different from each specific
implementation. Personally I use Ninject, and this has its own
ControllerFactory.
*View Engines*
I agree that some view engines are used less than others, and the most used
ones are already going on their own feet (NHaml and Spark). And that the
XSLT view engine, even if pretty cool as idea, requires a lot of work on the
controller to prepare the view model on purpose for the engine.
Brail and NVelocity are good engines and, expecially NVelocity, they have
nice things that other miss. The only thing I can think of is asking to the
Castle Project to include the support for ASP.NET MVC inside their project.
*FluentHTML and other HtmlHelpers
*I personally prefer to use angle brackets to design my html, but I agree
that some of the htmlhelpers (the grid for example) and the client-side
validation are popular features.
*One last thing: Documentation*
I think that one thing that is missing now, and that IMHO is the most
important one, is documentation. Now if someone want to see what's inside
MvcContrib it has to download the bits and look at the methods available.
And even when they find the features, there is no easy way to understand how
to use them.
Simo
On Sat, Feb 21, 2009 at 5:26 AM, Jeffrey Palermo
<jeffreypale...@gmail.com>wrote:
> Simone,
> Thanks for the head-up. We are putting out this message so that lots of
> people can provide feedback. We will not act hastily, and we want to do
> what is best for everyone. The main goal is to make the primary
> distribution of one assembly: mvccontrib.dll. We want to make adoption be
> a single assembly. Nice and simple.
> Right now the distribution is lots of assemblies, so we want to have two
> levels. The first is the just the main mvccontrib.dll. The second is the
> larger distro with mvccontrib.extras.dll. It's very conceivable that all
> the view engines remain and the controller factories remain and are
> consolidated to mvccontrib.extras.dll or perhaps some more to manage
> dependencies.
> Please continue to provide feedback as to what parts of MvcContrib are most
> important to you.
> Best regards,
> Jeffrey Palermo, Microsoft MVP, MCSD.Net
> CTO, Headspring Systems
> agile. software. consulting.
> 512-459-2260 x 712
> On Fri, Feb 20, 2009 at 4:54 PM, Simone Chiaretta <
> simone.chiare...@gmail.com> wrote:
>> So, all the external view engine and external IoC containers are going
>> away? Together with the client-side validation framework?
>> Something you are planning to remove has it's own home (Ninject, Spark)
>> but other things don't (Brail, NVelocity, XsltViewEngine).
>> Personally the only features of mvccontrib I used were the external view
>> engines and some Controller Factory, but I never used the rest of the
>> MvcContrib features. You plan will make me stop using that library.
>> Simone
>> On Fri, Feb 20, 2009 at 9:07 PM, Eric Hexter <eric.hex...@gmail.com>wrote:
>>> As we get close to the release of the Asp.Net mvc framework it is time to
>>> take a look at what the contrib project has grown into organically and match
>>> that up with what we want to get out of the project to make sure everything
>>> is aligning.
>>> The goals of the project:
>>> *Ease of use/adoption:* We want to position the MvcContrib project so
>>> that it is easy for someone new to the ASP.Net MVC framework to include and
>>> use the MvcContrib functionality. The goal here is for frictionless
>>> and painless adoption.
>>> *Drive to conventions:* We want to provide some opinions on how we think
>>> the framework should be used. This means making the conventions easy
>>> to discover and use.
>>> *Provide nice to have functionality: *We are also willing to allow for
>>> some features that are infrequently used to still be easy to access, but
>>> this must be balanced with the first two goals.
>>> So, that leads us to the question of why are we bringing this up and what
>>> does that mean?
>>> We do see the MvcContrib project site being a central place to look for
>>> alternative implementations. We may not host all of these in our
>>> project, but we could at least list all of them, view engines and IoC, than
>>> have links to their project homepages. I see a lot of value in
>>> maintaining a complete list of known extensions.
>>> Here is a list of actions we want to take on the code base to support the
>>> goal.
>>> 1. Consolidate the existing mvc projects/assemblies down to four
>>> (4) projects.
>>> · MvcContrib
>>> · MvcContrib.Extras
>>> · MvcContrib.TestHelpers
>>> · MvcContrib.UnitTests
>>> 2. Add a dependency on the CommonServiceLocator to replace all of
>>> the IoC containers in the MvcContrib project.
>>> 3. Remove old dependencies that are available in their home
>>> projects:
>>> · Ninject
>>> · StructureMap – provide links to the CSL implementation
>>> · Unity – provide links to the CSL implementation
>>> · Castle / Windsor – the Controller register could be pulled
>>> into documentation on the contrib project website.
>>> · Spark – It is being maintained as a separate project, we
>>> should be pushing developers to it home page to get the most recent version
>>> of the project.
>>> 4. Deprecate and remove the following projects:
>>> · Xslt View Engine
>>> · Nvelocity
>>> · Brail
>>> · Spring
>>> At this point I would like to open up the discussion. Please make it know
>>> if you are relying on any of the functionality that is planned for removal.
Hello, all!
I'm not a current user of asp.net mvc (django here yay!) but I am
looking forward to it!
I read some of the points made here and have some thoughts about them:
-Regarding the view engines. I hope they stay. This is one of the
reasons I am even considering this framework. If only asp%>ugly stays
that would be horrible!
-Regarding the support/maintenance/ownership of the view engines: I
think you need to give it time. I mean there are already about 4 !!
books pending about mvc.net! I am still waiting for them to come until
really diving into the framework. Removing some components so early on
will probably decrease my enthusiasm for getting involved later on.
-Same goes for "Documentation". You need to get people understanding
the framework first (i.e. release, publish book, etc..).
I say leave and add but don't remove! But I am probably not very
qualified to put in my 5c.
On Feb 21, 11:53 am, Simone Chiaretta <simone.chiare...@gmail.com>
wrote:
> I think it all comes to which market you as team want to address.
> My opinion is that you should go on maintaining only the parts of mvccontrib
> that are enhancements to the framework itself. I think this probably was not
> the original idea of the project (which was, correct me if I'm wrong, to
> provide the glue between ASP.NET MVC and the ecosystem of opensource project
> that can be integrated with it) but is the best way to go on from here.
> *IoC Containers*
> I've not idea what the CSL is and how it is different from each specific
> implementation. Personally I use Ninject, and this has its own
> ControllerFactory.
> *View Engines*
> I agree that some view engines are used less than others, and the most used
> ones are already going on their own feet (NHaml and Spark). And that the
> XSLT view engine, even if pretty cool as idea, requires a lot of work on the
> controller to prepare the view model on purpose for the engine.
> Brail and NVelocity are good engines and, expecially NVelocity, they have
> nice things that other miss. The only thing I can think of is asking to the
> Castle Project to include the support for ASP.NET MVC inside their project.
> *FluentHTML and other HtmlHelpers
> *I personally prefer to use angle brackets to design my html, but I agree
> that some of the htmlhelpers (the grid for example) and the client-side
> validation are popular features.
> *One last thing: Documentation*
> I think that one thing that is missing now, and that IMHO is the most
> important one, is documentation. Now if someone want to see what's inside
> MvcContrib it has to download the bits and look at the methods available.
> And even when they find the features, there is no easy way to understand how
> to use them.
> Simo
> On Sat, Feb 21, 2009 at 5:26 AM, Jeffrey Palermo
> <jeffreypale...@gmail.com>wrote:
> > Simone,
> > Thanks for the head-up. We are putting out this message so that lots of
> > people can provide feedback. We will not act hastily, and we want to do
> > what is best for everyone. The main goal is to make the primary
> > distribution of one assembly: mvccontrib.dll. We want to make adoption be
> > a single assembly. Nice and simple.
> > Right now the distribution is lots of assemblies, so we want to have two
> > levels. The first is the just the main mvccontrib.dll. The second is the
> > larger distro with mvccontrib.extras.dll. It's very conceivable that all
> > the view engines remain and the controller factories remain and are
> > consolidated to mvccontrib.extras.dll or perhaps some more to manage
> > dependencies.
> > Please continue to provide feedback as to what parts of MvcContrib are most
> > important to you.
> > Best regards,
> > Jeffrey Palermo, Microsoft MVP, MCSD.Net
> > CTO, Headspring Systems
> > agile. software. consulting.
> > 512-459-2260 x 712
> > On Fri, Feb 20, 2009 at 4:54 PM, Simone Chiaretta <
> > simone.chiare...@gmail.com> wrote:
> >> So, all the external view engine and external IoC containers are going
> >> away? Together with the client-side validation framework?
> >> Something you are planning to remove has it's own home (Ninject, Spark)
> >> but other things don't (Brail, NVelocity, XsltViewEngine).
> >> Personally the only features of mvccontrib I used were the external view
> >> engines and some Controller Factory, but I never used the rest of the
> >> MvcContrib features. You plan will make me stop using that library.
> >> Simone
> >> On Fri, Feb 20, 2009 at 9:07 PM, Eric Hexter <eric.hex...@gmail.com>wrote:
> >>> As we get close to the release of the Asp.Net mvc framework it is time to
> >>> take a look at what the contrib project has grown into organically and match
> >>> that up with what we want to get out of the project to make sure everything
> >>> is aligning.
> >>> The goals of the project:
> >>> *Ease of use/adoption:* We want to position the MvcContrib project so
> >>> that it is easy for someone new to the ASP.Net MVC framework to include and
> >>> use the MvcContrib functionality. The goal here is for frictionless
> >>> and painless adoption.
> >>> *Drive to conventions:* We want to provide some opinions on how we think
> >>> the framework should be used. This means making the conventions easy
> >>> to discover and use.
> >>> *Provide nice to have functionality: *We are also willing to allow for
> >>> some features that are infrequently used to still be easy to access, but
> >>> this must be balanced with the first two goals.
> >>> So, that leads us to the question of why are we bringing this up and what
> >>> does that mean?
> >>> We do see the MvcContrib project site being a central place to look for
> >>> alternative implementations. We may not host all of these in our
> >>> project, but we could at least list all of them, view engines and IoC, than
> >>> have links to their project homepages. I see a lot of value in
> >>> maintaining a complete list of known extensions.
> >>> Here is a list of actions we want to take on the code base to support the
> >>> goal.
> >>> 1. Consolidate the existing mvc projects/assemblies down to four
> >>> (4) projects.
> >>> · MvcContrib
> >>> · MvcContrib.Extras
> >>> · MvcContrib.TestHelpers
> >>> · MvcContrib.UnitTests
> >>> 2. Add a dependency on the CommonServiceLocator to replace all of
> >>> the IoC containers in the MvcContrib project.
> >>> 3. Remove old dependencies that are available in their home
> >>> projects:
> >>> · Ninject
> >>> · StructureMap – provide links to the CSL implementation
> >>> · Unity – provide links to the CSL implementation
> >>> · Castle / Windsor – the Controller register could be pulled
> >>> into documentation on the contrib project website.
> >>> · Spark – It is being maintained as a separate project, we
> >>> should be pushing developers to it home page to get the most recent version
> >>> of the project.
> >>> 4. Deprecate and remove the following projects:
> >>> · Xslt View Engine
> >>> · Nvelocity
> >>> · Brail
> >>> · Spring
> >>> At this point I would like to open up the discussion. Please make it know
> >>> if you are relying on any of the functionality that is planned for removal.
I'm using MvcContrib in all my projects. There are many so useful
features in it ;). Thanks for good addition to MVC framework!
And my 5c:
@Eric, I'm sure that merging mvc futures is not a good idea. And I
really don't know which useful functionality will be provided in this
case. One dll less? And what about cases when someone wants update
MvcContrib assembly without updating MvcFutures assembly or update
MvcFutures without MvcContrib?
>>1. Consolidate the existing mvc projects/assemblies down to four (4)
projects.
I suggest to add one more assembly for additional view engines.
>>2. Add a dependency on the CommonServiceLocator to replace all of the
IoC containers in the MvcContrib project.
>>3. Remove old dependencies that are available in their home projects
I agree.
>>4. Deprecate and remove the following projects
I suggest to move engines which have no alternative implementation to
separate project or assembly ("MvcContrib.ViewEngines" for example)
and try to find someone willing to maintain them or mark them as not
maintained. They may be useful as a sample of implementation of the
view engines too. For engines which have alternative implementations
links to home pages should be added in documentation or readme.
FluentHtml, I suggest to move it to MvcContrib.Extras or
MvcContrib.FluentHtml. And I have no really good arguments for this
but I think so.
Also I agree with Jeremy about adding guidelines and standards and
mvccontrib-developers mailing list.
And one more, as I think MvcContrib needs in a more good documentation
(hope this will be included in guideline for patches).
I'm a new user of MvcContrib, and the amount of DLLs was quite staggering
:) I'd love to see something like what Java Spring has - a text document
saying if you use this assembly, you need to bring along these assemblies.
That allowed me to pick and choose what parts of Spring I wanted to use
without dragging in Web MVC stuff, security stuff, etc. that I knew I wasn't
going ot use (and didn't want in memory).
As for IoC, I like your idea. Documenting is better than another
abstraction. MVC has the ControllerFactory abstraction which is pretty
trivial to implement. Writing a CLS implementation for it just complicates
the matter because now I've got to wonder if my container has a CLS
implementation. And what value does a CLS implementation add that a
specific container implementation doesn't? It's an abstraction that doesn't
buy me anything.
As for view engines, I personally feel those are up to the technology (i.e.
NHaml). Maybe MvcContrib can work with Brail and NVelocity to contribute
the view engines back to them? That's where they live. What I'd like to
see from MvcContrib is new view engines or taking the VB.NET one and
solidifying it (I'm enamored with the strongly typed XML approach of VB.NET
).
On Fri, Feb 20, 2009 at 8:23 PM, Eric Hexter <eric.hex...@gmail.com> wrote:
> My biggest concern with the MvcContrib project is that the binary release
> contains 157 dlls in the zip file. While I know which dependencies I am
> using in my projects, this is an insane amount of assemblies. Combine that
> with the fact that this Open Source project suffers from the problem of
> incomplete documentation and I think that we are really hurting producing a
> high friction solution, that will reduce the adoption of the project.
> As far as the IoC controllers, one of the ideas that was kicked around was
> perhaps documenting what the ControllerFactory implementations for each
> container look like. In most cases, the ControllerFactories are actually
> pretty light and when you weigh that we could provide the same benefit and
> not care around and have to maintain/update the project each time a single
> container has a new version, it would really be better, IMHO, to provide
> guidance through documentation rather than implementations for each
> container. Thoughts?
> My biggest concern with the view engines is that they are not really being
> maintained by anyone. There were originally ported, but no one has taken
> ownership over the engines. The engines that have moved out
> into separate projects.... like Spark have developed a life of their own
> including Visual Studio support. Don't get me wrong, if there is
> an audience for some of the view engines I am willing to work out something
> that could meet the needs of the project while still leaving some option for
> the alternatives. I am really proposing that we let the view engine that
> has risen to the top live free and let the one on life support (XSLT) go on
> to a better place. The real question is what should we do for the view
> engines like brail and nvelocity?. There is a small segment that uses them
> but most people are not.
> I am glad to here from everyone so far and hope to hear from some people so
> that we can make some well informed decisions.
> Eric Hexter
> Principal Consultant
> Headspring Systems | www.HeadspringSystems.com > email: ehex...@HeadspringSystems.com
> blog: Hex.LosTechies.com
> --------------------------------------------------------------------------- ----------------------------------
> Director - Austin .Net Users Group | www.ADNUG.org > Membership Mentor South Texas - INETA | www.INETA.org > Asp Insider | www.ASPInsiders.com
> On Fri, Feb 20, 2009 at 4:43 PM, Bill Pierce <wcpie...@gmail.com> wrote:
>> I don't thinks its been made clear why we need to slim down MvcContrib
>> or why we need to be a little more picky about applying patches. I
>> acknowledge the three goals and to the best of my knowledge we meeting
>> those goals. Is there evidence to the contrary? If we were to drive
>> to more conventionality we would ship with one IoC implementation
>> (with the ability for you to substitute your own) and one view engine
>> (with the ability for you to substitute your own) and one Controller
>> implementation (with the ability to substitute your own) and one...
>> If anything removing the current dependencies will make it more
>> difficult to adopt MvcContrib because now you will have to shop around
>> for CSL implementations that fit your needs for the IoC of your
>> choice.
>> I second the high praise for Jeremy.
>> On Fri, Feb 20, 2009 at 12:59 PM, Jeffrey Palermo
>> <jeffreypale...@gmail.com> wrote:
>> > Jeremy,
>> > (and for everyone listening)
>> > You have been key to the success of MvcContrib up to this point. You
>> have
>> > been so responsive in applying patches and upgrading the project. THANK
>> YOU
>> > for all your hard work. You are an asset to this project.
>> > We need to start being a little more picky about what we include, so
>> Eric
>> > and I are trying to flesh out a strategy for market adoption. I'm glad
>> you
>> > are part of this discussion because you have been the most active
>> committer
>> > on MvcContrib.
>> > Let's get opinions from everyone for about a week and then we (you, me
>> and
>> > Eric) can decide what course of action to take.
>> > Best regards,
>> > Jeffrey Palermo, Microsoft MVP, MCSD.Net
>> > CTO, Headspring Systems
>> > agile. software. consulting.
>> > 512-459-2260 x 712
>> > On Fri, Feb 20, 2009 at 2:43 PM, Jeremy Skinner <
>> jer...@jeremyskinner.co.uk>
>> > wrote:
>> >> Some thoughts...
>> >> > Add a dependency on the CommonServiceLocator to replace all of the
>> IoC
>> >> > containers in the MvcContrib project.
>> >> As I've mentioned in the past, swapping the current controller factory
>> >> implementations for one based on the CSL is not as simple as it seems
>> as the
>> >> CSL does not support releasing components (so it is not possible to
>> >> implement IControllerFactory.ReleaseController properly). This can be
>> >> mitigated with the use of child containers which can be disposed at the
>> end
>> >> of a request, but this is adding an extra level of complexity. I guess
>> the
>> >> question is: is having a leaner codebase worth the extra complexity and
>> >> higher learning curve? Personally I'm OK with this, but I'm thinking of
>> new
>> >> users in particular who are not as familiar with the specifics of the
>> >> various containers.
>> >> > So FluentHTML would be going where?
>> >> You could easily turn FluentHTML into a separate project entirely (I
>> >> believe it was separate originally?) as it has no dependencies on
>> >> MvcContrib. Personally, I much prefer having several smaller projects
>> that
>> >> can be mixed and matched rather than one mammoth 'one contrib to rule
>> them
>> >> all'. I'd particularly like to hear Tim's thoughts on this...
>> >> > Deprecate and remove the following projects: Nvelocity, Brail
>> >> Is this really a good idea? I know several people use these and there
>> are
>> >> no alternative implementations out there. The version of Brail in the
>> Castle
>> >> trunk is completely incompatible with aspnetmvc. Again, these could be
>> moved
>> >> to separate projects if there was someone willing to maintain them, but
>> I'm
>> >> not sure that getting rid of them completely is necessarily wise if
>> there
>> >> are people using them.
>> >> Other thoughts...
>> >> There are several different styles used for naming/writing tests. I
>> >> propose that we come up with a standard style for testing, and I'd also
>> like
>> >> to see a move towards fluent test extensions (foo.ShouldEqual(bar)) and
>> away
>> >> from the Assert.That(...) style. The same also goes for mocking - we
>> have
>> >> some places using the old record/replay model and others use the new
>> AAA
>> >> style. I'd like to see everything moved over to the AAA approach.
>> >> I think it is also important to come up with some guidelines for what
>> >> should actually be included in the project. Currently I apply pretty
>> much
>> >> every patch that is submitted unless there's an obvious reason not to.
>> >> Perhaps we should resurrect the use of the mvccontrib-developers
>> mailing
>> >> list for discussing patches?
>> >> Jeremy
So from the feedback I am thinking that rather than limiting the number of
Projects in contrib. It would make more sense to look at how we release the
binaries and source. I am just typing this as I think through it but an
option to help reduce the friction for the main mvc bits that do not have
dependencies on 3rd party libraries.
How do you feel about having the following Binary Releases:
MvcContrib - Contains MvcContrib & MvcContrib.TestHelpers assemblies.
MvcContrib.Extras - Contains ViewEngines / Other less used/maintained
features. This would come in the form of many dlls and some better
documentation on what dependencies are required for each dell in the extras
folder.
The project would still contain the unit tests and this may be split into
tests that support the Contrib vs Extra releases. We could possibly split
the project so that it has a separate trunk for the Extras.
I really think leaning towards hosting IoC Controller factory samples on the
wiki and maybe links to source code implementations for each IoC
implementation would be better than providing separate dlls and
implementations for each IoC container. how do you feel about this? We
could still maintain those in source code but they would not be part of a
build of any kind.
Thoughts?
Thanks,
Eric
Eric Hexter
Principal Consultant
Headspring Systems | www.HeadspringSystems.com email: ehex...@HeadspringSystems.com
blog: Hex.LosTechies.com
--------------------------------------------------------------------------- ----------------------------------
Director - Austin .Net Users Group | www.ADNUG.org Membership Mentor South Texas - INETA | www.INETA.org Asp Insider | www.ASPInsiders.com
On Mon, Feb 23, 2009 at 12:53 PM, Justin Rudd <justin.r...@gmail.com> wrote:
> I'm a new user of MvcContrib, and the amount of DLLs was quite staggering
> :) I'd love to see something like what Java Spring has - a text document
> saying if you use this assembly, you need to bring along these assemblies.
> That allowed me to pick and choose what parts of Spring I wanted to use
> without dragging in Web MVC stuff, security stuff, etc. that I knew I wasn't
> going ot use (and didn't want in memory).
> As for IoC, I like your idea. Documenting is better than another
> abstraction. MVC has the ControllerFactory abstraction which is pretty
> trivial to implement. Writing a CLS implementation for it just complicates
> the matter because now I've got to wonder if my container has a CLS
> implementation. And what value does a CLS implementation add that a
> specific container implementation doesn't? It's an abstraction that doesn't
> buy me anything.
> As for view engines, I personally feel those are up to the technology (i.e.
> NHaml). Maybe MvcContrib can work with Brail and NVelocity to contribute
> the view engines back to them? That's where they live. What I'd like to
> see from MvcContrib is new view engines or taking the VB.NET one and
> solidifying it (I'm enamored with the strongly typed XML approach of
> VB.NET).
> On Fri, Feb 20, 2009 at 8:23 PM, Eric Hexter <eric.hex...@gmail.com>wrote:
>> My biggest concern with the MvcContrib project is that the binary release
>> contains 157 dlls in the zip file. While I know which dependencies I am
>> using in my projects, this is an insane amount of assemblies. Combine that
>> with the fact that this Open Source project suffers from the problem of
>> incomplete documentation and I think that we are really hurting producing a
>> high friction solution, that will reduce the adoption of the project.
>> As far as the IoC controllers, one of the ideas that was kicked around was
>> perhaps documenting what the ControllerFactory implementations for each
>> container look like. In most cases, the ControllerFactories are actually
>> pretty light and when you weigh that we could provide the same benefit and
>> not care around and have to maintain/update the project each time a single
>> container has a new version, it would really be better, IMHO, to provide
>> guidance through documentation rather than implementations for each
>> container. Thoughts?
>> My biggest concern with the view engines is that they are not really being
>> maintained by anyone. There were originally ported, but no one has taken
>> ownership over the engines. The engines that have moved out
>> into separate projects.... like Spark have developed a life of their own
>> including Visual Studio support. Don't get me wrong, if there is
>> an audience for some of the view engines I am willing to work out something
>> that could meet the needs of the project while still leaving some option for
>> the alternatives. I am really proposing that we let the view engine that
>> has risen to the top live free and let the one on life support (XSLT) go on
>> to a better place. The real question is what should we do for the view
>> engines like brail and nvelocity?. There is a small segment that uses them
>> but most people are not.
>> I am glad to here from everyone so far and hope to hear from some people
>> so that we can make some well informed decisions.
>> Eric Hexter
>> Principal Consultant
>> Headspring Systems | www.HeadspringSystems.com >> email: ehex...@HeadspringSystems.com
>> blog: Hex.LosTechies.com
>> --------------------------------------------------------------------------- ----------------------------------
>> Director - Austin .Net Users Group | www.ADNUG.org >> Membership Mentor South Texas - INETA | www.INETA.org >> Asp Insider | www.ASPInsiders.com
>> On Fri, Feb 20, 2009 at 4:43 PM, Bill Pierce <wcpie...@gmail.com> wrote:
>>> I don't thinks its been made clear why we need to slim down MvcContrib
>>> or why we need to be a little more picky about applying patches. I
>>> acknowledge the three goals and to the best of my knowledge we meeting
>>> those goals. Is there evidence to the contrary? If we were to drive
>>> to more conventionality we would ship with one IoC implementation
>>> (with the ability for you to substitute your own) and one view engine
>>> (with the ability for you to substitute your own) and one Controller
>>> implementation (with the ability to substitute your own) and one...
>>> If anything removing the current dependencies will make it more
>>> difficult to adopt MvcContrib because now you will have to shop around
>>> for CSL implementations that fit your needs for the IoC of your
>>> choice.
>>> I second the high praise for Jeremy.
>>> On Fri, Feb 20, 2009 at 12:59 PM, Jeffrey Palermo
>>> <jeffreypale...@gmail.com> wrote:
>>> > Jeremy,
>>> > (and for everyone listening)
>>> > You have been key to the success of MvcContrib up to this point. You
>>> have
>>> > been so responsive in applying patches and upgrading the project.
>>> THANK YOU
>>> > for all your hard work. You are an asset to this project.
>>> > We need to start being a little more picky about what we include, so
>>> Eric
>>> > and I are trying to flesh out a strategy for market adoption. I'm glad
>>> you
>>> > are part of this discussion because you have been the most active
>>> committer
>>> > on MvcContrib.
>>> > Let's get opinions from everyone for about a week and then we (you, me
>>> and
>>> > Eric) can decide what course of action to take.
>>> > Best regards,
>>> > Jeffrey Palermo, Microsoft MVP, MCSD.Net
>>> > CTO, Headspring Systems
>>> > agile. software. consulting.
>>> > 512-459-2260 x 712
>>> > On Fri, Feb 20, 2009 at 2:43 PM, Jeremy Skinner <
>>> jer...@jeremyskinner.co.uk>
>>> > wrote:
>>> >> Some thoughts...
>>> >> > Add a dependency on the CommonServiceLocator to replace all of the
>>> IoC
>>> >> > containers in the MvcContrib project.
>>> >> As I've mentioned in the past, swapping the current controller factory
>>> >> implementations for one based on the CSL is not as simple as it seems
>>> as the
>>> >> CSL does not support releasing components (so it is not possible to
>>> >> implement IControllerFactory.ReleaseController properly). This can be
>>> >> mitigated with the use of child containers which can be disposed at
>>> the end
>>> >> of a request, but this is adding an extra level of complexity. I guess
>>> the
>>> >> question is: is having a leaner codebase worth the extra complexity
>>> and
>>> >> higher learning curve? Personally I'm OK with this, but I'm thinking
>>> of new
>>> >> users in particular who are not as familiar with the specifics of the
>>> >> various containers.
>>> >> > So FluentHTML would be going where?
>>> >> You could easily turn FluentHTML into a separate project entirely (I
>>> >> believe it was separate originally?) as it has no dependencies on
>>> >> MvcContrib. Personally, I much prefer having several smaller projects
>>> that
>>> >> can be mixed and matched rather than one mammoth 'one contrib to rule
>>> them
>>> >> all'. I'd particularly like to hear Tim's thoughts on this...
>>> >> > Deprecate and remove the following projects: Nvelocity, Brail
>>> >> Is this really a good idea? I know several people use these and there
>>> are
>>> >> no alternative implementations out there. The version of Brail in the
>>> Castle
>>> >> trunk is completely incompatible with aspnetmvc. Again, these could be
>>> moved
>>> >> to separate projects if there was someone willing to maintain them,
>>> but I'm
>>> >> not sure that getting rid of them completely is necessarily wise if
>>> there
>>> >> are people using them.
>>> >> Other thoughts...
>>> >> There are several different styles used for naming/writing tests. I
>>> >> propose that we come up with a standard style for testing, and I'd
>>> also like
>>> >> to see a
I like the "extras" approach:
The main dll will be just the enhancements to ASP.NET MVC, with no
dependencies on external libraries (except, of course, for ASP.NET MVC), and
the extra will be anything that has to do with external libs (ViewEngines).
Where in this scenario will FluentValidation and the various HtmlHelpers be
placed? I assume it will be the main assembly.
IoC ControllerFactories are pretty easy, and I think that having the source
code will be enough
On Tue, Feb 24, 2009 at 8:12 PM, Eric Hexter <eric.hex...@gmail.com> wrote:
> So from the feedback I am thinking that rather than limiting the number of
> Projects in contrib. It would make more sense to look at how we release the
> binaries and source. I am just typing this as I think through it but an
> option to help reduce the friction for the main mvc bits that do not have
> dependencies on 3rd party libraries.
> How do you feel about having the following Binary Releases:
> MvcContrib - Contains MvcContrib & MvcContrib.TestHelpers assemblies.
> MvcContrib.Extras - Contains ViewEngines / Other less used/maintained
> features. This would come in the form of many dlls and some better
> documentation on what dependencies are required for each dell in the extras
> folder.
> The project would still contain the unit tests and this may be split into
> tests that support the Contrib vs Extra releases. We could possibly split
> the project so that it has a separate trunk for the Extras.
> I really think leaning towards hosting IoC Controller factory samples on
> the wiki and maybe links to source code implementations for each IoC
> implementation would be better than providing separate dlls and
> implementations for each IoC container. how do you feel about this? We
> could still maintain those in source code but they would not be part of a
> build of any kind.
> Thoughts?
> Thanks,
> Eric
> Eric Hexter
> Principal Consultant
> Headspring Systems | www.HeadspringSystems.com > email: ehex...@HeadspringSystems.com
> blog: Hex.LosTechies.com
> --------------------------------------------------------------------------- ----------------------------------
> Director - Austin .Net Users Group | www.ADNUG.org > Membership Mentor South Texas - INETA | www.INETA.org > Asp Insider | www.ASPInsiders.com
> On Mon, Feb 23, 2009 at 12:53 PM, Justin Rudd <justin.r...@gmail.com>wrote:
>> I'm a new user of MvcContrib, and the amount of DLLs was quite staggering
>> :) I'd love to see something like what Java Spring has - a text document
>> saying if you use this assembly, you need to bring along these assemblies.
>> That allowed me to pick and choose what parts of Spring I wanted to use
>> without dragging in Web MVC stuff, security stuff, etc. that I knew I wasn't
>> going ot use (and didn't want in memory).
>> As for IoC, I like your idea. Documenting is better than another
>> abstraction. MVC has the ControllerFactory abstraction which is pretty
>> trivial to implement. Writing a CLS implementation for it just complicates
>> the matter because now I've got to wonder if my container has a CLS
>> implementation. And what value does a CLS implementation add that a
>> specific container implementation doesn't? It's an abstraction that doesn't
>> buy me anything.
>> As for view engines, I personally feel those are up to the technology
>> (i.e. NHaml). Maybe MvcContrib can work with Brail and NVelocity to
>> contribute the view engines back to them? That's where they live. What I'd
>> like to see from MvcContrib is new view engines or taking the VB.NET one
>> and solidifying it (I'm enamored with the strongly typed XML approach of
>> VB.NET).
>> On Fri, Feb 20, 2009 at 8:23 PM, Eric Hexter <eric.hex...@gmail.com>wrote:
>>> My biggest concern with the MvcContrib project is that the binary release
>>> contains 157 dlls in the zip file. While I know which dependencies I am
>>> using in my projects, this is an insane amount of assemblies. Combine that
>>> with the fact that this Open Source project suffers from the problem of
>>> incomplete documentation and I think that we are really hurting producing a
>>> high friction solution, that will reduce the adoption of the project.
>>> As far as the IoC controllers, one of the ideas that was kicked around
>>> was perhaps documenting what the ControllerFactory implementations for each
>>> container look like. In most cases, the ControllerFactories are actually
>>> pretty light and when you weigh that we could provide the same benefit and
>>> not care around and have to maintain/update the project each time a single
>>> container has a new version, it would really be better, IMHO, to provide
>>> guidance through documentation rather than implementations for each
>>> container. Thoughts?
>>> My biggest concern with the view engines is that they are not really
>>> being maintained by anyone. There were originally ported, but no one has
>>> taken ownership over the engines. The engines that have moved out
>>> into separate projects.... like Spark have developed a life of their own
>>> including Visual Studio support. Don't get me wrong, if there is
>>> an audience for some of the view engines I am willing to work out something
>>> that could meet the needs of the project while still leaving some option for
>>> the alternatives. I am really proposing that we let the view engine that
>>> has risen to the top live free and let the one on life support (XSLT) go on
>>> to a better place. The real question is what should we do for the view
>>> engines like brail and nvelocity?. There is a small segment that uses them
>>> but most people are not.
>>> I am glad to here from everyone so far and hope to hear from some people
>>> so that we can make some well informed decisions.
>>> Eric Hexter
>>> Principal Consultant
>>> Headspring Systems | www.HeadspringSystems.com >>> email: ehex...@HeadspringSystems.com
>>> blog: Hex.LosTechies.com
>>> --------------------------------------------------------------------------- ----------------------------------
>>> Director - Austin .Net Users Group | www.ADNUG.org >>> Membership Mentor South Texas - INETA | www.INETA.org >>> Asp Insider | www.ASPInsiders.com
>>> On Fri, Feb 20, 2009 at 4:43 PM, Bill Pierce <wcpie...@gmail.com> wrote:
>>>> I don't thinks its been made clear why we need to slim down MvcContrib
>>>> or why we need to be a little more picky about applying patches. I
>>>> acknowledge the three goals and to the best of my knowledge we meeting
>>>> those goals. Is there evidence to the contrary? If we were to drive
>>>> to more conventionality we would ship with one IoC implementation
>>>> (with the ability for you to substitute your own) and one view engine
>>>> (with the ability for you to substitute your own) and one Controller
>>>> implementation (with the ability to substitute your own) and one...
>>>> If anything removing the current dependencies will make it more
>>>> difficult to adopt MvcContrib because now you will have to shop around
>>>> for CSL implementations that fit your needs for the IoC of your
>>>> choice.
>>>> I second the high praise for Jeremy.
>>>> On Fri, Feb 20, 2009 at 12:59 PM, Jeffrey Palermo
>>>> <jeffreypale...@gmail.com> wrote:
>>>> > Jeremy,
>>>> > (and for everyone listening)
>>>> > You have been key to the success of MvcContrib up to this point. You
>>>> have
>>>> > been so responsive in applying patches and upgrading the project.
>>>> THANK YOU
>>>> > for all your hard work. You are an asset to this project.
>>>> > We need to start being a little more picky about what we include, so
>>>> Eric
>>>> > and I are trying to flesh out a strategy for market adoption. I'm
>>>> glad you
>>>> > are part of this discussion because you have been the most active
>>>> committer
>>>> > on MvcContrib.
>>>> > Let's get opinions from everyone for about a week and then we (you, me
>>>> and
>>>> > Eric) can decide what course of action to take.
>>>> > Best regards,
>>>> > Jeffrey Palermo, Microsoft MVP, MCSD.Net
>>>> > CTO, Headspring Systems
>>>> > agile. software. consulting.
>>>> > 512-459-2260 x 712
>>>> > On Fri, Feb 20, 2009 at 2:43 PM, Jeremy Skinner <
>>>> jer...@jeremyskinner.co.uk>
>>>> > wrote:
>>>> >> Some thoughts...
>>>> >> > Add a dependency on the CommonServiceLocator to replace all of the
>>>> IoC
>>>> >> > containers in the MvcContrib project.
>>>> >> As I've mentioned in the past, swapping the current controller
>>>> factory
>>>> >> implementations for one based on the CSL is not as simple as it seems
>>>> as the
>>>> >> CSL does not support releasing components (so it is not possible to
>>>> >> implement IControllerFactory.ReleaseController properly). This can be
>>>> >> mitigated with the use of child containers which can be disposed at
>>>> the end
>>>> >> of a request, but this is adding an extra level of complexity. I
>>>> guess the
>>>> >> question is: is having a leaner codebase worth the extra complexity
>>>> and
>>>> >> higher learning curve? Personally I'm OK with this, but I'm thinking
>>>> of new
>>>> >> users in particular who are not as familiar with the specifics of the
>>>> >> various containers.
>>>> >> > So FluentHTML would be going where?
>>>> >> You could easily turn FluentHTML into a separate project entirely (I
>>>> >> believe it was separate originally?) as it has no dependencies on
>>>> >> MvcContrib. Personally, I much prefer having several smaller projects
>>>> that
>>>> >> can be mixed and matched rather than one mammoth 'one contrib to rule
>>>> them
I imagine that the html helpers would be in the Main dll. I think we would
better define the root namespaces so that so that it is clear what name
space to use when in a view versus in code (controllers), action filters,
results, route helpers.
Eric Hexter
Principal Consultant
Headspring Systems | www.HeadspringSystems.com email: ehex...@HeadspringSystems.com
blog: Hex.LosTechies.com
--------------------------------------------------------------------------- ----------------------------------
Director - Austin .Net Users Group | www.ADNUG.org Membership Mentor South Texas - INETA | www.INETA.org Asp Insider | www.ASPInsiders.com
On Tue, Feb 24, 2009 at 1:35 PM, Simone Chiaretta <
simone.chiare...@gmail.com> wrote:
> I like the "extras" approach:
> The main dll will be just the enhancements to ASP.NET MVC, with no
> dependencies on external libraries (except, of course, for ASP.NET MVC),
> and the extra will be anything that has to do with external libs
> (ViewEngines).
> Where in this scenario will FluentValidation and the various HtmlHelpers be
> placed? I assume it will be the main assembly.
> IoC ControllerFactories are pretty easy, and I think that having the source
> code will be enough
> Simo
> On Tue, Feb 24, 2009 at 8:12 PM, Eric Hexter <eric.hex...@gmail.com>wrote:
>> So from the feedback I am thinking that rather than limiting the number of
>> Projects in contrib. It would make more sense to look at how we release the
>> binaries and source. I am just typing this as I think through it but an
>> option to help reduce the friction for the main mvc bits that do not have
>> dependencies on 3rd party libraries.
>> How do you feel about having the following Binary Releases:
>> MvcContrib - Contains MvcContrib & MvcContrib.TestHelpers assemblies.
>> MvcContrib.Extras - Contains ViewEngines / Other less used/maintained
>> features. This would come in the form of many dlls and some better
>> documentation on what dependencies are required for each dell in the extras
>> folder.
>> The project would still contain the unit tests and this may be split into
>> tests that support the Contrib vs Extra releases. We could possibly split
>> the project so that it has a separate trunk for the Extras.
>> I really think leaning towards hosting IoC Controller factory samples on
>> the wiki and maybe links to source code implementations for each IoC
>> implementation would be better than providing separate dlls and
>> implementations for each IoC container. how do you feel about this? We
>> could still maintain those in source code but they would not be part of a
>> build of any kind.
>> Thoughts?
>> Thanks,
>> Eric
>> Eric Hexter
>> Principal Consultant
>> Headspring Systems | www.HeadspringSystems.com >> email: ehex...@HeadspringSystems.com
>> blog: Hex.LosTechies.com
>> --------------------------------------------------------------------------- ----------------------------------
>> Director - Austin .Net Users Group | www.ADNUG.org >> Membership Mentor South Texas - INETA | www.INETA.org >> Asp Insider | www.ASPInsiders.com
>> On Mon, Feb 23, 2009 at 12:53 PM, Justin Rudd <justin.r...@gmail.com>wrote:
>>> I'm a new user of MvcContrib, and the amount of DLLs was quite staggering
>>> :) I'd love to see something like what Java Spring has - a text document
>>> saying if you use this assembly, you need to bring along these assemblies.
>>> That allowed me to pick and choose what parts of Spring I wanted to use
>>> without dragging in Web MVC stuff, security stuff, etc. that I knew I wasn't
>>> going ot use (and didn't want in memory).
>>> As for IoC, I like your idea. Documenting is better than another
>>> abstraction. MVC has the ControllerFactory abstraction which is pretty
>>> trivial to implement. Writing a CLS implementation for it just complicates
>>> the matter because now I've got to wonder if my container has a CLS
>>> implementation. And what value does a CLS implementation add that a
>>> specific container implementation doesn't? It's an abstraction that doesn't
>>> buy me anything.
>>> As for view engines, I personally feel those are up to the technology
>>> (i.e. NHaml). Maybe MvcContrib can work with Brail and NVelocity to
>>> contribute the view engines back to them? That's where they live. What I'd
>>> like to see from MvcContrib is new view engines or taking the VB.NET one
>>> and solidifying it (I'm enamored with the strongly typed XML approach of
>>> VB.NET).
>>> On Fri, Feb 20, 2009 at 8:23 PM, Eric Hexter <eric.hex...@gmail.com>wrote:
>>>> My biggest concern with the MvcContrib project is that the binary
>>>> release contains 157 dlls in the zip file. While I know which dependencies
>>>> I am using in my projects, this is an insane amount of assemblies. Combine
>>>> that with the fact that this Open Source project suffers from the problem of
>>>> incomplete documentation and I think that we are really hurting producing a
>>>> high friction solution, that will reduce the adoption of the project.
>>>> As far as the IoC controllers, one of the ideas that was kicked around
>>>> was perhaps documenting what the ControllerFactory implementations for each
>>>> container look like. In most cases, the ControllerFactories are actually
>>>> pretty light and when you weigh that we could provide the same benefit and
>>>> not care around and have to maintain/update the project each time a single
>>>> container has a new version, it would really be better, IMHO, to provide
>>>> guidance through documentation rather than implementations for each
>>>> container. Thoughts?
>>>> My biggest concern with the view engines is that they are not really
>>>> being maintained by anyone. There were originally ported, but no one has
>>>> taken ownership over the engines. The engines that have moved out
>>>> into separate projects.... like Spark have developed a life of their own
>>>> including Visual Studio support. Don't get me wrong, if there is
>>>> an audience for some of the view engines I am willing to work out something
>>>> that could meet the needs of the project while still leaving some option for
>>>> the alternatives. I am really proposing that we let the view engine that
>>>> has risen to the top live free and let the one on life support (XSLT) go on
>>>> to a better place. The real question is what should we do for the view
>>>> engines like brail and nvelocity?. There is a small segment that uses them
>>>> but most people are not.
>>>> I am glad to here from everyone so far and hope to hear from some people
>>>> so that we can make some well informed decisions.
>>>> Eric Hexter
>>>> Principal Consultant
>>>> Headspring Systems | www.HeadspringSystems.com >>>> email: ehex...@HeadspringSystems.com
>>>> blog: Hex.LosTechies.com
>>>> --------------------------------------------------------------------------- ----------------------------------
>>>> Director - Austin .Net Users Group | www.ADNUG.org >>>> Membership Mentor South Texas - INETA | www.INETA.org >>>> Asp Insider | www.ASPInsiders.com
>>>> On Fri, Feb 20, 2009 at 4:43 PM, Bill Pierce <wcpie...@gmail.com>wrote:
>>>>> I don't thinks its been made clear why we need to slim down MvcContrib
>>>>> or why we need to be a little more picky about applying patches. I
>>>>> acknowledge the three goals and to the best of my knowledge we meeting
>>>>> those goals. Is there evidence to the contrary? If we were to drive
>>>>> to more conventionality we would ship with one IoC implementation
>>>>> (with the ability for you to substitute your own) and one view engine
>>>>> (with the ability for you to substitute your own) and one Controller
>>>>> implementation (with the ability to substitute your own) and one...
>>>>> If anything removing the current dependencies will make it more
>>>>> difficult to adopt MvcContrib because now you will have to shop around
>>>>> for CSL implementations that fit your needs for the IoC of your
>>>>> choice.
>>>>> I second the high praise for Jeremy.
>>>>> On Fri, Feb 20, 2009 at 12:59 PM, Jeffrey Palermo
>>>>> <jeffreypale...@gmail.com> wrote:
>>>>> > Jeremy,
>>>>> > (and for everyone listening)
>>>>> > You have been key to the success of MvcContrib up to this point. You
>>>>> have
>>>>> > been so responsive in applying patches and upgrading the project.
>>>>> THANK YOU
>>>>> > for all your hard work. You are an asset to this project.
>>>>> > We need to start being a little more picky about what we include, so
>>>>> Eric
>>>>> > and I are trying to flesh out a strategy for market adoption. I'm
>>>>> glad you
>>>>> > are part of this discussion because you have been the most active
>>>>> committer
>>>>> > on MvcContrib.
>>>>> > Let's get opinions from everyone for about a week and then we (you,
>>>>> me and
>>>>> > Eric) can decide what course of action to take.
>>>>> > Best regards,
>>>>> > Jeffrey Palermo, Microsoft MVP, MCSD.Net
>>>>> > CTO, Headspring Systems
>>>>> > agile. software. consulting.
>>>>> > 512-459-2260 x 712
>>>>> > On Fri, Feb 20, 2009 at 2:43 PM, Jeremy Skinner <
>>>>> jer...@jeremyskinner.co.uk>
>>>>> > wrote:
>>>>> >> Some thoughts...
>>>>> >> > Add a dependency on the CommonServiceLocator to replace all of the
>>>>> IoC
>>>>> >> > containers in the MvcContrib project.
>>>>> >> As I've mentioned in the past, swapping the current controller
>>>>> factory
>>>>> >> implementations for one based on the CSL is not as simple as it
>>>>> seems as the
>>>>> >> CSL does not support
> MvcContrib - Contains MvcContrib & MvcContrib.TestHelpers assemblies. > MvcContrib.Extras - Contains ViewEngines / Other less used/maintained
features.
+1
> We could possibly split the project so that it has a separate trunk for
the Extras.
I think this is a good idea. From a project maintenance perspective, this makes updating MvcContrib when there's a new ASP.NET MVC release a lot easier.
> I really think leaning towards hosting IoC Controller factory samples on
the wiki
As the Controller Factories are very lightweight this definitely makes sense. It also means that we won't need to continually keep an eye on new releases of the various containers in order to keep their binaries up to date.
> Where in this scenario will FluentValidation and the various HtmlHelpers
be placed?
I assume you mean FluentHtml? FluentValidation is a project I maintain separately :) I agree it should be in the main assembly rather than the Extras. However...I'm not so sure about the ModelAttributes project. The nice thing about having this as a separate assembly for for ModelAttributes means that your model project doesn't have to have a reference to all of MvcContrib.
the Mvc installer is requiring. .Net 3.5 sp1, so data annotations are
included in that version of the framework.. Seems like using those
attributes would be the best bet since they are part of the framework..
rather than another 3rd party dependency.
Eric Hexter
Principal Consultant
Headspring Systems | www.HeadspringSystems.com email: ehex...@HeadspringSystems.com
blog: Hex.LosTechies.com
--------------------------------------------------------------------------- ----------------------------------
Director - Austin .Net Users Group | www.ADNUG.org Membership Mentor South Texas - INETA | www.INETA.org Asp Insider | www.ASPInsiders.com
On Tue, Feb 24, 2009 at 1:49 PM, Jeremy Skinner
<jer...@jeremyskinner.co.uk>wrote:
> > We could possibly split the project so that it has a separate trunk for
> the Extras.
> I think this is a good idea. From a project maintenance perspective, this
> makes updating MvcContrib when there's a new ASP.NET <http://asp.net/> MVC
> release a lot easier.
> > I really think leaning towards hosting IoC Controller factory samples on
> the wiki
> As the Controller Factories are very lightweight this definitely makes
> sense. It also means that we won't need to continually keep an eye on new
> releases of the various containers in order to keep their binaries up to
> date.
> > Where in this scenario will FluentValidation and the various HtmlHelpers
> be placed?
> I assume you mean FluentHtml? FluentValidation is a project I maintain
> separately :) I agree it should be in the main assembly rather than the
> Extras. However...I'm not so sure about the ModelAttributes project. The
> nice thing about having this as a separate assembly for for ModelAttributes
> means that your model project doesn't have to have a reference to all of
> MvcContrib.
Ooh, I had completely forgotten about those.
If we can use these then we can completely remove the ModelAttributes
project. I don't think this should affect anything, but best to double check
with Tim.
> the Mvc installer is requiring. .Net 3.5 sp1, so data annotations are
> included in that version of the framework.. Seems like using those
> attributes would be the best bet since they are part of the framework..
> rather than another 3rd party dependency.
> Eric Hexter
> Principal Consultant
> Headspring Systems | www.HeadspringSystems.com > email: ehex...@HeadspringSystems.com
> blog: Hex.LosTechies.com
> --------------------------------------------------------------------------- ----------------------------------
> Director - Austin .Net Users Group | www.ADNUG.org > Membership Mentor South Texas - INETA | www.INETA.org > Asp Insider | www.ASPInsiders.com
> On Tue, Feb 24, 2009 at 1:49 PM, Jeremy Skinner <
> jer...@jeremyskinner.co.uk> wrote:
>> > We could possibly split the project so that it has a separate trunk for
>> the Extras.
>> I think this is a good idea. From a project maintenance perspective, this
>> makes updating MvcContrib when there's a new ASP.NET <http://asp.net/>MVC release a lot easier.
>> > I really think leaning towards hosting IoC Controller factory samples on
>> the wiki
>> As the Controller Factories are very lightweight this definitely makes
>> sense. It also means that we won't need to continually keep an eye on new
>> releases of the various containers in order to keep their binaries up to
>> date.
>> > Where in this scenario will FluentValidation and the various
>> HtmlHelpers be placed?
>> I assume you mean FluentHtml? FluentValidation is a project I maintain
>> separately :) I agree it should be in the main assembly rather than the
>> Extras. However...I'm not so sure about the ModelAttributes project. The
>> nice thing about having this as a separate assembly for for ModelAttributes
>> means that your model project doesn't have to have a reference to all of
>> MvcContrib.
It could be it is just too much of a pain to use them. but I really like
the idea of moving to a common set of decorators that are validation engine
independent. or at least 3rd party independent. I have been using the
castle validation but have had it on my list to check out the
DataAnnotations.
On Tue, Feb 24, 2009 at 2:33 PM, Jeremy Skinner
<jer...@jeremyskinner.co.uk>wrote:
> Ooh, I had completely forgotten about those.
> If we can use these then we can completely remove the ModelAttributes
> project. I don't think this should affect anything, but best to double check
> with Tim.
>> the Mvc installer is requiring. .Net 3.5 sp1, so data annotations are
>> included in that version of the framework.. Seems like using those
>> attributes would be the best bet since they are part of the framework..
>> rather than another 3rd party dependency.
>>> > We could possibly split the project so that it has a separate trunk for
>>> the Extras.
>>> I think this is a good idea. From a project maintenance perspective, this
>>> makes updating MvcContrib when there's a new ASP.NET <http://asp.net/>MVC release a lot easier.
>>> > I really think leaning towards hosting IoC Controller factory samples
>>> on the wiki
>>> As the Controller Factories are very lightweight this definitely makes
>>> sense. It also means that we won't need to continually keep an eye on new
>>> releases of the various containers in order to keep their binaries up to
>>> date.
>>> > Where in this scenario will FluentValidation and the various
>>> HtmlHelpers be placed?
>>> I assume you mean FluentHtml? FluentValidation is a project I maintain
>>> separately :) I agree it should be in the main assembly rather than the
>>> Extras. However...I'm not so sure about the ModelAttributes project. The
>>> nice thing about having this as a separate assembly for for ModelAttributes
>>> means that your model project doesn't have to have a reference to all of
>>> MvcContrib.
