I've got an app that consists of a shell app which loads in other modules. As I've made changes and put them on the web of course others on the team haven't seen updates because of older versions they've cached.
Now of course a simple fix is to change the directory I'm uploading to and symbolically linking to that file, but I thought I could get around this by custom compiler arguments...
I've been getting around the caching of the external modules by appending a random number to the url of the module to be loaded by the shell (ie loadModule(blah/blah.swf?123). But this also means that the modules get pulled everytime; that's not needed. I then created a VERSION string in the main app that I change when the modules need to be pulled (ie loadModule(module.swf?+VERSION). That works for the modules but not the main app.
I'm thinking that if I can add some sort of VERSION to the compiler - the Consts I suppose - then I could also use that CONST to compile the file with shell_{CONST}.swf (ie shell_203.swf) and make sure that the htmlTemplate ALSO embeds this versioned file...
Suggestions?
Related
After doing the first Maven install on my new Vaadin 8.1 project created from the vaadin-archetype-widget Maven archetype, and first running my app, I noticed a single new file appeared:
myproject-demo/src/main/webapp/VAADIN/themes/demo/styles.scss.cache
➠ Does it make sense to include or ignore this file from my version control?
By ignore, I mean add that filename to my list of file/folders to big ignored by my version control system. (.hgignore file)
If I intend to share this project as open-source, should I include this file to save a step during build? Or does it get rebuilt frequently, so it would be annoying with frequent changes and needlessly flag an irrelevant change, so I should ignore it?
Using Mercurial for version control.
You can ignore styles.scss.cache. It is generated by the Vaadin servlet after it compiles your style for the first time. Cache entry is controlled by VaadinServlet on row 1107 and it will be good to let the server to create and invalidate this file when necessary.
On the fly compilation of SCSS works fine but if that turns out to be "too slow" you can compile your theme to flat styles.css file with maven. For example, Vaadin is compiling Valo theme into vaadin-themes library and you could do similar artefact from your theme. See Vaadin theme documentation for more details.
I'm considering using LESS for CSS development with server (or development) side processing, but I can't decide if I should keep the generated CSS files in version control. There are plenty of solutions with hooks, but this adds software dependencies to the server. A hook could just be added locally so staging and production areas on the web would get the same files. So, the question is:
Should generated CSS files be included in version control or not? Please keep in mind that some frameworks require a CSS file to exist for a particular reason (i.e. WordPress themes require a style.css file in order to be recognized).
When I say 'considering using LESS', I mean it becomes a requirement. New developers would not have the option use vanilla CSS after the choice is in favor of LESS.
Checking in derived artifacts is almost always sub-optimal.
I vote no to checking in the .css. It's only a matter of time until one of your peers or successors checks in an edit to the .css and not the .less. Then when you change the .less the prior change is lost.
You've pretty much answered your own question. It depends on how you deploy your website.
If the server is just going to pull directly from the Git repository:
1) It needs to have software installed to generate CSS from LESS.
2) or you need to include the CSS files in the repository.
If you're not pulling straight from the repository on your web server, you could have a build script that pulls from git, generates CSS, and then transfers the content to the web server(s), possibly excluding unnecessary files from the transfer.
In my opinion, Git should be used to keep all of the source for a project, and none of the "derived artifacts" (as mentioned by #thekbb). Developers need to have all tools installed to generate those derived artifacts during development and test. For deployment to test and production servers, an automated build server should take the source and create just the files needed for distribution.
In the case of software development, you'd have a Makefile with .C and .H files (for example) in your Git repository. Developers and the build server have a compiler installed that will create an executable or compiled library. When the files are packaged for distribution, the source code is not a part of the archive.
For web development, you have source files like original graphics, HTML templates and LESS files. Developers and the build server can run scripts to generate the site assets (CSS from LESS files, static HTML pages from templates, flattened images in multiple sizes/formats, etc.) When the build server deploys new builds, it copies just the files needed by the server, excluding the source graphics, templates and LESS files.
If there are people that need to review the site content, they should do it on a staging server. If that's not possible, the automated build server can create a ZIP file on an internal server that they can download for review.
Should generated CSS files be included in version control or not?
In theory they should not, but for practicality, I do usually checks in the generated css file. The reason is that it simplifies deployment since I do deployment using git; I would not need to have a less compiler installed on the server and usually not even on the machine I'm deploying from (as opposed to the machine where I'm developing on). Doing this could be useful if you have separate developer and deployer, but can sometimes also be useful even if you're deploying yourself.
Now, there are drawbacks on doing this:
You can't use git add --patch (or you really need to be very careful when doing so)
You should not modify the .css directly; instead I usually use a secondary .css file to do minor modifications without modifying the primary .less or .css file. You can also compile .less file straight into a minified css, to make it less tempting to modify the generated css.
Developers have to set up their machine to use automatic recompile tool (like SimpLess or Less.app), so the .css file is updated as soon as they save to the .less file. Without automation, you'll run into risk of the css not matching the checked-in less file.
I would not do the same when compiling from .C and .H files though, because the generated binary for those are platform specific, and also .less/.css file is usually a very small part of a larger web project so the space overhead of the additional file is small.
Good question. If you can absolutely guarantee that the CSS file gets updated when the LESS gets updated then perhaps yes - as per #Scott Simpson's comment. I suspect that this would be difficult to guarantee and what happens when the new developer get's a copy of CSS the day when they are out of sync? Also, of course, and I hadn't originally thought of this, what happens if the new developer then makes updates to the CSS file rather than the LESS?? If the CSS has to be built and isn't part of archive I can see less problems.
I would say yes -- because what happens if you want to add a developer to your workflow and they don't want or need to build .Less? It would be helpful for them to have access to only the generated file.
I'm building a Flex/AIR application that connects to a remote server, the URL of which changes depending on the environment (development/production, and possibly others). For now, this URL parameter is hardcoded in my root application MXML file but it means I have to change it everytime I build my app for a different environment.
Is there a way to externalize such a parameter so that when Flash Builder automatically builds my app (in development mode), it uses the development URL (http://localhost...) and when Flash Builder exports a release build, it uses the production URL (http://www.mycompany.com/myapp)?
Flex compiler supports something called Conditional compilation, you an read about it here: link. The problem is that it still doesn't give you an way to check if you're exporting a release build or building for debug. Probably the simplest way to achieve that is to use ANT for compilation of the release build and use the conditional compilation from there.
We have several fairly large JavaScript files embedded into a single script resources DLL. This is then consumed by multiple projects by way of a reference and page includes via the ASP.NET script manager. This keeps things nice and neat within our ASP.NET pages and requires very little work to integrate into new projects.
The problem is that some of these script files are quite larger (approx 100KB) and take time to download. By running minify on them before embedding this is reduced down a lot (around 70KB) but not enough. What we would like to do is GZIP the files before they are embedded. However, just gzipping the files causes syntax errors as the content is not unzipped. There is a content type "text/javascript" applied in AssemblyInfo when the resource is embedded but we can't find a way to specify content-encoding.
Is there any way to make this work without having to write a httpmodule/handler (which would mean changing the config for all consuming projects)?
Okay, so it looks, from many different attempts, an absence of answers and a lot of Google searching, that the HttpModule is the only way to approach this. In an attempt to keep this easy to configure I've setup an HttpModule inside the same dll containing the script files as below.
Simplified DLL Structure
\ScriptMinified\*.js [Embedded Resource] (Minified Only)
\ScriptCompressed\*.gz [Embedded Resource] (Gzipped and Minified)
\ScriptDebug\*.js [Embedded Resource] (Raw uncompressed and commented)
MyScriptManager.cs
MyHttpModule.cs
The only additional work is an entry in the consumer's web config to enable the module. Plus I've made the initialize call, in MyScriptManager, that includes the script tags, detect the presence/mode of the new http module and serve gziped, debug or minimized versions as required. This means we don't have to recode or configure any old projects for them to work so achieves much the same result.
I noticed that Eclipse (Flex Builder) generates hundreds of metadata files. Should I check them into my source control? They seem necessary, because if I delete them Flex Builder just opens up an empty workbench...
Some of these files plainly do not belong in source control (like .history files and some cache files). If I delete them my project opens up again without a hitch. But the list is long and there seem to be no clear separation between folders that contain files that belong in source control and those that do not.
I can't just shove them all into svn, even if I were to ignore the inefficiency, because Eclipse generates new ones constantly, with different names, which in turn also seem to be crucial for the project to load.
Can someone please enlighten me?
Don't check in the hundreds of metadata files. If you want to be able to check out the project in a way that it can just be imported, then check in:
.actionScriptProperties
.project
.flexProperties
And "html-template" and "libs". As Christian says, any resources you depend on. I usually keep those as separate Flex Library projects though.
I generally put all of my source code under src, and I check in src and all of its descendents. If my project relies on any external dependencies (e.g., the Cairngorm SWC, as3corelib, etc.), Flash/graphical assets, stylesheets, or resource files, I check those in, too. But I don't check in any generated (bin-*), intermediate or IDE-specific stuff, because having that stuff in source control doesn't seem to provide much practical benefit, and in my experience has only caused me headaches; in general, I check in the most minimal set of whatever I'd need -- given a clean FlexBuilder installation (or none at all -- for example, if I were compiling instead with mxmlc or compc) and an empty project -- to build the project successfully.
Most of the eclipse project files, like .project, .properties, everything in .settings, can go into your source control. As long as the files don't have user-dependent settings like file paths or local urls, you should be fine.
One method we use is creating local property files that don't get used in SCM, but are included in the ones that do. I.E an ant build file including a local.properties file which has local metadata.
What if the .actionScriptProperties, .project, or .flexProperties have user-dependent stuff in them? Typically this will be url or path information. What's the best practice way of externalizing this? I tried creating path variables, but this only works obviously for paths. Not for things like hostname, etc.