Mvc Contrib – Version 1.0 preparation / project restructuring

[Eric Hexter]

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.

Thanks,

Eric Hexter -  MvcContrib Co-founder

Jeffrey Palermo - MvcContrib Co-founder

[Will Shaver]

So FluentHTML would be going where?

There are a couple of things in Castle -> Perhaps we should have an
MvcCastleContrib project separate?

[Eric Hexter]

Lets get into some details, about what should stay from the castle dependencies and which portions are "dead" code.

[Will Shaver]

I use both the MvcTransaction attribute and the Controller register
code. Don't recall what else is there at the moment, and I'm not on my
dev box.

[Jeremy Skinner]

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

[Jeffrey Palermo]

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

[Ben Scheirman]

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.

[Tim Scott]

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.

[Morten Maxild]

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.

/Maxild

[Bill Pierce]

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.

[Simone Chiaretta]

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

--
Simone Chiaretta
codeclimber.net.nz
Any sufficiently advanced technology is indistinguishable from magic
"Life is short, play hard"

[Eric Hexter]

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: ehe...@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

[Jeffrey Palermo]

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

[Eric Hexter]

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.

Eric

[Simone Chiaretta]

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

[Drozzy]

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:

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

[Zihotki]

Hello all,

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

Thanks.

[Justin Rudd]

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

Justin Rudd
http://justrudd.org/

[Eric Hexter]

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: ehe...@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

[Simone Chiaretta]

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

[Eric Hexter]

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: ehe...@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

[Jeremy Skinner]

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

Jeremy

[Eric Hexter]

Why are you using Model attributes now that there is ComponentModel.DataAnnotations ? http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.aspx 

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: ehe...@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

[Jeremy Skinner]

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. 

2009/2/24 Eric Hexter <eric....@gmail.com>

[Eric Hexter]

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.

[Jeremy Skinner]

I think it should be fine. The only attributes in MvcContrib.ModelAttributes are MaxLengthAttribute and RequiredAttribute which map nicely to StringLengthAttribute and RequiredAttribute in the DataAnnotations assembly. 

2009/2/24 Eric Hexter <eric....@gmail.com>

[Tim Scott]

I have no objections to eliminating ModelAttributes. We would either
have to eliminate ConventionModelViewXXXXX classes or change them to
use other attributes, such as DataAnnotations. I have no objection
either way. The case for using these is pretty narrow, and it's
pretty trivial to do yourself. I think maybe I created those mostly
to illustrate the usage of behaviors with attributes. Could be
achieved even better with a sample.

On Feb 24, 2:40 pm, Eric Hexter <eric.hex...@gmail.com> wrote:
> 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.
>

> > 2009/2/24 Eric Hexter <eric.hex...@gmail.com>

>
> >  Why are you using Model attributes now that there is
> >> ComponentModel.DataAnnotations ?

> >>http://msdn.microsoft.com/en-us/library/system.componentmodel.dataann...

>
> >> 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<http://www.headspringsystems.com/>
> >> email: ehex...@HeadspringSystems.com
> >> blog: Hex.LosTechies.com <http://hex.lostechies.com/>
>
> >> -------------------------------------------------------------------------------------------------------------
> >> Director - Austin .Net Users Group |www.ADNUG.org<http://www.adnug.org/>
> >> Membership Mentor South Texas - INETA |www.INETA.org<http://www.ineta.org/>
> >> Asp Insider |www.ASPInsiders.com<http://www.aspinsiders.com/>

>
> >>   On Tue, Feb 24, 2009 at 1:49 PM, Jeremy Skinner <
> >> jer...@jeremyskinner.co.uk> wrote:
>
> >>>   > 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 <http://asp.net/>MVC release a lot easier.

[Jeremy Skinner]

I vote to switch over to DataAnnotations. I think the behaviours are useful enough to warrant keeping them in the project.

Jeremy

2009/2/25 Tim Scott <tsc...@lunaversesoftware.com>

[Morten Maxild]

I vote for moving ConventionModelViewXXXX to sample project, and using DataAnnotations would be okay. On a real project we cannot know if people would want to use Castle validation attributes, DataAnnotations, or anything else. I also guess on a real project that the super layer types for layout, view and partial views would inject the behaviors into the super layer types using a different approach (more DRY, more IoC like)

 

Just my thoughts…or 2 cents…whateverJ

 

/Maxild

 

 

 

---

From: mvccontri...@googlegroups.com [mailto:mvccontri...@googlegroups.com] On Behalf Of Jeremy Skinner
Sent: Wednesday, February 25, 2009 3:10 PM
To: mvccontri...@googlegroups.com
Subject: [mvccontrib-discuss] Re: Mvc Contrib – Version 1.0 preparation / project restructuring

 

I vote to switch over to DataAnnotations. I think the behaviours are useful enough to warrant keeping them in the project.

Jeremy

[Eric Hexter]

I have mixed feelings.  I would like to see mvccontrib provide some bases to allow for better html helpers in the views.  But in order to so this it would require building off of classes in the framework and not in different framework. I need to personally get into the fluent html examples and see if what I am thinking of matches up with this specific implementation.

Eric Hexter

Principal Consultant
Headspring Systems | www.HeadspringSystems.com

email: ehe...@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

[Morten Maxild]

In FluentHtml there are two kind of base classes. ModelXXXX and ConventionModelXXX. I say that users can start right away using the fluent view helpers by deriving from ModelXXXX bases. More experienced users can inject (conventions) behaviors by looking at the ConventionModelXXX base classes in the sample, and make there own ConventionModelXXXXX (or OpinionatedXXX) base classes. I don’t want to use ConventionModelXXXXX, because this way I can’t control what behaviors I am using during rendering (I have to use the ones ‘burned’ into the ConventionModelXXXX classes). Therefore I say ConventionModelXXXXX base classes to me is more like sample code than like production code.

 

Of course not everybody would have to agree with me on this.

 

/Maxild

 

---

[Tim Scott]

I agree with Morton. Users who don't care about behaviors will derive
from ModelViewXXXX and that's that. Users who want to use behaviors
are unlikely to have the exact same opinions expressed in
ConventionModelViewXXXX and will instead create their own base classes
that derive from ModelViewXXXX.

On Feb 25, 8:55 am, "Morten Maxild" <mmax...@gmail.com> wrote:
> In FluentHtml there are two kind of base classes. ModelXXXX and ConventionModelXXX. I say that users can start right away using the fluent view helpers by deriving from ModelXXXX bases. More experienced users can inject (conventions) behaviors by looking at the ConventionModelXXX base classes in the sample, and make there own ConventionModelXXXXX (or OpinionatedXXX) base classes. I don’t want to use ConventionModelXXXXX, because this way I can’t control what behaviors I am using during rendering (I have to use the ones ‘burned’ into the ConventionModelXXXX classes). Therefore I say ConventionModelXXXXX base classes to me is more like sample code than like production code.
>
> Of course not everybody would have to agree with me on this.
>
> /Maxild
>
>   _____  
>

> From: mvccontri...@googlegroups.com [mailto:mvccontri...@googlegroups.com] On Behalf Of Eric Hexter
> Sent: Wednesday, February 25, 2009 3:42 PM
> To: mvccontri...@googlegroups.com
> Subject: [mvccontrib-discuss] Re: Mvc Contrib – Version 1.0 preparation / project restructuring
>
> I have mixed feelings.  I would like to see mvccontrib provide some bases to allow for better html helpers in the views.  But in order to so this it would require building off of classes in the framework and not in different framework. I need to personally get into the fluent html examples and see if what I am thinking of matches up with this specific implementation.
>
> 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 Wed, Feb 25, 2009 at 8:21 AM, Morten Maxild <mmax...@gmail.com> wrote:
>
> I vote for moving ConventionModelViewXXXX to sample project, and using DataAnnotations would be okay. On a real project we cannot know if people would want to use Castle validation attributes, DataAnnotations, or anything else. I also guess on a real project that the super layer types for layout, view and partial views would inject the behaviors into the super layer types using a different approach (more DRY, more IoC like)
>

> Just my thoughts…or 2 cents…whatever:-)
>
> /Maxild
>
>   _____  

[Morten Maxild]

Morten...but thanks anyway:-)

Sent from my iPhone

[Will Shaver]

So is someone going to review the ModelAttributes project then?

[Morten Maxild]

I don't understand. Isn't the plan to move it to a sample project?
Maybe i just don't know enough about the workflow?

Sent from my iPhone

[Jeremy Skinner]

I have started to add some FluentHtml samples UI Sample project including an example of using DataAnnotations for adding maxlength/required attributes. If anyone else would like to add some samples, please feel free. I have also removed the ModelAttributes project along with the ConventionModel* classes. 

I also think that FluentHtml should be included in the core release package rather than the 'extras' package.

Jeremy

[Eric Hexter]

Do you think we should just roll in the fluent html into the main dll? 

I like the main release to be one production dll and one test dll.  Makes things really simple.  I am on vacation for the week but I can put some time to this when I get back.

Eric Hexter

Principal Consultant
Headspring Systems | www.HeadspringSystems.com

email: ehe...@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

2009/3/15 Jeremy Skinner <jer...@jeremyskinner.co.uk>

[Jeremy Skinner]

I have no problem with this. Its possible that some people may want to use fluenthtml without taking a dependency on mvccontrib, but I can't really think of a good reason not to merge the two.

2009/3/16 Eric Hexter <eric....@gmail.com>