The biggest limitation of what you've got is that you need to modify the core of Umbraco to achieve it.
What you should try and do is see if you can run it entirely out of the macro engine, basically have a .NET macro which is just a wrapper for hosting Spark macros. Then you could have a property on the Spark host which allows you to select the Spark macro to run.
I agree that it is unfortunate to have to modify the core. Basically it was a call between having a solution that integrated nicely into the user/developer experience and a solution that integrated nicely into the core, and I chose the former. That said, I'm currently exploring a solution with custom nodes for the Spark (et. al.) templates, which can be executed from a .NET macro. It requires quite a lot more code, but hopefully it will be OK and not as invasive.
The solution used by the Razor control is also an option, but I'm afraid that mixing markup languages that way may lead to trouble.
Since Umbraco 5 is now in production, did you have any thoughts on using the Spark View Engine in u5?
I too love the Spark View Engine and use it in most of my MVC projects. Personally, I think Spark would've been a much better fit than Razor for umbraco. I'm willing to contribute to some sort of side project, but I'm not sure where to start. Surely swapping out the view engine in u5 is less of an issue than in 4.x as described in your two blog posts, no?
The Razor solution in U4 ended up almost identical to my suggestion, which was cool, but I agree that Spark in many ways feels like a better fit. Closer to the HTML and less ambiguous in its parsing magic..
Adding Spark support to U5 may seem easier, since it's all MVC, but currently I'd say that it's even more hard wired to Razor (cshtml specifically) than U4 was to its base macro languages. But, the core parts are there and I think the most work to be done is making the back end interface deal with new template and macro types.
The well being of the Spark project itself is a bit of a question mark, but I'd be willing to put some effort into this, since I know there are a few developers and designer who are not Razor fans. And your contribition would be welcome.
Using the Spark View Engine
I blogged about this...
http://blog.nexterday.com/category/Umbraco.aspx
..and would very much appreciate your input and ideas.
/Gunnar
The biggest limitation of what you've got is that you need to modify the core of Umbraco to achieve it.
What you should try and do is see if you can run it entirely out of the macro engine, basically have a .NET macro which is just a wrapper for hosting Spark macros. Then you could have a property on the Spark host which allows you to select the Spark macro to run.
That'd save having any modifications to the core.
I agree that it is unfortunate to have to modify the core. Basically it was a call between having a solution that integrated nicely into the user/developer experience and a solution that integrated nicely into the core, and I chose the former. That said, I'm currently exploring a solution with custom nodes for the Spark (et. al.) templates, which can be executed from a .NET macro. It requires quite a lot more code, but hopefully it will be OK and not as invasive.
The solution used by the Razor control is also an option, but I'm afraid that mixing markup languages that way may lead to trouble.
Hey Gunnar,
Since Umbraco 5 is now in production, did you have any thoughts on using the Spark View Engine in u5?
I too love the Spark View Engine and use it in most of my MVC projects. Personally, I think Spark would've been a much better fit than Razor for umbraco. I'm willing to contribute to some sort of side project, but I'm not sure where to start. Surely swapping out the view engine in u5 is less of an issue than in 4.x as described in your two blog posts, no?
Hi Matt!
The Razor solution in U4 ended up almost identical to my suggestion, which was cool, but I agree that Spark in many ways feels like a better fit. Closer to the HTML and less ambiguous in its parsing magic..
Adding Spark support to U5 may seem easier, since it's all MVC, but currently I'd say that it's even more hard wired to Razor (cshtml specifically) than U4 was to its base macro languages. But, the core parts are there and I think the most work to be done is making the back end interface deal with new template and macro types.
The well being of the Spark project itself is a bit of a question mark, but I'd be willing to put some effort into this, since I know there are a few developers and designer who are not Razor fans. And your contribition would be welcome.
/G
is working on a reply...