I think Johns problem can be avoided by just resorting to old school
embedding. I also think it can be avoided by using floating divs instead of
popups, or popups within the player.
I have here version 1.3 of FlashObject, I will talk from this since it's
what I've based my arguments on. I understand that it's a package of various
classes, however, this is in theory, where practically, the names of the
functions become the only distinguishable aspect from one class to another.
There may be very valid reasoning as to why the class prototype object is
defined as one statement, as it takes less code to accually define, it is
better optimized than a more readable and extendable definition would be,
however, as it stands, all of the prototype members are defined in one
massive statement.
Again, I'm not trashing your code, I'm really dissapointed to have to make a
point when everyone seems to be taking a jab at you right now. I think there
are very valid reasons why it is the way it is, I just want my point to
remain valid, so I will go on to say that better encapsulation could of been
accomplished by including seperate .js files as seperated classes into
various packaging .js files depending on various tasks, thus, if one were to
just need the function of embeding swf files without any detection or
express installing code they could do so without any redundancy. If one were
to require a combination of functionality from the package, they could
select a composite class that encapsulated this functionality.
I guess this wouldn't take too long to do myself now that I think of it...
What's important is that it's well programmed, it works and has passed
various stress tests.
There is one intrinsic problem that I've noticed with the current technique
for implementing the express installer, I think we've discussed this already
Geoff.
The express installer page doesn't always close after the download and
redirect. It's rather erratic, as it only sometimes happens. I haven't had
time to spend on it. Has anyone else experienced anything like this?
High Regards,
M.
On 4/17/06, Geoff Stearns <[EMAIL PROTECTED]> wrote:
>
> well that's cool, thanks for the response..
>
> the only thing i'd like to address was this part:
>
> > 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.
>
> If you take a look at the code, you'll see that it *is* split up into
> different 'classes' and objects that have their own methods...
>
> the FlashObject 'class' handles the base creation (constructor) and
> writing the HTML to the page.
> for plugin detection, I have another 'class' that handles lookups of
> the flash player version, this is under
> deconcept.FlashObjectUtil 'class'. To do this, it creates
> PlayerVersion objects, which contain methods for comparing versions
> to check if the user has the version that is required or not
> (PlayerVersion.versionIsValid)
>
> then, because it is extremely useful, I've included another 'class'
> for grabbing query parameters (and hash parameters) from the query
> string - this is packaged up in the 'deconcept.util' 'class' (or
> package i guess)
>
> Each of these can be modified / changed / added / removed just as you
> could in any other OOP language (obviously with a few more
> restrictions, since this is Javascript and not some other compiled
> language).
>
> So you can see that it is indeed split up into different sections for
> easier modification.
>
> I guess it helps if you look at the flashobject.js file as more of a
> 'package' than a 'class'.
>
>
> (and as an aside, John's problem can't be fixed by modifying the script)
>
>
> On Apr 17, 2006, at 9:54 PM, Jim Kremens wrote:
>
> > 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
>
> _______________________________________________
> [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
>
_______________________________________________
[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
