New download posted

0 views
Skip to first unread message

Louis DeJardin

unread,
Aug 25, 2008, 12:47:36 PM8/25/08
to Spark View Engine Dev
Note! There's a breaking change in the <spark> config section... The
<add namespace=""/> elements have moved to a <pages> element, which is
following the config structure of asp.net.

<spark>
<compilation debug="true|false">
<assemblies><add assembly=""/></assemblies>
</compilation>
<pages pageBaseType="fullname, assembly">
<namespaces><add namespace=""/></namespaces>
</pages>
</spark>

The samples folder is also part of the release zip... There aren't too
many samples yet.

One of them is how you would use a windsor container to create your
view instances. It also shows how you would use a custom base class
for views to add public properties and methods.

That's in case you want to use things like INavRepository from views
and partials. You could put public INavRepository Nav {get;set;} in
your view base class and windsor will hook you up with it.

The other sample is showing the compile-on-start and the load-
precompiled-assembly scenarios. The castle precompile isn't
implemented yet - that'll follow soon - but there's a chance this
could be used in asp.net mvc now to deploy to medium trust
environments.

Louis DeJardin

unread,
Aug 25, 2008, 12:49:05 PM8/25/08
to Spark View Engine Dev

Mihai

unread,
Aug 25, 2008, 1:26:46 PM8/25/08
to Spark View Engine Dev
Why did the need to specify the base page?
Is it really a must have? I think there should be an implicit value.
But I am curios to know why :P

Louis DeJardin

unread,
Aug 25, 2008, 2:10:08 PM8/25/08
to Spark View Engine Dev
It's totally optional - both frameworks have their own base class
which would be the default value. And if you do specify the
pageBaseType you'd probably that class to inherit from the default.

And those would be... "MvcContrib.SparkViewEngine.SparkView" and
"Castle.MonoRail.Views.Spark.SparkView"

It can be convenient though if you want to provide universally
available methods and properties in your web app. You can always use
<macro> and <global> in markup to do much the same thing, but a base
view class can be a very convenient way to add things like the "public
string H(string content)" function that does html encoding $
{H(property.Name)}. Or if you wanted to make some of your own
intrinsic objects universally available like "public UserInfo
CurrentUser {get {...}}" for ${CurrentUser.Email}.

And as always, please use responsibly. :) It would be pretty easy to
wander off the golden path of mvc - the road to hell is paved with
code-behind.
Reply all
Reply to author
Forward
0 new messages