Extensibility, and manipulating the generation of the html from a spark template

[fractisrob]

Apologies if this is answered somewhere else, my googling turned up
nothing. Just throwing this out there before I download the code and
start hunting around in it.

I'm curious, is there an intermediate state of the output that can be
manipulated before the final html gets generated? One of the things
I've wanted for a while is a 'debug' output of html, with the entire
rendered output formatted and indented for readability, and on the
flip side, a 'release' output which has its whitespace removed.

One of the things that make me wish I was using this today is the
automatic expansion of '~/path/to/file' in attributes (I assume, based
on some of the samples I've look at :). I can think of plenty of other
types of conventional transformations like this, is there an
extensibility story, or is it baked in?

[Louis DeJardin]

I don't think there's anyplace that's suitable for a holistic
reformatting of the html... You could try inserting a class at the
HttpRespose.Filter property to post-process everything being written
to reformat or to remove whitespace.

[fractisrob]

Thanks for the reply.

Yea I had considered that, but its not really that much of a priority
for pretty printing the html, I was wondering if an intermediate tree
was created from the tempate markup which would make it more of a fun
distraction :)

As for the other question, regarding transforming/manipulating values
entered as attributes (for application relative urls), is this
extensible, and is there some metadata somewhere signaling which
attributes should be treated as possible urls etc?

[Louis DeJardin]

There are a couple of interesting places you could look if you're trying to control the ~/ expansion.

One thing you can do is reconfigure the location of those resources. The idea is for production release you can control where individual assets or entire directories of assets are located. It's described a bit here:

http://sparkviewengine.com/documentation/configuring#Sparksettingsinconfigfile


If you want deeper control of the url mapping, you can replace the SiteResource method that's on the base view's class. You can do that by changing the base page type to a class from your project, and inheriting the original one. The default implementation is this:

public string SiteResource(string path)
{
   return ResourcePathManager.GetResourcePath(SiteRoot, path);
}

So another thing you could do is replace the IResourcePathManager service with one of your own.

The urls which can be treated as possible urls are hardcoded in the UrlAttributeVisitor. They're more or less anything from the html spec that was a uri.

http://dev.dejardin.org/trac/spark/browser/trunk/src/Spark/Compiler/NodeVisitors/UrlAttributeVisitor.cs

Anyway that UrlAttributeVisitor is a pretty good example of how the contents of the spark files are manipulated in stages as it goes from a bunch of file streams and ends up as a compiled view type.

If you **really** want to dive in and alter what's going on you can replace the syntax provider. The default is here, which you would probably copy as a starting point:

http://dev.dejardin.org/trac/spark/browser/trunk/src/Spark/Parser/Syntax/DefaultSyntaxProvider.cs

The method GetChunks walks through the meat of the work being done. The line "var result = _grammar.Nodes(position);" is the recursive descent parser that's turning the file-stream into an array of nodes, and the "foreach (var visitor in BuildNodeVisitors(context)) ... visitor.Accept(nodes);" is what's giving all of the individual features and special elements and attributes a chance to take effect.

Now that you mention it - if the BuildNodeVisitors was virtual replacing the syntax provider with a subclass that simply adds a few more node visitors would probably be much easier and more future-proof.