Where’s Lou

Going back to December there was a comment on Using Spark as a general purpose template engine about the use of anonymous types for your ViewData model. Or about surfacing information in general without being type-specific.

Out of curiosity. If in EmailView I just had a public property…
public object data {get; set;}
and set the data using an anonymous type like so…
view.data = new {user = new {first=”Phil”, Last=”Haack”}};
Could I do this in the template
Hi ${data.user.last}, ${data.user.first}

To which I replied

Well… Sort of… But not really…

Thinking about it later I was mulling over the steps you would take to inject small DLR expressions of something like Ruby or Python. For performance you’d want to have keep and re-use the same code instance, because it trains and optimizes itself based on the types that pass through it. Most DLR expressions are ultimately run with the same type of value at most of their code points, which is how dynamic language engines can get blisteringly fast performance out of a run-time-type situation.

Then I realized something. That’s what the dynamic keyword does! It’s a tiny instantiation of a csharp DLR expression.

Hey, wait a second! Isn’t this exactly what the C# 4.0 dynamic keyword is for?

So then the answer is yes - with C# 4.0 you’ll be able to do exactly what you were asking.

And then after thinking about it even more I realized that’s also exactly what ViewData.Eval is for. The problem with ${ViewData.Eval(”data.user.last”)} is you’re not really gaining the benefit of late binding from a wrist pain standpoint. Yes, you haven’t declared the viewdata types, but taken together the repeated ViewData.Eval( ) will increase the overall template size and reduce readability.

Enter a new syntax! Within a code expression it’s never valid to have a # in front of an identifier, or series of identifiers connected by dots. That syntax is now repurposed - when it’s seen it’s treated as the string argument for a call to Eval.

Hi ${#user.last}, ${#user.first}
Read the rest of this entry »

I added a sample of a Asp.Net MVC based framework a web site composed of individually deployable packages.

As you may know the Spark view engine site is a Drupal CMS. I’ve been amazed how well Drupal and WordPress can compose a site from extensions and plugins. There was an earlier question about how you would do that with Spark, so I recently posted a more complete sample following up on that. The code for the sample is in the .zip download under Samples/Modularity/Modularity.sln.
Read the rest of this entry »

I was just walking through all the sample web apps in the Spark project converting them from ${H(expr)} and ${expr} to ${expr} and !{expr}. One thing I hate to admit is how frequently I had demo data like product names going out without html encoding - so for me that’s kind of case in point on that particular feature.

The other thing I noticed was when I was working updating a _NavItem.spark partial file in a MonoRail web app. I saw a comparison of a value with a Context.Request.RawUrl and had an idle curiosity about what other properties might have been available.

So I thought, hey! Great time to see if that intellisense thing is working. Ctrl+space and Bam! That property is deprecated.

But even better than that is how well it informs you of the vast array of properties available at every level. I really wish we’d had this available a few projects ago. I guess you should never underestimate the value of your development tools.
Read the rest of this entry »

Happy new year! A new build for Spark has been posted on the download page that includes a SparkVsIntegration.msi file in the root of the zip. That file will deploy needed resources to Program Files\Spark and add registry entries.

Newer versions of the msi will upgrade these without needing to uninstall. To reverse any changes you may uninstall “Spark View Engine” from Control Panel at any time.

There are a few other changes, see release notes on download page for details, but one is based on a thread started by Kevin Dente.

There’s been a bunch of discussion in the blogosphere lately about XSS
and encoding output, with the the general consensus being “always HTML
encode your output”. Yet no view engines seem to do this. Have you
considered making Spark encode output by default (with a way to
escape, of course)? Or at least giving an expression syntax that
encodes by default (e.g #{expr}, ^{expr}, or whatever).

See also The Perfect Storm Botnet. In the end the feature allows you to opt-in to a configuration where you html-encode all ${expr} by default, and the expressions which you explicitly intend to hold raw html would use a !{expr} syntax.

Assuming you have an existing project there’s a migration path if you want to switch over. First go through your entire project and change $ to ! where you want html to come through.

<p>
  Hello ${H(user.Name)}
  ${Html.ActionLink("edit profile", "edit", "account")}
</p>

becomes

<p>
  Hello ${H(user.Name)}
  !{Html.ActionLink("edit profile", "edit", "account")}
</p>

You can verify your site’s still working because $ and ! work identically with automatic html encoding disabled. Then turn on the option with a config switch:

<configuration>
  <spark>
    <pages automaticEncoding="true"/>
  </spark>
</configuration>

You can verify your site is still working at this point because ${H(expr)} will ignore the redundant H(). Finally go through and remove those extra H()’s.

<p>
  Hello ${user.Name}
  !{Html.ActionLink("edit profile", "edit", "account")}
</p>