Another request to fix Thunder website templates projects

Hey,

I know its not cool or that much fun to rebuild it from scratch but with VisualStudio 2012 offering bundling, minification and even LESS support we could really use a 'normal' project type. Attached you'll see a screenshot of a 'Website template project' and a regular project underneath.

Not only does the website template project not show all the files (on save it creates 3 css files). It also creates them 3 levels higher than the original source file, this probably stemming from the fact that the 'Theme1' folder isn't recognized as an actual folder.

---
Aside from VisualStudio, even Telerik's JustCode extension doesn't understand/recognize anything inside of a Website Template project...

 Jochem

Hello Jochem,

The idea behind the Website Templates project was to make a lightweight container for website templates together with their master pages and themes. Its functionality cannot match what you can do in the Sitefinity project itself.

If we change the MFP project to a flavoured C# project, we will need to make it a web project with a web config in order for the master pages to have intellisense for the controls in the referenced assemblies. What we will essentially end up with is a copy of the Sitefinity project.

However, you can already do this. You can download and upload website templates and themes to and from a Sitefinity web project just like you can with a Website Templates project. If you do not wish to edit the project itself, you can have a second Sitefinity project where you can download the website templates, edit them and upload them back to the server when necessary.

Please let me know if I can be of further assistance.

Regards,
Marin Atanasov
the Telerik team

Hey Marin,

I understand that MFP differs from regular since we talked about it a while back and I'm not pleading for NuGet package support or anything ;)

I was just pointing out that with VS2012 being released and most developers are switching to some form of preprocessing/minification 'actual folder' support would be a huge advantage.

---
Perhaps instead of having this as a leight-weighted solution, why not turn it into the heavy weight solution?

The average user merely playing around with a masterpage and some stylesheet are served perfectly with the general Sitefinity project, but an instance independent template project that I can instantly hook up to any Sitefinity would be of far greater value and keeps my .less & package files isolated per 'theme/template' combo where I want them.

A setup like that would also work perfectly together with the Marketplace no? Thunder itself has great value, and I understand its a free add-on, so please just consider it a suggestion placed in the Thunder forum instead of the suggestion thread.

Jochem

Hello Jochem,

I understand why you would want a more powerful solution for the themes/templates. However, having anything less than a Sitefinity project would reduce its usefulness.

Currently you have a Website Templates project which is very simple and lightweight but lacks a lot of the functionalities. On the other hand, you can use an empty Sitefinity project where you can download, edit and upload themes/templates to other Sitefinity projects. It has the complete functionality but takes more space. Sitefinity Explorer supports both downloading to and uploading from both Website Templates projects and SitefinityWebApp projects.

Would changing the Website Templates project or adding a third option that would fit somewhere between these 2 already available options bring anything to the table?

Please note that I am not dismissing your feedback or suggestions. I am just trying to understand the value of the suggested functionality.

Kind regards,
Marin Atanasov
the Telerik team

Hey Marin,

You’re always welcome to dismiss my feedback :) Suggestions are opinioned ideas, each one of us works differently and has their own set of ideas what constitutes smart & best practices…

A solution somewhere between the current ‘website template’ and a full-fledged project would be a welcome addition. Like I said yesterday, we’ve got different perspectives on things where I see customers using one regular website project to keep things ‘simple’ and front-end developers wanting Thunder to give them a flexible template project.

 The main design parts of any website are the masterpages, the css and the javascript. Those are often unique for every different site. The current ‘template project’ handles masterpages perfectly yet it offers no wiggle room for the other parts…

The css limitations.
Like I said before, most progressive developers use some form of pre-processing or bundling these days when it comes to .css. Perhaps you’re a .LESS fan, others might use SASS and others might just write .css and minify it on save through a VisualStudio extension. (I think it’s fair to say that with VisualStudio 2012, Microsoft’s Web Essentials extension will become a defacto standard extension across the board no?) 

But regardless of whether you use WebWorkbench, Chirpy or Web Essentials all of them struggle with the website template project. Either because they don’t understand ‘nested’ files or they don’t recognize a template folder as a regular folder.

The JavaScript limitations.
Regardless of whether it’s custom .js functionality or a standard library, JavaScript is theme/template related (for site A you might use jQueryUI, and for site B you might use KendoUI). The bundling & minification limitations that I mentioned for css also apply to JavaScript. 

But beyond that, one of Microsoft’s greatest addition, NuGet, totally isn’t supported. The only way to get some NuGet integration is to clutter my main project to include script packages.

Imagine refactoring a theme/template
Imagine version 1 using .css and jQuery 1.7.1 and jQueryUI, if I wanted to test/trial/enhance version 2 to be build on Twitter Bootstrap with .less, jQuery 1.7.2 and  KendoUI instead, currently I would have to completely mess up my main Sitefinity project. 

Javascript getting pulled in from NuGet needs to go into the main project, which would cause jQuery conflicts as there would be two now. Pulling in another NuGet package (KendoUI) would cause all kind of source control repository issues because the package manager and the scripts would be
registered in the main project.

In order for bundling of the .JS to work and not affecting v1 of the design, I’d have to create the folder structure App_Data/Sitefinity/WebsiteTemplates/TemplateName/JS in the regular project and have the .js combined there while the template (inside the template project) references the file as if it would be there inside that project).

So my solution would always need to have 2 projects, one of which is the main Sitefinity project, which I have to break open and cross-reference to get things going. Twitter Bootstrap would cause a number of issues, again a NuGet package, but also the fact that its .LESS. 
 
Now imagine I want to transfer this new v2 design to another user/computer. Instead of just being able to hand over the project, instead they need to include parts of the main project as well (nuget package configuration, minified scripts). In which case their original solution/project will get cluttered.

If we had some kind of option, that all this would be inside an isolated project, which I can simply zip up or check-out, life would be so much easier.  Not to mention the ability to export/save this as a NuGet package would be even sweeter no?  

If Sitefinity would publish their own Marketplace feed, people could instantly download & update right from VisualStudio instead of having to browse to the marketplace, download a zip, extract it and manually copy/paste the bits into places.

---
Ok, long and boring use case description but I hope I made my point that beyond average single-site users theming & designing can become a bit cumbersome with the current tools available J

Jochem.

I would welcome what Jochem is asking for as well.  Visual Studio 2012 brought with it some great new additions in the realm of optimization for bundling and minification.  Right now it is not possible, unless I am missing something, to maintain the preferred/recommended structure for templates and use bundling/minification without jumping through a lot of extra hoops that in the end are probably just as time consuming as if I were to run yui through the command prompt and bundle/minify pre-launch of a production site.

If I want to setup the new bundling features with .NET 4.5 I would need to create my masterpages and themes outside of the App_Data folder so that I could register the bundles via the configs and then add the render tags within the masterpage.  By doing this I am now breaking the convention that Sitefinity has stated templates should use. 

I am also now trying to make use of LESS and and having a hard time finding an acceptable work process that does not make me less efficient than just writing straight up CSS.  What I mean by this is that I can now get LESS syntax support through Web Essentials + 2012, but the fact that Sitefinity automatically loads all css in the global folder means that it would load the LESS files plus the processed files that Web Essentials spits out.  I have seen Jochem talk about marking the LESS files to not be included in the project build, but now we are talking about having one more extra dev setup where all I am doing is building/publishing and then a separate dev site that I test everything out on.  Obviously this is not unheard of and I am familiar with having dev/staging/prod scenarios, but it feels like a lot of setup just to get support for .NET features that I feel are going to become staples as time goes on.