PHP: Object Oriented Programming

[printelectric]

I actually do have one example that I've done. It's the reason I bought the AS 2.0 book, and had to learn it in a hurry. It was designed to be exclusively on CD, so it's a little big (4 mb) - but not considering what it delivers.

The portion of the assignment which forced me to use Flash was the inclusion of 500 technical paper abstracts, which had to be included on CD, and which had to be searchable by several different categories. All of this had to be achieved without any internet connectivity at all. So it had to be some sort of compiled application.

The big things (for me anyway) that I developed on the way were an object oriented menu system, consisting of about 3 classes, and a system to read and sort XML data. The menu system builds itself from an XML file - here's a chunk of it...

<?xml version="1.0" standalone="yes"?>
<menu>
<level1 menuLabel='Schedule at a Glance' menuData='schedule.swf'>
</level1>
<level1 menuLabel='General Information' menuData=''>
<level2 menuLabel='Registration' menuData='registration.swf'>
</level2>
<level2 menuLabel='Housing' menuData='housing.swf'>
</level2>
<level2 menuLabel='Transportation' menuData='transportation.swf'>
</level2>
<level2 menuLabel='Visa Information' menuData='visa.swf'>
</level2>
</level1>
<level1 menuLabel='Short Courses' menuData=''>
<level2 menuLabel='One-Day Courses' menuData='1day_courses.swf'>
</level2>
<level2 menuLabel='Two-Day Courses' menuData='2day_courses.swf'>
</level2>
</level1>

The menu class reads the XML file, creates a menu button instance (another class) for each top-level menu item, determines whether or not that item has submenus (level2), and then replicates the process for each of those level2 items. So you end up with a hierarchical menu that you can edit by simply editing and XML file. The menuData entry in my XML files references the content which each menu button will load when pressed.

The other big chunk of content that I had to develop was the search function. It reads a 500+ page XML file (in this case) into an object called searchData. Different chunks of the data can then be pulled out of the object for display, depending on the user selections.

You can look at this project online at http://www.printelectric.com/ - it is the 1st example in my interactive portfolio. Keep in mind this was my 1st project ever using OOP, so it is a looooooong way from something I'd hold up as best practices or clean code. I was also on a deadline, and I was learning both OOP and Actionscript 2.0 on the way. It also runs a heck of a lot faster on CD, but you'll get the idea.

To my knowledge, Flash was the only way to get this thing done on the timeframe that was required. I put it together in about 8 weeks, from concept to delivery. The intro is NOT done with code - it was done by a subcontractor, and uses old-school Flash techniques - tweening and keyframe animation.

You should check out Colin Moock's site (moock.org). It's very experimental, and frankly far less usable and fun than his old site : ( but he's doing some wacky stuff with Flash. He's been developing multi-user environments with Flash for a few years now, and he's developed a multi-user development 'platform' called Unity, which I believe is entirely Flash object based.

Finally, if you just google OOP actionscript, there's enough info in the first few links to get you started. Samuel Wan also has a good AS OOP book, and I think there are a couple of sample chapters available for reading on Amazon. It's old info, as it relates to AS 1.0 instead of AS 2.0, but the basic OOP info is the same. Actionscript 2.0 just provides a lot more support for OOP features, and a compiler that tells you a lot more about what you've screwed up and where, if you use it right.

Also, feel free to email me if you'd like - scott@...

[printelectric]

This is silly, but if you go to the front page of moock.org, and you're the only user, you can't get anywhere. The multi-user environment requires that other users complete your transfer to the next page! You can do it yourself if you open another browser window. But just in case, here's a direct link to the good stuff.

http://www.moock.org/webdesign/flash/

[ATS16805]

all i can say is "Impressive!". i don't know where else to begin! the stuff demonstrated at printelectric.com is far beyond anything i could dream of creating.

but, i'm still curious, since you've provided the specific example, can you tell me in layman's terms (as much as possible) what part AS and OOP playing in the realization of that project?

also, and this must sound so ignorant, but when using Action Script as a programming language, are you working in the Flash MX application, or is this something that you're hand-coding into the html? that's the part where i'm clueless. for example, i have a copy of Flash MX. supposing i knew enough to complete a similar project, how much of it would i complete inside of the Macromedia app, and how much of it could be done w/ a text editor?

i see also the php file extension, so you're using XML to tell flash what to do w/ the PHP? wow. it's really over my puny head! give me a few years of intense study, and maybe it will make sense. very intriguing stuff nonetheless

[printelectric]

The best way that I can explain it is that the framework (background elements, menus, and the rest of the interface) were all coded in Flash MX Professional. Actionscript 2.0 introduced a new file extention, .as (for Actionscript). The distinction between what is OOP and what is not becomes a lot less distinct when you start working with it, especially in Flash. OOP is just a way to take a set of things which have an existing relationship, give them a name, and formalize that relationship in a way that makes the resulting code cleaner and more efficient. When the application launches, it imports all of the class files, and creates an instance(object) of a class. That class in turn creates other objects. Some of those objects then import symbols from the Flash library, or external XML data, or entire other Flash movies. So the structure which drives the application is essentially all OOP, but the individual pages and elements are not.

Each page of content was first built in InDesign, converted to PDF, then to Illustrator. I know this sounds insane, but InDesign is the best tool for typesetting and page layout by far, and we had a lot of content to put together quickly, that had to also look good. From Illustrator, pages that needed to be interactive (with links) were converted to EPS and then opened in Flash to add links. The links are done with the most basic Actionscript, and are just attached to individual pieces of text within the Flash document. The pages which didn't need links were ripped to .swf format directly from Illustrator.

You can do OOP badly, and end up with classes (a class is the template for an OOP object) that don't really work that well together. You can do it well and end up with a application that is much more efficient than it could ever be as a non- object-oriented program. The thing that takes time and practice and a lot of head scratching is to know when something should be built as a class/object, and when it shouldn't. Someone mentioned the car example earlier. It seems simple. A car is an object. A car has wheels, therefore wheels should be a property of the car object, as should seats, steering wheels, color, make, model, and everything else about the car. A car is easy to think about because it's a concrete object, and something that everyone is familiar with. When you start thinking about more abstract objects - user interfaces, search engines, etc. - you find that it is far less intuitive to decide which elements should and shouldn't be members of a class. When you get to that point, look at design patterns.

I've actually just started trying to work some OOP into my PHP work. So far, I haven't found that much info on the subject. That's why I would recommend looking at Flash to start with. There's a lot more information out there.

Incidentally, my web site does not mix Flash with PHP. The web site is all PHP, Javascript, and HTML. Javascript actually does all of the work for the menus and the user interface. PHP is used mainly to pull info from MySQL and write it into the page. The only Flash is in the 2-3 portfolio pieces that use it.

[Weedpacket]

Another thing to point out is that both Actionscript and Javascript are in fact both the same language - ECMAScript. The only difference lies in what is controlled by the objects and interfaces provided by the environment.

[cyberlew15]

I didn't think weedpacket was right when I heard his post and He is not by no means should you learn javascript to benefit your actionscript or vica versa it does not work. JavaScript was the projenitor ECMA is simply a specification to which client side scripting languages can either conform to or not please read http://en.wikipedia.org/wiki/ECMAScript before flaming on and on. Yes modern javascript, Jscript, and Actionscript are ECMA based as in they conform to it's standards but in no way are they even remotely comparable. it's like trying to compare the propulsion systems of hovercrafts and sailboats they both travel across water but are fundamentally different only the basics are the same

[laserlight]

I didn't think weedpacket was right when I heard his post and He is not by no means should you learn javascript to benefit your actionscript or vica versa it does not work.

hmm... but Weedpacket said nothing about learning one to benefit the other - he merely stated what you confirmed, that the underlying language is the same, but otherwise they are different.

[cyberlew15]

Oh I must have Imagined this statement

Another thing to point out is that both Actionscript and Javascript are in fact both the same language - ECMAScript.

Oh yeah and I suppose i imaginged the rest of the post

The only difference lies in what is controlled by the objects and interfaces provided by the environment.

absolute rubbish actionscript utilises a much more advanced control of it's DOM(the flash DOM)

Also One is Compiled and the other is interpreted Once again Laserlightyou are playing semantics with words and not really understanding the underlying issues of the subjects. and again ECMA Script is not an underlying Language merely a specification for languages to comply to.

[laserlight]

Also One is Compiled and the other is interpreted

Such differences dont really count here - all compiled languages are interpreted at some level.

and not really understanding the underlying issues of the subjects

That's probably true - I have never learnt Actionscript, and although I started out with Javascript I dont have much experience with it.

ECMA Script is not an underlying Language merely a specification for languages to comply to

From the link you gave that appears to be inaccurate - ECMA Script is indeed a scripting/programming language, but Actionscript and Javascript are compatible with it.

[cyberlew15]

there is no ecma script interpreter go to http://www.ecma-international.org/memento/index.html and look for a download
oh have you only found information on standards. if the company that was paid to build the standard does not offer an ecma scripting module then it is not a language. I have e-mailed them so far with no answer I think if you read the original link ECMA was the specification for the old Jscript and Javascript that they were paid to write so that the wo technologies would be more closely integrated. if you strongly disagree with what I am saying post me a link to a page using an ecma script.

Such differences dont really count here - all compiled languages are interpreted at some level.

at some level all languages are interpreted eh what about machine code elmutt. I'm sure this is all because I made a post here and you just want to annoy me with your word games it cannot be a serious argument because you are wrong it is in writing I swear you must be one of those nutters that reads spot had a ball and expects it to have levels

[thorpe]

the ecma scripting language itself does not provide (nor need to) the environment in which it needs to run. that is up to the host to supply.

if your here to pick arguments, you might want to read up on the subject itself. just as you where wrong about VB, C and basic being object orientated languages, your points about the ecma scripting language are distorted.

[cyberlew15]

You may wish to do a little reading yourself as ECMA Script is a standard not an implementation. I have received an e-mail from it's creators confirming that there is not and never will be an ECMA Script parser sanctioned by them. they went on to write just what i have been saying that it is a standard. It is quite annoying that lots of people are continuing this argument I only wanted to do a one off post to educate some people but it seems they are ignoring this. I resent the inference that I am simply starting arguments. You would'nt moan so much if I supported good advice that you give but yet at the slightest hint of criticism you seem to blow up. Weedpacket has obviously read the original link and followed that links suggested reading and because weedpacket is able to take constructive criticism weedpacket will grow as a developer you guys seem to be the ones starting arguments Thorpe and Laserlight. How amazing that even though the evidence is staring you both in the face you refuse to admit defeat. Also seeing as this is a thread designed to help others learn about OOP i think you should voice your inadequacies elsewhere.

[thorpe]

i have read the document here several years ago, and i again briefly read the overview tonight. if the email is worded in the way you describe then there documentation is contradictive.

[cyberlew15]

Thorpe To the point in your last post I must concede that ECMA Script is infact a language in it's own right. although I doubt it's sucess and still strongly disagree that it is comparable to javascript or actionscript. Also others may wish to read the pdf file because it does clear up this whole issue JScript and JavaScript were the projenitors for ECMA Script and ECMA Script was apparently some failed project that worked with W3C as far as I know the language as a standalone or addon to a web server / browser does not exist anymore. Having Said this it still means ECMA Script is as dissimilar in syntax and functionality to all of the languages previously mentioned. I think now that JavaScript and ECMA Scripts other competitors are more popular it has just fallen into a standard for web scripting languages to comply to. Really it just has some similar features to JavaScript etc but is as dissimilar as two different websites

[ATS16805]

cyberlew15 wrote:

How amazing that even though the evidence is staring you both in the face you refuse to admit defeat.

wow. i realize that all involved in this debate have strong feelings for their own viewpoints, however, i viewed this entire thread as commentary on the issue of OOP. i do not understand how commentary can be "defeated", although i realize more than commentary has now arisen because of the debate which has ensued.

i am not learning much about OOP from this debate, and at this point it has become not much fun to add aditional commentary. this is not to say that i do not greatly appreciate that you all have so extensively entertained this thread.

[Elizabeth]

cyberlew15 wrote:

Also others may wish to read the pdf file because it does clear up this whole issue JScript and JavaScript were the projenitors for ECMA Script and ECMA Script was apparently some failed project that worked with W3C as far as I know the language as a standalone or addon to a web server / browser does not exist anymore.

<-- still trying to read Cyberlew's run-on sentences.

(Relax, I'm only kidding) 🙂

[Weedpacket]

Livescript was developed by Netscape, and became Javascript in collaboration with Sun. To get it adopted as a standard they approached the W3C and suggested that that organisation might want to adopt the role. W3C said no thanks, but ECMA did accept.

Javascript 1.5 complies with the language described in ECMA-262 3rd.ed. (Mozilla also adds parts of ECMA-357 and 262 4th.ed. Actionscript2 also has a few bits that were in draft versions of 262, but haven't been adopted for the third edition. In both cases, however, these are additions, and may be considered part of the next paragraph.) Strictly speaking, only Sun is allowed to use the name Javascript™.

Both languages have a lot of additional functionality that comes from the hosting environment: this is part of the intention of ECMAscript - rather than standardise the environment that people had to work in, which would limit its potential utility. But MyConstructor.prototype.proto.value = 5; still means the same thing in all of them.

(Incidentally, regarding

cyberlew15 wrote:

Weedpacket has obviously read the original link and followed that links suggested reading

I have usage logs that tell me that the last time I looked at my local copy of ECMA-262 was in October 2003.

And while I'm in these parentheses,

absolute rubbish actionscript utilises a much more advanced control of it's DOM(the flash DOM)

Oh, so there is a difference in the interfaces provided by the environment? Gee, why didn't I mention anything about that?)

ATS16805 wrote:

am not learning much about OOP from this debate

Are there any aspects in particular you'd like more detail on? OOP on its own is a big cloudy thing and tends to fade off gradually rather than there being any sharp boundaries between "OOP/Not OOP". I guess one reason is how lately languages themselves have been getting broken down into common syntax architectures for developers to plug components of their own language into.

[laserlight]

if the company that was paid to build the standard does not offer an ecma scripting module then it is not a language.

Not really, it would still be a programming language, but a standard model for other conforming implementations. I'm just relying on your link, so if the info provided there is inaccurate, then my knowledge must be inacccurate. But then you've conceded this point, so I suppose the info in the link you provided is accurate.

at some level all languages are interpreted eh what about machine code

Machine code is interpreted by the machine, duh. The point here is that using compiled/interpreted as a criteria for distinguishing programming languages often is not very useful. It is often more useful to consider the concepts that come with the programming language, e.g. OOP.

Weedpacket has obviously read the original link and followed that links suggested reading and because weedpacket is able to take constructive criticism weedpacket will grow as a developer .

Um, the only thing I pointed out (originally) was that ECMA script, based on the info provided in your link, is a programming/scripting language (as what Weedpacket wrote).

you guys seem to be the ones starting arguments Thorpe and Laserlight

You wrote that "I resent the inference that I am simply starting arguments", and now you say this. Dont you think that I (and Thorpe) will also resent the direct statement that we are simply starting arguments?

How amazing that even though the evidence is staring you both in the face you refuse to admit defeat.

You wrote "I must concede that ECMA Script is infact a language in it's own right". Clearly your original stand was wrong - but it is not that I'm trying to win an argument (I dont have any), I'm trying to clarify a point since what you wrote and what you linked to seemed to say different things.

Also seeing as this is a thread designed to help others learn about OOP i think you should voice your inadequacies elsewhere.

Um, may I suggest that you keep ad hominem attacks away?

[ATS16805]

Weedpacket wrote:

Are there any aspects in particular you'd like more detail on?

no, not at all. you have all quite extensively satisfied my curiosity. when i said "not learning much", i was referencing the particular debate which seemed to be going on a while back.

i can't say that i've never addressed other users publicly w/ comments which would probably best be left for private debate-- for the sake of the public's reading. i suppose it boils down to pride and saving face. hey, we've probably all done it. whatever.

i guess the reason for my statement which you quoted was my own little way of saying that i would rather hear more about examples or explanations, rather than that kind of fine hair-splitting. it's all way over my head. i should just keep my mouth shut, really. i have learned a great deal from this thread. very much that i would never have known (stuff you wrote weedpacket, of the origins of javascript, etc, and many other things that other contributers wrote... printelectric, etc... and others). i'm fortunate to have been involved if even from a reader's standpoint. i wish i could contribute to the discussion, but all i can say is "wow", and "i didn't know that... could you tell me more?" but, there is valuable information here-- and considering the OOP discussion the context of this thread, one who wishes to further investigate OOP would be fortunate to read all that is here.

one last bit, and then i'll be finished-- i think what i was really trying to say is that i didn't want to see a good thread of valuable info end on a sour note. i hate to bear witness to the counter-productive effect of implicit name-calling, and back-and forth jabs at each other. it's almost embarrassing to read.

none of what i'm saying is inteded to be accusatory either. we all have our moments-- especially when strong convictions are involved.

thanks again. cheers!

[Weedpacket]

Examples! Yes!

The most visible example of OOP really flying is in graphical user interfaces. Each widget is an object, many of which are made up of several others; a Window may have a Titlebar, a MenuBar (with Menus that have MenuItems), Scrollbars (which have a track, a slider, and a couple of buttons)..... Underneath there'd be a generic "Button" object, from which more specialised buttons would be created ("Close buttons", "Scrollbar Buttons", and whatsyourfancy). So the principle is that all the code that makes any sort of button gets written once and that becomes the Button class. All the code that distinguishes a Close Button from an ordinary button would be written once and that becomes the CloseButton class. Then once you've got the classes you can use them to crank out CloseButtons galore.

Ultimately (and ideally from the paradigm's point of view), everything is an object. Not only is a Button an object, but its appearance as well - if you make it a separate entity from the button itself you can then have Themes.

Another example is the Javascript DOM. An HTML (or XML) document is an object. Its header element is an object; ditto its title element, ditto every element. This is the DOM representation of an HTML document. Javascript has an interface to manipulate this representation: do that in a browser displaying the document, and it's redrawn to reflect the changes. Every single aspect of the page can be rewritten ad lib. An entire page could be built from scratch, or totally replaced, just by messing around with its DOM representation. No doubt ActionScript gives just as much control over Flash movies.

Firefox's entire front end is written in this wise: a dialect of XML to describe the layout, CSS to describe its appearance, and Javascript to define its functionality. I shudder to think of the work that would be involved to achieve such a division of labour if you couldn't have a distinct "thing" you could work with in isolation - that you could uniquely identify at any time and to which you could attach behaviour, give an appearance to, and then position.

Of course, in the end, it's all ones and zeros. The OO paradigm could be used in literally any programming language (and a good thing too, otherwise it couldn't be translated into machine code). It's just that some languages make it easier than others: from those where using it makes for the simplest and easiest-to-understand programs, all the way to those where it's easier to use it to write a compiler to implement a more OO-friendly language.