ASP.NET MVC Spark view engine for designers, do they like it?

Question

I am in the process of building a large asp.net Mvc project and have a question regarding the default rendering engine opposed to the MVC Spark engine in the context for designers.

I am all in favour of reducing my tag soup and can see that the spark engine is neat, very neat and I for one would welcome it. However does anyone have an experience/opinions on whether their design team has embraced it or been opposed against it?

My designer team has yet to develop using the Mvc framework so they are either going to have to learn the default or spark engine.

Can anyone comment?

Answer 1

You're design team should not need to have any knowledge of the view engine at all. They should only need to know about the final product from the view engine (i.e. the HTML, CSS and Javascript that is output).

Your designers can make templates from plain old HTML and CSS, without ever seeing a single line of rendering engine code. You just have to tell them the places in the template you are going to inject the content.

The whole point of CSS/HTML templates is to provide separation between the designer and the developer. This allows these templates to be farmed-out to a design shop. You don't want the design shop to have to mess with your development code.

The designer will also be providing you with a set of text styles: h1, h2, h3, p ,etc. You will be able to plug those styles in wherever you need them in the templating code of the rendering engine to achieve the desired effects. If you wish, you can let the designer dictate some rules about the layout and use of these styles, but it's still your job to write the code that renders the output into the designer template.

So to be clear, the designer's job is to create an HTML/CSS template for you (with sample content and styling so that both of you can adequately see the layout). Your job is to incorporate the CSS/HTML the designer provides you into the view engine code.

Spark is just an HTML-ified version of C# (or VB). All other things being equal, Spark would be easier for a designer, because it changes all of the <% { %> things to HTML equivalents. But that assumes that the designers will be writing the template code for the view engine, which they won't be.

Answer 2

I know this question is considered 'answered', but let me answer from a 'designer' (we call it Front-end Developer) perspective.

We have a back-end (C#) team and a front-end (HTML/CSS/Javascript) team that works on .NET MVC Applications. Spark is a much more natural way to do HTML Views. Sparks adds a natural way to do ifs and loops by adding 'if' and 'each' statements as attributes of the HTML element instead of loops outside HTML tags in <% %> tags. Partials are also called from an intuitive manner. <dashboard /> will include the partial "_dashboard.spark".

Spark makes all View markup look like HTML, which I think is very important for Maintainability. It also forces good MVC habits by keeping as much logic as possible out of the View markup. The design team and create the HTML markup and the developers can then add the little bit of logic to get the content generation going.

With Spark, we have minimized the issue of ugly code and have kept front-end and back-end work separate, yet still fluid and maintainable.