MVC integration assembly name

[Nicholas Blumhardt]

Hi all,

Alex - just surfacing the discussion about how the MVC integration should be named. I was going to suggest keeping the old Autofac.Integration.Web.Mvc name just to minimise changes when upgrading; however the new and old MVC integrations are totally different, and thus they're really not the same assembly. Autofac.Integration.Mvc therefore gets my vote - sound logical?

Just had my first tinker with the new codebase, looks great!

Nick

[Aaron Powell]

I don't see why not go with a new naming format. It's not like people wouldn't be doing an in-place upgrade between MVC2 & MVC3 without compiling first!

There needs to be some clear doco though on stating that MVC3 integration has moved into a new assembly though, otherwise it could quite easily get lost

Aaron Powell
Umbraco Ninja

http://www.aaron-powell.com | http://twitter.com/slace | Skype: aaron.l.powell | MSN: aaz...@hotmail.com

--
You received this message because you are subscribed to the Google Groups "Autofac" group.
To post to this group, send email to aut...@googlegroups.com.
To unsubscribe from this group, send email to autofac+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/autofac?hl=en.

[Alex Meyer-Gleaves]

Sounds logical to me. I will rename the project to Autofac.Integration.Mvc and fix up the sample applications. I will also add some documentation to the MVC3 page on the wiki. The documentation should be straight forward as there are now fewer steps for the user to get the integration running.

[Alex Meyer-Gleaves]

Hi all,

I have renamed the integration, fixed the example applications and
added some documentation to the wiki page. The documentation includes
details about upgrading from MVC 2.

http://code.google.com/p/autofac/wiki/Mvc3Integration

I would like to add some documentation about using the action invoker
later as well.

Cheers,

Alex.

On Nov 24, 2:07 pm, Alex Meyer-Gleaves <alex.meyerglea...@gmail.com>
wrote:

> Sounds logical to me. I will rename the project to Autofac.Integration.Mvc
> and fix up the sample applications. I will also add some documentation to
> the MVC3 page on the wiki. The documentation should be straight forward as
> there are now fewer steps for the user to get the integration running.
>
> On 24 November 2010 08:19, Aaron Powell <m...@aaron-powell.com> wrote:
>
>
>
>
>
>
>
> > I don't see why not go with a new naming format. It's not like people
> > wouldn't be doing an in-place upgrade between MVC2 & MVC3 without compiling
> > first!
>
> > There needs to be some clear doco though on stating that MVC3 integration
> > has moved into a new assembly though, otherwise it could quite easily get
> > lost
> > Aaron Powell
> > Umbraco Ninja
>
> >http://www.aaron-powell.com|http://twitter.com/slace| Skype:
> > aaron.l.powell | MSN: aaz...@hotmail.com
>
> > On Wed, Nov 24, 2010 at 8:47 AM, Nicholas Blumhardt <
> > nicholas.blumha...@gmail.com> wrote:
>
> >> Hi all,
>
> >> Alex - just surfacing the discussion about how the MVC integration should
> >> be named. I was going to suggest keeping the old Autofac.Integration.Web.Mvc
> >> name just to minimise changes when upgrading; however the new and old MVC
> >> integrations are totally different, and thus they're really not the same

> >> assembly. *Autofac.Integration.Mvc* therefore gets my vote - sound

> >> logical?
>
> >> Just had my first tinker with the new codebase, looks great!
>
> >> Nick
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Autofac" group.
> >> To post to this group, send email to aut...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> autofac+u...@googlegroups.com<autofac%2Bunsu...@googlegroups.com >
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/autofac?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "Autofac" group.
> > To post to this group, send email to aut...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > autofac+u...@googlegroups.com<autofac%2Bunsu...@googlegroups.com >
> > .

[Andrew Cherry]

Seems to be working pretty well here. Has anyone looked at view page activation with Autofac? I had a quick play around yesterday and it seems pretty straightforward. I'm not using it for anything right now, but if it would be useful, the following might be a starter for 10 (hardly production code, but seems to work). The choice to dynamically register the types seems sensible even though given the lack of constructor injection possibility in MVC, I'm not sure how much it'll gain over simple Activator.CreateInstance > Context.InjectProperties. But I suppose it might be useful in future.

Anyway, code follows. As I say, I'm not using it, but it works in my tests so far. I've moved away from using it how I thought I might as I'm not hugely liking highly concrete dependencies on an inheritance hierarchy, but I can imagine cases where it's worth it.

<code>

public class AutofacViewPageActivator : IViewPageActivator
{
private readonly IComponentContext context;

public AutofacViewPageActivator(IComponentContext context)
{
this.context = context;
}

public object Create(ControllerContext controllerContext, Type type)
{
var service = new TypedService(type);

if (!context.IsRegisteredService(service))
RegisterViewPageService(type);

return context.ResolveService(service);
}

private void RegisterViewPageService(Type serviceType)
{
var builder = new ContainerBuilder();
builder
.RegisterType(serviceType)
.PropertiesAutowired(false)
.InstancePerHttpRequest();
builder
.Update(context.ComponentRegistry);
}
}

</code>

Cheers,

A.

----- Start Original Message -----
Sent: Thu, 25 Nov 2010 06:28:01 -0800 (PST)
From: Alex Meyer-Gleaves <alex.mey...@gmail.com>
To: Autofac <aut...@googlegroups.com>
Subject: Re: MVC integration assembly name

> To unsubscribe from this group, send email to autofac+u...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/autofac?hl=en.

----- End Original Message -----

[Nicholas Blumhardt]

Hi Andrew,

Thanks for the info! Couple of questions, if you or anyone on the list has the time to look at them:

• Are there any criteria that identify View types; e.g. are they all derived from a common base, or have names that can be tested, such as ending with the word 'View'?
• Will ASP.NET MVC try the IDependencyResolver before hitting the IViewPageActivator?

If so, an IRegistrationSource would be the way to go.

Cheers,

Nick

[Andrew Cherry]

Hi Nick,

I'd love something a bit more convention based but haven't a way. The framework will try IDependencyResolver for an IViewPageActivator first of all. If not found, it will try the concrete class of the view (something like ASP.Index_cshtml), and finally it'll go for Activator.CreateInstance.

The classes requested are pretty much "dynamic" they're created from the .cshtml for example in the case of Razor views. They implicitly inherit from WebViewPage, unless overridden, but they don't exist at compile time in terms of registerable types that I can see. Which leaves a common base out in the cold as well as far as I can see. If you override you must inherit with an abstract class and only a default constructor is possible.

It's a bit of a flaw in the compilation process for view pages as far as I'm concerned, but I can see why. One of those things. I couldn't find a much neater way of doing it without adding more complexity (which would be sensible for performance in some cases perhaps). If anyone has any thoughts, I'm totally open.

In terms of an IRegistrationSource, that sounds interesting - I'll go and look at the Autofac core code!

Cheers

A.

----- Start Original Message -----

Sent: Tue, 30 Nov 2010 08:00:37 +1000
From: Nicholas Blumhardt <nicholas....@gmail.com>
To: aut...@googlegroups.com

Subject: Re: MVC integration assembly name

> Hi Andrew,

>
> Thanks for the info! Couple of questions, if you or anyone on the list has
> the time to look at them:
>
>

> - Are there any criteria that identify View types; e.g. are they all

> derived from a common base, or have names that can be tested, such as ending
> with the word 'View'?

> - Will ASP.NET MVC try the IDependencyResolver before hitting the

> > <autofac%2Bunsu...@googlegroups.com<autofac%252Buns...@googlegroups.com>>

> > > > >> .
> > > > >> For more options, visit this group at
> > > > >>http://groups.google.com/group/autofac?hl=en.
> > > >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > Groups
> > > > > "Autofac" group.
> > > > > To post to this group, send email to aut...@googlegroups.com.
> > > > > To unsubscribe from this group, send email to
> > > > > autofac+u...@googlegroups.com<autofac%2Bunsu...@googlegroups.com>

> > <autofac%2Bunsu...@googlegroups.com<autofac%252Buns...@googlegroups.com>>

> > > > > .
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/autofac?hl=en.
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "Autofac" group.
> > > To post to this group, send email to aut...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > autofac+u...@googlegroups.com<autofac%2Bunsu...@googlegroups.com>
> > .
> > > For more options, visit this group at
> > http://groups.google.com/group/autofac?hl=en.
> >

[Alex Meyer-Gleaves]

Hi guys,

Sorry to jump in late on this one. I knocked up a IRegistrationSource and checked it in along with some unit tests.

http://code.google.com/p/autofac/source/detail?r=50bf5ddfa5d38a9f232c3f62642997b44b719bc4

This should work with any derived WebViewPage class so we don't need to provide a base class for others to use. Constructor injection is definitely not possible but property injection is fine.

public class WebViewPageRegistrationSource : IRegistrationSource

{

public IEnumerable<IComponentRegistration> RegistrationsFor(Service service, Func<Service, IEnumerable<IComponentRegistration>> registrationAccessor)

{

var typedService = service as IServiceWithType;

if (typedService != null && typedService.ServiceType.IsAssignableTo<WebViewPage>())

yield return RegistrationBuilder.ForType(typedService.ServiceType)

.PropertiesAutowired()

.InstancePerHttpRequest()

.CreateRegistration();

}

public bool IsAdapterForIndividualComponents

{

get { return true; }

}

}

For example, I could create a simple view base class.

public abstract class MyBaseWebViewPage : WebViewPage

{

public IDependency Dependency { get; set; }

}

Then make my view inherit from it.

@inherits MyBaseWebViewPage

Add the registration source during start up.

builder.RegisterSource(new WebViewPageRegistrationSource());

And finally refer to the property in the view.

<p>Dependency injected: @(Dependency != null)</p>

You can't have the @model and @inherits in your view at the same time but it is possible to make your base view class inherit from WebViewPage<> and provide the type there instead.

Cheers,

Alex.

[Nicholas Blumhardt]

Nice work :) One small suggestion - IsAdapterForIndividualComponents - should return false in this case, the view isn't wrapping any other components.

Cheers,

Nick

[Alex Meyer-Gleaves]

Thanks Nick. 

Good catch. I've that fixed that one and pushed the change up.

What do you think about a container builder extension that adds the registration source? Something like ViewPropertiesAutowired or InjectWebViewPages. It doesn't save much typing, but it might save some confusion about what a registration source is and make it a bit more discoverable.

Cheers,

Alex.