This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Guys, Web Workbench has one significant drawback - its performance.
Each language supported by Workbench (SASS, LESS, JS) requires some time to compile, there is no obvious way to make the process faster. The problem can be solved only if you put code-generation in background thread.
The concept of application based on Visual Studio BaseCodeGeneratorWithSite fucility which support's only synchronous generation of files. But, I think, it's possible to just return empty string in BaseCodeGeneratorWithSite's GenerateCode method and start background activity (process, thread, external app, whatever that will work in this case) to generate the file. Actual file content will be populated in a second after Save. I think it is not problem - it will not be visible to user. |
|
|
Guys, I found another, more significant, problem in approach with custom code generation based on BaseCodeGeneratorWithSite. Generally SASS language supports import of one files to another using @import directive. But if you change a file used by other files - they won't be updated automatically.
Let's look at following case: You have to keep compatibility of your web application with IE6, IE7 and modern browsers. For me, the easiest solution there is to create three .scss files: - Site.scss (stylesheet for all modern browsers, delivered by default if browser is not IE or IE8+) - SiteIE6.scss (if IE6 detected) - SiteIE7.scss (if IE7 detected) With similar contents: Site.scss // Main stylesheet with conditional styles for specific browsers $ie-version: $999 !default; ... $if $ie-version <= 6 ... SiteIE6.scss // Defining IE version and importing all styles from the main file $ie-version: 6; @import "Site"; SiteIE7.scss // Defining IE version and importing all styles from the main file $ie-version: 7; @import "Site"; This example shows us how flexible and useful conception of modular stylesheets. But with current version of Web Workbench after every change in Site.scss I have to open each depending file (SiteIE6.scss and SiteIE7.scss) and just press Ctrl+S to apply changes in imported file.
How we can overcome these limitations? 1) I think, Web Workbench should stop rely on BaseCodeGeneratorWithSite for code-generation and be implemented as a VS AddIn which subscribes on various Sulution events (solution opened, solution closed, solution item added, solution item changed etc.) and tracks all existing .scss files. 2) For all existing in opened solution .scss files Workbench AddIn stores in memory some kind of dependency graph. Dependencies between .scss files can be determined (in background thread) using simple regual expression. 3) When AddIn receives 'Save' event for a tracked .scss file - it rebuilds file, also looks at dependency graph for dependencies - and recursively rebuilds them too. Everying happens in background, VS doesn't freeze on each Ctrl+S, end-users very happy. 4) Custom code generators (BaseCodeGeneratorWithSite) should be still used to these files. But they will be fakes, doing nothing (they will return empty content). They needed for one single reason: if user opens .scss file (created by Web Workbench) in Visual Studio without Web Workbench intalled then Visual Studio will warn him with error message that Custom Code Generator not found. Also, I guess, the best behaviour for Web Workbench is to tack (and rebuild) files created only by Workbench itself (and keep untouched other files). Because Workbanch cannot know - wants the user to automatically rebuild his files or not. Exitance of specified code generator for a file will that the file should be tracked and builded on Save.
Thanks, Sergey
|
|
|
+1 from here. A bit sad to see that noone from Mindscape has responded to the ideas presented here. |
|
|
We shipped a performance update at the end of last week, which should greatly improve highlighting performance on large files (for what it's worth, we have always done highlighting on a background thread). We have some work in the pipeline that will allow us to look at making compilation faster and less intrusive and hopefully we'll be able to get onto this in the next couple of weeks. |
|