I would be interested to hear how others are managing their javascript
(.js) files from the original code vs the obfuscated version they
publish to their site/webapp.
I currently manage 2 files, and everytime i need to make a change, I
have to switch the names, test, then rename again, obfuscate to the
original file name (because this is the file referenced in php/perl/asp
whatever files). So its kind of a pain.
Any thoughts out there? Be very interested to hear how you are
managing your files.
Thx,
John
I don't necessarily think of what I do with my code as obfuscation as
much as compression, but for the scripts at
http://www.unfocus.com/projects/FlashSuite/ - I develop using a folder
structure (that I got from an actionscript book - though I've seen it
elsewhere too) - I have a source folder, and a deploy folder (and some
others like an assets folder).
In the source folder I have all of the uncompressed javascript files
(and actionscript files, flas/swfs, etc.) commented all over (am in the
process of switching to JSDoc style comments), with each class in it's
own file, arranged in a namespace like directory structure.
In the deploy folder I have my html files (if I'm using the js classes
for a site) and the rest of the site folders (images folder scripts
folder, etc.). In the scripts folder, I have at least two files, one
that contains every js class that I intend to use for the site, just
copied in from the individual js class files (I usually call it
unFocusLib.js) and another js file with a -p on the end of the name
(like unFocusLib-p.js) which is just the large file compressed with Dean
Edward's packer tool (
http://dean.edwards.name/packer/).
Active development on the js classes usually takes place in an html file
in the source folder, that links to all the individual class files. Then
the working code is just copied to the deploy folder, where the window
dressing is usually applied.
I'm not sure this is the best way, but it is the way I do it for now.
Kevin N.
P.S. I include a link in the compressed files to where you can get the
source code. There's no reason to hide anything.
P.P.S. I haven't released an updated package yet that reflects what I
described here, and am still refining that work process and directory
structure. ;-P