Received: by 10.180.233.15 with SMTP id f15mr41527bkh.9.1235190199843; Fri, 20 Feb 2009 20:23:19 -0800 (PST) Return-Path: Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by mx.google.com with ESMTP id 3si286923fgg.16.2009.02.20.20.23.18; Fri, 20 Feb 2009 20:23:18 -0800 (PST) Received-SPF: pass (google.com: domain of eric.hex...@gmail.com designates 209.85.220.176 as permitted sender) client-ip=209.85.220.176; Authentication-Results: mx.google.com; spf=pass (google.com: domain of eric.hex...@gmail.com designates 209.85.220.176 as permitted sender) smtp.mail=eric.hex...@gmail.com; dkim=pass (test mode) header...@gmail.com Received: by fxm24 with SMTP id 24so555052fxm.20 for ; Fri, 20 Feb 2009 20:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=jVWJ3vP1c9indwbO6D0QZsUZkhLzdftIOqzbzPeTEYE=; b=rCnXv/kpIo4JpKVum94VxN8kmMmMYvLJtfus2e9pXS1OD/UOJF5HCkMuZANKFByRT/ iDEbIKOweoQdllPOrzCZbEghGI/GUhR5ZVIyVLVa2CrTggjggu/nZNsiXczswzVDhv7U WEhvuJrNHajgNhDT1rVNHYHTShVrkxpXf2naY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Ljlpmye+w21qfMxJeaYxIfVr+1NNyBKpaZcCYXup3cHohybiNOqtBa1VqEHjK8/DB5 60pnljYclDd16lQp5qMszym2Mh+/aYAR2plfmDfilqgvMzgn+c1rU7vDnQbvlMRC7mns qqCRraPcuQ5feDKeZgD65r1NengNS+i6K95cM= Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00163641692904c2ce046366214f" Received: by 10.103.172.7 with SMTP id z7mr2180834muo.129.1235190198616; Fri, 20 Feb 2009 20:23:18 -0800 (PST) In-Reply-To: References: <1689ca1e0902201207v525139f5va9b81eb71f039333@mail.gmail.com> <77aa53440902201210v4d0ed93ejafaf2090eadb8...@mail.gmail.com> <1689ca1e0902201213t6825d1e8vf18427ab26df2...@mail.gmail.com> <9ec6b15b0902201243o1cc699ftd39fce240a2f7...@mail.gmail.com> Date: Fri, 20 Feb 2009 22:23:18 -0600 Message-ID: <1689ca1e0902202023v590d0004q482885c1c2e89...@mail.gmail.com> Subject: =?windows-1252?Q?Re=3A_=5Bmvccontrib=2Ddiscuss=5D_Re=3A_Mvc_Contrib_=96_Version?= =?windows-1252?Q?_1=2E0_preparation_=2F_project_restructuring?= From: Eric Hexter To: mvccontrib-discuss@googlegroups.com --00163641692904c2ce046366214f Content-Type: text/plain; charset=ISO-8859-1 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 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 > 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 > >> > > > > > > > > > > > > > --00163641692904c2ce046366214f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My biggest concern with the MvcContrib project is that the binary rele= ase contains 157 dlls in the zip file.  While I know which dependencie= s I am using in my projects, this is an insane amount of assemblies. &= nbsp;Combine that with the fact that this Open Source project suffers from = the problem of incomplete documentation and I think that we are really hurt= ing producing a high friction solution, that will reduce the adoption of th= e project.


As far as the IoC controllers, one of th= e ideas that was kicked around was perhaps documenting what the ControllerF= actory implementations for each container look like.  In most cases, t= he ControllerFactories are actually pretty light and when you weigh that we= could provide the same benefit and not care around and have to m= aintain/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&n= bsp;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 s= ome 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 alternativ= es.  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 bett= er place.  The real question is what should we do for the view engines= like brail and nvelocity?.  There is a small segment that u= ses them but most people are not.


I am glad to here from everyone so far a= nd hope to hear from some people so that we can make some well informed dec= isions.

Eric Hexter

Principal Consultant
Headspring Systems | www.Heads= pringSystems.com
email: ehex...@HeadspringSystems.com
blog: Hex.LosTechies.com
---------------= ---------------------------------------------------------------------------= -------------------
Director - Austin .Net Users Group | www.A= DNUG.org
Membership Mentor South Texas - INETA | www.INETA.org
Asp Insider | www.ASPInsiders.com




On Fri, Feb 20, 2009 at 4:43 PM, Bill Pi= erce <wcpierce@g= mail.com> wrote:

I don't thinks its been made clear why we need to slim down MvcContrib<= br> 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 d= rive
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. &nbs= p;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 E= ric
> and I are trying to flesh out a strategy for market adoption.  I&= #39;m glad you
> are part of this discussion because you have been the most active comm= itter
> 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 o= f 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 se= ems as the
>> CSL does not support releasing components (so it is not possible t= o
>> implement IControllerFactory.ReleaseController properly). This can= be
>> mitigated with the use of child containers which can be disposed a= t the end
>> of a request, but this is adding an extra level of complexity. I g= uess the
>> question is: is having a leaner codebase worth the extra complexit= y 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<= br> >> MvcContrib. Personally, I much prefer having several smaller proje= cts 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:    Nve= locity, Brail
>> Is this really a good idea? I know several people use these and th= ere are
>> no alternative implementations out there. The version of Brail in = the Castle
>> trunk is completely incompatible with aspnetmvc. Again, these coul= d 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 i= f 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&#= 39;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 n= ew AAA
>> style. I'd like to see everything moved over to the AAA approa= ch.
>> I think it is also important to come up with some guidelines for w= hat
>> should actually be included in the project. Currently I apply pret= ty much
>> every patch that is submitted unless there's an obvious reason= not to.
>> Perhaps we should resurrect the use of the mvccontrib-developers m= ailing
>> list for discussing patches?
>> Jeremy
>>
>
>
> >
>



--00163641692904c2ce046366214f--