Using Spark View Engine

[Epps]

My problem is when using a ServiceLocator other than
WindsorServiceLocator, the SparkViewFactory is not properly
intialized. Is there a special mechanism similar to
IRouteRegistration for wiring up alternate view engines? Or would I
just need to register it in a custom ViewEngineBlade and then add it
to the collection in Startup()? I would monkey with this right away,
but I will be away from my dev machine until tomorrow some time, and
was just wondering if anyone had already addressed this problem, or if
it was just something very simple I was overlooking.

Thanks in advance!

[Javier Lozano]

Have you downloaded the samples? In there we have a multiple view
engines app that shows you how to have spark, webforms and nvelocity
working on the same app.

NVelocity has some issues since its not compiled with mvc2 but all
others work just fine.

Also, did you add the config pieces into web.config that Spark needs?

[Epps]

Yes, the sample uses the WindsorServiceLocator, and the comment on the static ctor for mvcapplication mentioned Windsor did something special with the iviewengine initialization , thus the reason it was being used for the example. I am currently using Ninject, but it doesn't act the same way, unfortunately.

I did plugin Windsor as in the sample, and it worked fine, but in the end was hoping to be able to wire up ninject in order to reuse some other registration components I already have written from other projects.

--Sean

[Javier Lozano]

Ok, cool. The issue is actually not with Turbine or Spark but with
Ninject (not slamming on it). This is due to the fact that Ninject
goes for the greedy constructors of any type. When Turbine resolves
all the IViewEngine, it just pings the underlying container for the
types. So when Ninject goes and tries to build SparkViewFactory it
uses the constructor that takes in a ISparkSettings instance. The
reason why Windsor works out of the box is because of how it handles
object construction. Since no ISparkSettings is ever registered it
knows to use the next constructor it discovered (the default one).

If you want to use Ninject with Spark and Turbine you'll need to do
this:

kernel.Bind<ISparkSettings>().ToMethod(context =>
(ISparkSettings)ConfigurationManager.GetSection("spark"));

You're setting a factory method for the ISparkSettings type and
resolving it the same way the SparkViewFactory greedy constructor
handles the instantiation of ISparkSettings.

Does this help?

On Aug 18, 6:05 pm, Epps <epp...@gmail.com> wrote:
> Yes, the sample uses the WindsorServiceLocator, and the comment on the static ctor for mvcapplication mentioned Windsor did something special with the iviewengine initialization , thus the reason it was being used for the example.  I am  currently using Ninject, but it doesn't act the same way, unfortunately.
>
> I did plugin Windsor as in the sample, and it worked fine, but in the end was hoping to be able to wire up ninject in order to reuse some other registration components I already have written from other projects.
>
> --Sean
>

[Epps]

Ya, that makes sense. I suppose I can do that in startup, no need to make a blade for it.. Although I could just for kicks. Thanks for your help. I'm digging Turbine.

--Sean

[Darren Cauthon]

I don't know Spark well, so forgive any ignorance here. Plus, this
won't be a potential solution until the next version of Turbine,
but...

If getting past the greedy constructor is an issue, could you register
IViewEngine with a simple factory method like so:

locator.Register<IViewEngine>(() => new SparkViewEngine());

So instead of feeding the requirements of the greediest constructor,
you can just tell the container to invoke a method that uses the
default constructor. And, it will work against all of the IoC
containers.

I'm a Unity guy, (which also follows for the greediest constructor
rule), so I've used the trick Javier lists above. However, fulfilling
multiple dependencies for things like Linq2SQL, EF or web services can
be a huge pain and leave some confusing code (nothing like fulfilling
multiple string constructor dependencies :) ). I've used the factory
method trick above to keep things simple.


Darren

[Sean Epping]

Well, I registered the ISettings, did a break to check the registrations, confirmed the view engine resolved correctly from the locator, and even went as far as clearing the viewengines collection and adding spark back in.  When I run, I am still getting:

Exception Details: System.InvalidOperationException: The view 'Index' or its master was not found. The following locations were searched:
~/Views/Home/Index.aspx
~/Views/Home/Index.ascx
~/Views/Shared/Index.aspx
~/Views/Shared/Index.ascx

if I remove the controller action, I get a 404, shouldn't it try to infer something?  Is this indicative a something deeper not getting initialized correctly?  I may just refactor into Castle, or maybe Unity if I can get that to work(And just rewrite the old modules to use Turbine registration).  My curiosity about it all keeps me at it.  Any other thoughts?

[Sean Epping]

As an update, I switched into Unity to test it out.  The above method of registering ISettings worked with Unity, but still flounders with Ninject.  The curiosity burns..

[Javier Lozano]

Ok, so sorry! You're running into the same issues I did while testing
out a solution for you.

If you remove the copying of MvcContrib.dll on the the Build Events of
the project, you will fix the issue. Also, make sure you're bin folder
is clear since Turbine loads all assemblies within the bin folder and
process them. So if it's left over, it will pull it back in.

On Aug 19, 12:09 pm, Sean Epping <epp...@gmail.com> wrote:
> As an update, I switched into Unity to test it out.  The above method of
> registering ISettings worked with Unity, but still flounders with Ninject.
>  The curiosity burns..
>
>
>
> On Thu, Aug 19, 2010 at 10:59 AM, Sean Epping <epp...@gmail.com> wrote:
> > Well, I registered the ISettings, did a break to check the registrations,
> > confirmed the view engine resolved correctly from the locator, and even went
> > as far as clearing the viewengines collection and adding spark back in.
> >  When I run, I am still getting:
>

> > *Exception Details: *System.InvalidOperationException: The view 'Index' or

[Sean Epping]

Aha!  I had removed it from my references, but forgot to clean the folder.  My next goal shall be to determine if I still need to be able to use MvcContrib.  Maybe in that override method I can explicitly remove the binding ahead of time, or add a filter for it somewhere.  I know I saw assembly filters in there somewhere.  I am trying to think if there is anything in MvcContrib I am still using, or if there is anything that I really need registered in there.  I believe the main thing I was using was strongly typed redirects.