I use spark view engine in my MVC 2 project. By default, Spark tags are unqualified, without prefix. My question is: Do I gain performance when put prefix in my web.config file? Put differently, whether spark files compile faster with prefix?
Compilation will not be any faster or slower with the prefix.
Spark not only outputs HTML, but is equally capable of outputting valid XML, and in the latter case, you very often need to qualify your tags to maintain valid XML.
None of this will effect compilation time. It is recommended however, regardless of this, that you precompile your views for production anyway to improve performance.
Related
I am working on automating the translation workflow and improving the Localization process as a whole of a Rails website. I am using SimpleBackend so only YAML files are used for storing translations.
The current locales directory consists of folders, then sub-folders (in some cases) and those sub-folders containing yml files. I am considering to integrate the project with some third-party tool like Transifex for translation management so may be using a single YAML file for each language may be good for management of workflow.
If someone can highlight the pros and cons of both structures then it would be really helpful to decide whether I should switch from nested file structure to single file pattern or not. Also, the project is an Open-Source project with active contributors and so thinking for a long-term solution.
Thanks!
I think whatever tools you are using to make the process flow smoothly factors a lot in this decision. You should explore how exactly Transifex wants things to be structured in output, and try to keep your current input structure, and give that a shot before making a decision.
However, in my opinion, for a large app with a lot of translatable text, my preference would be to allow for multiple yaml files in your default locale, and one or two consolidated yaml files for each foreign translation. If there isn't a lot of translatable text in your app, maybe a single file is fine for you, but given it's already split up, there's a good chance that's the better choice. On a team with many contributors you can end up with a very high churn file (maybe with a lot of merge conflicts) that everyone changes all the time.
Splitting into separate files lets you logically separate out text to match a domain in your app, like a separate yaml file for mailers (or even each mailer), and one for each domain (or controller). Either way, it puts you in control of your organization strategy.
However, there isn't a lot of value, IMO in separating your foreign translations to mirror that structure. The systems I have experience with (not Transifex) generate your foreign translation files for you, so you just need to sync with the web interface and commit the results.
I am using MVC3, ASP.NET4.5 and C#
There are a number of choices when precompiling a web application:
Do not Merge.
Do not merge, Create a separate assembly for each page and control.
Merge all outputs to a single assembly.
Merge each individual folder output to its own assembly.
Merge all pages and control outputs to a single assembly.
I am deploying to Azure websites.
I have currently opted for 3 which creates a 2.5MB assembly.
I realise that PCode is generated at this point ready for the Jitter to create the Native code at runtime, and therefore performance should be identical. However I was wondering whether there was still a performance difference between these options. I have currently chosen option 3, because it seemed tidier.
Thanks.
There should be a performance impact based on your chosen merge option. How big? Uncertain without testing, but intuitively if there are more assemblies and files for your application to access, that should take longer than accessing a single assembly. My guess is the difference is minuscule. The assemblies themselves should not experience a performance impact, but your performance would suffer slightly in an un-merged scenario as there would be more files to process at run-time.
Additional resources that might help:
Additional Precompile Settings Dialog Box
ASP.NET Merge Tool, Compilation and Merge Scenarios
we have set of feature file which have scenarios shared between mid-tier and UI using tags ( #services , #UI )
Now when i give this feature file to Specflow . it generates the test-runner wiring for whole feature file.. including #services scenarios
which is useless as we don;t implement them at UI level.
So my question ..is there a way to tell Specflow that only auto-generate test-runner wiring code for scenarios which are tagged with #UI ..?
Apart from the obvious answer of splitting your feature file into UI.feature and Services.feature, then no. There is no way of getting generating multiple .feature.cs files from a single .feature.
However can I suggest that this mixing of steps is indicative that your specifications are crossing domains, which usually suggests that they are might be very technical instead of behaviour driven.
My web site (on Linux servers) needs to support multiple languages.
What is the best practice to have/store multiple languages versions of the same site?
Some I can think of:
store in DB
different view file for each language
gettex
hard coded words in PHP files (like in phpBB)
With web sites, you really have several categories of content to consider for localization:
The article-type content elements that you would in many cases create, edit and publish in a CMS.
The smaller content blocks that are common to every page (or a sub-group of pages), such as tagline, blurb, text around a contact form, but also imported content such as a news ticker or ads and affiliate links. Some of these may only appear for one language (for example, if you don't offer some services in some regions, or don't have, say, language-appropriate imported content for a particular language: it can be better to remove an element rather than offering English to people who may not speak it).
The purely functional elements, like "Click here to comment", "More...", high-level navigation, etc., which are sometimes part of your template. Some of these may be inside images.
For 1. the main decision is using a CMS or not. If yes, you absolutely need to choose one that supports multiple languages. I'm not up-to-date with recent developments in PHP CMS's, but several of the Django CMS apps (Django-CMS-2, FeinCMS) support multi-language content. Don't forget that date stamps, for example, need to be localized, too (or you can get around this by choosing ISO dates, though that may not always be possible). If you don't use a CMS, and everything is in your HTML files, then gettext is the way to go, and keep the .mo files (and your offline .po files) in folders by language.
For 2. if you have a CMS with good multi-lingual support, get as much as possible inside the CMS. The reason is that these bits do change, and you want to edit your template as little as possible. If you write code yourself, think of ways of exporting all in-CMS strings per language, to hand them to translators. Otherwise, again, gettext. The main issue is that these elements may require hard-coding language-selection code (if $language = X display content1 ...)
For 3., if it's in your template, use gettext. For images, the per-language folders will come in handy, and for heaven's sake make choose images the generation of which can be automated, or you (or your graphic artist) will go mad with editing 100s of custom images with strings in languages you don't understand.
For both 2. and 3., abstracting from the language selection may help selecting the appropriate blocks or content directory (where localized images or .mo files are kept).
What you definitely want to avoid is keeping a pile of HTML files with extensive text content in them that would be a nightmare to maintain.
EDIT: Everything about gettext, .po and .mo files is in the GNU gettext manual (more than you ever wanted to know) or a slightly dated but friendlier tutorial. For PHP, there's are the PHP gettext functions, and also the Zend Locale documentation
I recommend using Zend_Translate's Gettext adapter which parses mo files. Very efficient + caching. Your calls would be like
echo $translation->_("Hello World");
Which would find the locale specific key for that specified string.
Check out i18n support for php: http://php-flp.sourceforge.net/getting_started_english.htm
Using the Grails YUI plugin, I've noticed that my GUI tags are replaced with some JavaScript code that is inserted in the HTML page.
Does this behavior contradict the Yahoo rule of making JavaScript and CSS external?
In other words, how do I separate the script code from the HTML page in order to allow external JavaScript script caching?
Should I use the Grails UI performance plugin for that matter? Is there another way to do it?
Everything in software design is a trade-off.
It depends on if the benefit of performance overweights the importance of having well segregated and maintainable code.
In your case, I wouldn't mind having some extra JavaScript code automatically added to dramatically improve the performance.
Complete code and UI separation always comes at a price. More levels of abstraction and intermediate code often translates into slower performance, but better maintainability.
Sometimes, the only way to reach maximum efficiency is to throw away all those abstractions and write optimized code for your platform, minimizing the number of functions and function calls, trying to do as most work as possible in one loop instead of having two meaningful loops, etc. (which is characterized as ugly code).
Well, this is one the features of the UiPerformance Plugin amongst other things:
The UI Performance Plugin addresses some of the 14 rules from Steve Souders and the Yahoo performance team.
[...]
Features
minifies and gzips .js and .css files
configures .js, .css, and image files (including favicon.ico) for caching by renaming with an increasing build number and setting a far-future expires header
[...]
So I'd use it indeed.