Hi Geoff,
I'll reply to your comments inline below...
"First, I guess I'm not sure why you would need to 'maintain' it. The
script is basically just an API for writing the HTML to embed a swf
file into an html document. This probably won't change significantly
any time soon, so the need to 'maintain' a script like this is non-
existent."
I said 'maintain' - a more accurate word would have been 'modify.'
John Grden ran into an 'edge case.' In a case like that, he might
have chosen to dive into the script to refactor the code in a way that
involved more
than just extending it.
"Second, maybe you were looking at the compressed version? I
include a version of the 'source' code that is much easier to read if
you are into that."
I was reading the compressed version. What a dumbass... For some reason
I just didn't see the 'source' directory there. Certainly helps... :-)
"As far as the misc. accusations about FlashObject not being Object
Oriented, (Jim said: 'IMHO, the code is very procedural, not object
oriented. The cues for this are the endless conditional
statements. A good, encapsulated architecture can greatly minimize
these...')"
The code is object oriented - that comment was inaccurate. I think it could be
*more* object oriented, if that makes sense... In other words, I would
prefer it if it were
refactored in a way that further encapsulated the various tasks it performs.
As far as the conditional statements are concerned, the red flag for
me is seeing conditionals that include seemingly unlike things:
if(this.skipDetect || this.getAttribute('doExpressInstall') ||
this.installedVer.versionIsValid(this.getAttribute('version'))){
I'm sure all of that makes sense when you're the guy who wrote the
code. And of course, I can take the time to figure it out
so it makes sense to me as well. I just think that, for my taste,
this file is trying to do too much. I'd rather the functionality were
broken out into separate classes. I alluded to the Strategy pattern
only because I use it all the time. It forces me to make small
classes that
really only do one thing. That style of coding used to annoy me, but
I've learned to love it because once you understand how things fit
together, everything's incredibly easy to modify. And it can
eliminate the need for lots of conditional checks that are otherwise
unavoidable.
I still think Elibol said it extremely well:
The FlashObject class would just embed swf files. Any additional concerns
would be seperated from this class, where each class would interface to
operate with one another....As it stands, all of the features are
crammed into one class file, the
FlashObject.js, making it very hard to add/remove functionality without
fundamentally reprogramming the entire tool."
It all comes down to a matter of taste. For better or worse, my code
looks more like Java than it used to. (I think too much Java is a
disease,
but there's a lot that can be learned from Java or C#). I know
Javascript isn't Java, and it isn't even Actionscript. So it's unfair
of me to
complain about it. The javascript that I do like typically resides in
larger JS frameworks, like DOJO. Frameworks allow for
more encapsulation, more OOP, listeners, and all the stuff that I've
come to rely on in Actionscript. But FlashObject isn't a framework,
and it shouldn't be measured by those standards. FlashObject is a
tool that fills a very important niche and does so extremely well.
I hope we can now end this thread... If you disagree with me (and it
seems most people do!), it's just one guy's opinion :-)
Jim Kremens
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
