Compiling Views all at once

[Chadly]

One thing that I think would be nice would be to have all Spark views
compile at once at application start -- rather than having each view
compiled only when it is requested. That way, when there is a
compilation error in one of your views, you would know about it as
soon as you ran the site -- since no pages would work until all views
successfully compiled.

This could also open the door for precompilation options for when you
are deploying a site?

[Louis DeJardin]

Yeah, that would be ideal. I believe pre-generating all of the view cs
files is something nhaml does as well.

But the big question is how do you know what set of view/master
combinations need to be generated? You could have an inventory xml
file list them all, but that seems out of step with "don't repeat
yourself".

Though maybe that could just be the nature of the thing. You have to
name what you want to precompile.

Or instead of an inventory xml file maybe the spark view files could
have a <precompile master="blah"/> element? That way you could spin
through all of the files on startup.

After that you could have a compile-time tool that generates the all
of the view cs files to include in the web project. Or would it be
better to compile a different assembly to contain all of the view
classes rather than assuming they'll be compiled directly into the web
app?

[Louis DeJardin]

Wait - was it nhaml or Ken's AspView that pregenerated views? Maybe both.

[Justin Chase]

You could create a visual studio plugin that installed an IVsSingleFileGenerator so you can apply it to .spark files. In this case when they get saved after an edit the single file generator will create them right then, that file would get saved to your project and compiled along with your other classes.. You could also use the same plugin to create a syntax hilighter / intellisense... though intellisense on something like this would be ridiculously hard.

Also the engine would have to change quite a bit to accommodate that I suppose.

--
Justin Chase
http://www.justnbusiness.com

[Chadly]

I don't think specifying the layout files beforehand is a good way to
go. This would eliminate the possibility of doing things like
dynamically selecting a layout file from the controller (as a way of
implementing skinning on a site for instance).

I think it would make more sense to have the layout view generate a
separate class from the view that is using it. That way, it wouldn't
be an issue to dynamically mix and match them after they are compiled.

Also, as a personal preference, I would want the views compiled into a
separate assembly rather than have the CS files generated and become
part of the project.

On Aug 4, 2:00 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> Yeah, that would be ideal. I believe pre-generating all of the view cs
> files is something nhaml does as well.
>
> But the big question is how do you know what set of view/master
> combinations need to be generated? You could have an inventory xml
> file list them all, but that seems out of step with "don't repeat
> yourself".
>
> Though maybe that could just be the nature of the thing. You have to
> name what you want to precompile.
>
> Or instead of an inventory xml file maybe the spark view files could
> have a <precompile master="blah"/> element? That way you could spin
> through all of the files on startup.
>
> After that you could have a compile-time tool that generates the all
> of the view cs files to include in the web project. Or would it be
> better to compile a different assembly to contain all of the view
> classes rather than assuming they'll be compiled directly into the web
> app?
>

[Louis DeJardin]

I wouldn't suggest that it would either control or limit the layouts
that were used with the view - just which combinations were
precompiled. The rest of the framework would function as it stands
except if a precompiled view existed for a particular view descriptor
it wouldn't need to be generated and cached.

I'm not sure it would be possible to split the layout and view
classes. There's a lot they share as class members with macros,
viewdata, all of the context members, etc.