I’m curious how you handle updates to things like their ColdFusion frameworks, Javascript libraries, etc?? I’m using JQuery on several projects now and each project I think is using a different version of JQuery.
Do you include your framework and library files in each project?
Do you keep these files in a ‘core’ directory somewhere and reference them from each project?
Just curious how others handle this as I can see it getting worse and worse as I move forward and start using more and more of these (Mach-II, Reactor, JQuery, ExtJS, etc, etc).
I use a global mapping in the CF admin to share a single framework version across all projects.
It depends on the situation. Each of my clients’ projects has their own known, tested version of each third-party library under source code control and integrating updates is just like any other maintenance process (test on localhost, check in, test on QA server, when QA signs off, roll to production).
Usually with servers where I have multiple applications running, I try to keep them all on the same version of everything and manage them centrally (still under source code control of course).
Interesting question and one which I still ask myself.
As Sean is fond of saying…”it depends”. Even if I have full control over the server(s) with multiple projects, only one of those might want to take advantage of new functionality requiring a framework upgrade. I don’t want to have to needlessly test all other projects on that machine.
So really at this stage I tend to have a copy of the physical framework files in each project. Means a bit more work if you actually do want to upgrade ALL projects on that server, but more flexibility in the long term.
Some people use svn:externals to link an external codebase into their project, but this seems dangerous to me as well.
Looking forward to seeing what other ppl think.
Thanks for the feedback everyone. I agree – I like the idea of a central single copy but you would need good tests setup for each application. Hopefully I’ll get things automated to that point this year!
On my server I have a folder for each version of a framework that I have ever used on a project like…
fusebox500
fusebox510
fusebox550
spry150
spry160
transfer063
…then for something client-side like Spry I create a IIS virtual directory just called spry which points to the version of spry I want to use, say spry150. For CF8 I create a mapping in Application.cfc for, say fusebox5, that points to the version I want to use like fusebox510.
Then when a new version of a framework is released I create a new server folder for that version and then I can experiment with my existing applications by just changing the virtual directory or mapping to point to the new version without having to change my code.
So I have a single instance of each version of a framework used by multiple applications with an easy version testing configuration.
Great use of CF8s mapping feature!! When we move to CF8 I’ll have to remember that!
I’ve done that for different versions of FarCry before, but in general the “mappings” in CF8 Application.cfc are a major let down so I never use them.
Michael – in what way do you find the CF8 mappings lacking?
I mean the CF8 “per application” mappings you can set in Application.cfc (this.mappings)
As this ‘feature’ is a runtime mapping, not compile time, it only works for CFC paths when instantiating an object etc.
It does NOT work when using cfimport, extends=”" and implements=”" and *possibly* cfinclude (I can’t remember about cfinclude and I’m on cf7 at home so I can’t test to be sure).
The fact that it doesn’t work with cfimport alone is reason for me never ever to use it.
A few people have commented on the possible ‘misleading advertisement’ on this by Adobe and I tend to agree. But people like Sean Corfield have said that it’s kind of obvious (and the docs say) that this won’t work across the board as mappings in CF Adminstrator do.
Either way it’s a disappointment.
I have a separate repo setup for all the JavaScript libraries. The trunk of that repo is setup through an IIS virtual directory or an Apache alias to /js on the server. Then all my projects use /js/jQuery.js or /js/prototype.js to access the needed scripts. This makes upgrading and adding new libraries easy.
It does work for includes (of course: include is a *runtime* construct) and it works for extends for the first instantiation of a class (you can’t change the runtime setting and expect CF to figure out which classes need to be recompiled).
@Sean – thanks for the clarification Sean :)