Posted on 02/14/2012 12:38:26 PM PST by Mycroft Holmes
Also of interest are the BitNami stacks bitnami.org/stacks
Indeed. Care to relate your experiences with this piece of juicy goodness? Please do...
Object Oriented Programming is the latest fad in code-smithing, all the cool kids have been doing it for 20+ years. The previous model was procedural, you called procedures with a pointer to data and the procedure munged the data and returned a value indicating success or failure or something... Procedures, algorithms, were separate from data and you called one to operate on the other.
The Object Model rolls procedures and data into a single fur-ball called an object. Procedures get renamed methods (I guess so you know it's an object) and the data, which gets renamed properties is inside the object and is usually divided into public and private parts (methods too). The public parts are the bits you can see and use.
Looking at the money bit from the last section document.getElementById('frm1').submit(); In this fragment, document is an object. getElementById('frm1') is a method of the object document which resolves to an object which is an element of type form with the id 'frm1'. This object has a method submit() which involks the Submit Input on the element object. Clear?
DOM can be viewed as an inverted tree with the document at the top. All of the elements of the document (page of HTML) are accessible if you give them a unique id="mumble". getElementById() is the best method of referring to elements in JavaScript. There is a method getElementsByTagName() which gets you a NodeList of all the elements with name="mumble" but it's easier just to use id="mumble" and ensure that id is unique.
You can look at the methods for the element object here. The most useful is setAttribute() which can be used to force inputs to desired values and states. But if you look to the left on the screen you will see a list of HTML DOM Objects. This is where the gold lies if you want to twiddle elements from JavaScript.
The take away here is that those elements on your page that you want to manipulate with JavaScript need to have a unique id="mumble". You may then refer to that element as document.getElementById('mumble').method();. The methods that are available to the object (element) depend on the object. In the tutorial example the object was a form and one of the methods of a form is submit();.
One of the hazards of JavaScript is that it fails silently. This is probably a good idea in a client side scripting language, if a particular thing is unavailable at the moment you don't want error messages spewed all over the user's screen. But it does make it annoying to debug. One of the things that will definitely cause JavaScript to fail is any attempt to write to a NULL object. Any object that doesn't appear on the current page is NULL. This is not as nonsensical as it seems. Your program may have the notion of an object that you just aren't rendering at the moment because the time is not right. If your script tries to write to that object when it has not been instantiated the script stops silently.
DOM is just another way to look at the document. We have been thinking of the document as a collection of HTML that gets spewed by the server to the client for rendering but it really is more complicated than that, and the DOM gives us a way to talk about it.
Editorial Rant: I've heard a lot of whining from old farts about how OOP doesn't make sense, or that it's too hard. Get over it. It turns out to be a fairly useful way of thinking about things and frankly, who cares if the actual bits don't work that way. In the early '90's I wrote a Java application (not script, running on the iron) of >100K lines in less than a year which maintained a schedule in an arbitrary database, built a website to sell time in that schedule, routinely displayed images and video and even answered and took reservations over the phone. It was, of course, wildly networked. We managed to sell about a thousand systems and never had a user report a bug. It is my understanding that most of them are in use to this day. End of rant.
I was a COBOL programmer between 1983 and 2002. A friend and coworker moved from COBOL to Powerbuilder and eventually became a teacher for Sybase in the mid-1990’s.
When we had lunch one day a few years later, we talked about our old programming days. As we talked about the changes from the old days he commented that the COBOL programs that I designed were actually object oriented in the way they functioned. Personally, I think that OOP is the only way to fly, and very easy to maintain.
bookmark
I can’t for the life of me figure out what on this thread would provoke a reply that would draw attention from a moderator. Some people’s children.
You can't use MySQL on the forum for obvious reasons.
xkcd: exploits of a mom. For more, click pic.
The first step in using a database is to create one. You can't do this from PHP, you have to do this directly using phpMyAdmin. Type localhost/phpmyadmin/ into your browser's address bar and hit CR. Select the Databases tab and type 'tutorial_db' into the textbox under Create New Database. Select 'ascii_bin' under Collate (you are selecting a character set for the db here). Bug (select, hit-it) Create. You should get feedback that "Database tutorial_db has been created" and you should see it appear in your list of databases.
Copy the following code into a file named ~www/tutorial/include/connect.php
<?php
$db = "tutorial_db";
$link = mysql_connect('localhost', 'admin', 'password');
if (!$link) {
die('Could not connect: ' . mysql_error());
}
echo 'Connected successfully<br>';
mysql_select_db($db) or die(mysql_error());
?>
This fragment is not a function but an in-line bit of code that appears wherever we type include 'include/connect.php'; It just drops right in, like text from the gods. What it does is connects us to our database, using the name and password provided earlier, and informs us that we have successfully connected. The "or die" construct is interesting. If we fail to successfully connect the PHP script quits, Dead Right There. There is a very helpful error log though, you should find it soon. Part of the beauty of PHP is that this fragment (with our login name and password) never appears in the raw HTML emitted by the server. We then select, as opposed to connect to our database to proceed further. Copy the following code into the body of ~www/tutorial/index.php to make sure we are all on the same page.
<body>
<form id="frm1" method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>">
<?php
$debug = true;
if($debug) {$ta = array_keys($_POST);for($ti=0;$ti<count($ta);$ti++) {echo $ta[$ti]."=".$_POST[$ta[$ti]]."<br>";}}
$FoodCount = $_POST["food_count"]; // Memory, Dr Memory
$FoodUnits = $_POST["food_units"];
$DrinkCount = $_POST["drink_count"];
$DrinkUnits = $_POST["drink_units"];
$FavoriteFlavor = $_POST["favorite_flavor"];
include "include/tutorial_functions.php"; // a collection of functions for various stuff
echo "Hello World...<br />";
echo "Fave Flav:<input type='text' value='".$FavoriteFlavor."' name='favorite_flavor' /> ";
select_command($_POST, $base_name="command"); // pick a command
echo "<br />Food: ";
select_quantity($prefix='food_', $FoodCount, $FoodUnits); // pick a quantity of food
echo "<br />Drink: ";
select_quantity($prefix='drink_', $DrinkCount, $DrinkUnits); // pick a quantity of drink
echo "<br />";
include 'include/connect.php'; // connects us to tutorial_db
?>
<form>
</body>
The new thing here is the include/connect.php at the bottom. If you do the usual save/submit cycle you should see "Connected successfully" from the include file telling you all is good. We will soon eliminate the line generating that happy feedback as it will be in our way, but for now it lets us know everything is working as it should. Now we need to add a Table. In this case, a table is not furniture but a template for a collection of data. The data we are collecting for this little program is about stuff we buy at the store. The first table we need is one that represents items. I've copied below the existing table I am using.
1 name varchar(64) latin1_swedish_ci 2 upc bigint(16) No None 3 menus varchar(64) latin1_swedish_ci 4 price varchar(16) latin1_swedish_ci 5 amount varchar(32) latin1_swedish_ci 6 calories_unit varchar(32) latin1_swedish_ci 7 suppliers varchar(64) latin1_swedish_ci 8 handling int(11) No None 9 url varchar(64) latin1_swedish_ci 10 level double No None 11 reorder float No None
Tables are where data is stored in a database. It's convenient to think of tables as rows of individual items and columns of data fields. One of the columns is designated the primary key and the values in that column must be unique, each row's value must be different. Think of the primary key as the one true name of the record or individual entry (row) in the table.
The list above comprise the columns of the table. In general it is better to overdo than to fall short on field sizes. Don't be ridiculous, we don't need 4096K to store a product name, but it is easy to make fields go away or be smaller. Before you have accumulated significant data it is easy to adjust fields in general. Going big and cutting back when you have some experience seems to be a path that has worked for me.
Another database trick you want to be very aware of: If you are storing the same data in two different places you are doing it wrong. Consider the table above, there is a field named 'suppliers' and its a varchar(64). You might naively think we are going to put the supplier's name and address in that field, but that would be wrong. Many (most, really) of the items come from the same supplier. Imagine row after row containing the data 'Wallmart in Milton, FL 32570' over and over again, row after row. Pretty dreary all this duplication of text.
So what we do is create another table called 'suppliers' with a numeric primary key and a bunch of fields that have the supplier name, address, phone, contact, url, last conversation and anything else we can think of because we are only going to store this bit once and use that primary key in the suppliers field of the item table data.
So why is suppliers a text field? Because we may have multiple suppliers for the same item. We can store them by saving their primary keys as Comma Separated Values (CSV) in the suppliers field. There are downsides to this we will discuss later.
The next thing to do is write some code that will check to see if the tables we are interested in are present, and if not, to create them. Being lazy, for this application I just used phpMyAdmin to define the tables, but if you want to deploy an application to some folks and have them collect their own data you might want your program to set up the tables. So, I'll go away now and work that out and be back with some code that creates tables.
I hope some of you are being entertained. I know I am...
Are you talking about the pulled post #25?
Another former COBOL programmer here. I have considered writing a similar tutorial, geared towards folks like me - ‘old ‘mainframers that are now working in another skillset. Today I do java/js/j2ee/weblogic/xml/oracle/hibernate/etc development, and really enjoy it.
I used to look at OOP as magic, then got into it a bit more. Makes sense now, but sometimes I am still annoyed by ‘kids these days’. The whole ‘shopping cart’ model - seems no one knows how to do volume processing anymore. Even though a lot of my work is ‘front-end’, I still prefer the challenge of dealing with large ‘batches’ of work (and still needed where I work). Sad to say they ignore this work in favor of their on-line fetish...
I started my tutorial this weekend using Win 7, but in a Virtual Box running Ubuntu. Somehow lost my ‘vdi’ file or some such, so now I get to start again.
Yes
That was me. I double posted the tech ping so I requested the mod remove the duplicate post.<p
Nothing to be alarmed about.
I'm writing for a really bright 17 year old. I've got a nephew I hope to interest with this when I'm done.
I read a book in 1996 that was called, I believe, OOP for managers. It was great. With tons of analogies and pictures it discussed objects, classes, stored procedures and all that stuff.
I haven’t done any programming since I left COBOL. I”m now a PM/BSA. That said, I did rewrite a very poorly written five pages of SQL Server code someone handed me into a structured two pages.
It’s amazing how similar the functionality of computer languages is to figure out even with training, once you’ve learned one of them.
I wasn’t going down the ‘lamp’ path for a tutorial, but something more like a ‘standard’ dev environment: linux, java, maven, junits, mysql, junits, etc - keep adding components like version-control, injection control, logging, code analyzers, web servers (which you cover)...you get the idea.
I have a good idea how to get these all going, but I would love to have it all written down and easily repeatable. I have a growing list of components to add...somewhere...
Sweet. Even better.
You listed junits twice?
I like junits...
I've had a lot of fun with that kind of thing in the past, and actually set up a 3-tiered architecture in VMs under VMWare to play with different scenarios. Granted, that kind of thing is probably over the average Joe's head, and memory resources (I have 18GB on my workstation, and rarely have memory issues), but for those who want to go further, it can give folks an idea of the complexity of real-world systems.
If I have some time this weekend, I might build a small VM for exactly this purpose. Wonder if I could get it runing under DSL. Hmmmmm...
But I never got what VM would do for me. I'm a fair power user but I don't need to be switching environments or hiding information from myself or others. What advantages would I get from using a VM, other than increased hassle?
I see people doing it, so there must be something I'm missing. I've already got multiple machines with multiple OSs, why do I need to virtualize any of them?
Hoping for light, not heat. Regards.
Hoping for light, not heat. Regards.
No heat from me about this. ;-)
I see VMs as a tool that can be used in a lot of different ways. Let me set forth a few scenerios, that might shed some light for you.
One last thing. I've really been suprised that more corporate-type software isn't sold as complete working VMs. Could you imagine what it would mean from a troubleshtooting perspective, if you could tell your customer "take a snapshot and sent it to us." You'd have absolute and complete control over the hardware, software, and many other aspects of the environment. I would think from a supportability standpoint it would be an absolute godsend. If you set things up properly, such that customer data resided on a separate disk, mounted to the VM at boot time, the customer would be protected against sending you confidential information as well.
I'm sure there are a lot of other use-cases, as varied as you could probably imagine. I can understand someone not really seeing the utility of virtualization. It depends a lot on how you use your computer. There may well not be any benefit fo you. Then again, there might just be a use that you've just not thought of yet.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.