[Resolved] Classes and forms

mijokijo

I'm starting out slow with the new features in PHP5, so I'm making a shoutbox. What I'm wondering is how do I use a class with a form? That is, when would I make a new object? Does anybody know of a good "map" of sorts that can show me the big picture of how things should look?

elesueur

are you talking about a generally reusable HTML form class?
You can implement a class to help you build html forms in many ways. There is no set way, otherwise it would be included in the php framework.
Good OO design could lead you to create a set of objects which you can reuse over and over again in different projects.
If you are interested in OO design, I highly recommend that you learn Java - in my opinion, it is one of the most well designed OO languages, and you can learn a huge amount from using it.

PHP 5 doesnt really include any new features, it merely provides a better way to implement OO design patterns - but it is still fairly lacking by comparison to java for OO.

mijokijo

Ok, let's imagine for a moment all the files.

Let's have index.php be where the actual shoutbox is. There is field with the current posts in it, and a field to add a new post. The dilemma I see is, I can't directly point at a class, I need to make a new object. Would I do that in the HTML source for the form? How does one log into the SQL server so one can actually make the post? What about anonymous posting?

thorpe

i think you might want to re-read whatever you've read on php classes. i think you might be mistaking them for client-side javascript objects.

sorry, im just not quite sure where your question is going.

elesueur

this doesnt sound like an application that object orientated programming would be suitable for.

I suggest you look at a tutorial on database connectivity and basic php database applications.

HTML forms are a very simple way to transfer data from the browser to PHP, nothing more.

Its up to you how you deal with that data within your php script.

mijokijo

Alright, I guess I haven't been clear then.

Let's say I have a couple of classes, shoutbox.php and dbconnect.php. dbconnect.php has the code for simply connecting to a database. shoutbox.php has the code for the shoutbox, things like SQL insert statements and whatnot. I also have an index.php with the shoutbox in it. The shoutbox has one field with the currect shouts and a field to insert a new shout, and a submit button.

<form action="this is the big one, what do I put in here?">
<input name="shoutpost" />
<input type="submit" name="submit" />
</form>

You see my problem now? Would I start the index.php like this...

<?php $connect = new dbconnect(); ?>
<html>
<head>
...

Shrike

Start off by understanding what it is you want to represent with your classes. Break things down into simple chunks, you might consider

A 'shout' object
A list of 'shout' objects
Some iterative code to display the 'shouts' - PHP 5 - think Iterator
A database abstraction object
An HTML form object (maybe - is this really needed?)
A data parsing routine (any need for this to be an object?)

As was mentioned above, an important question is whether you really need to bother with objects at all. As it stands, the code would probably be best written procedurally. If you can forsee reuse for the code then perhaps an object based solution would work for you.

mijokijo

The point is not to have a nice shoutbox written using OOP for the fun of it, but rather to learn how to wield the OO power of PHP5 well.

- A 'shout' object //I think this would suffice for now
- A list of 'shout' objects
- Some iterative code to display the 'shouts' - PHP 5 - think Iterator //I'll look that up
- A database abstraction object // Definitely interested in that. I'm still trying to conceptualize how I would make a dbconnect class abstract enough that you could use the same class for multiple databases without changing anything.
- An HTML form object (maybe - is this really needed?) // Eh, maybe
- A data parsing routine (any need for this to be an object?) // Maybe you could explain this a bit more.

The point of this exercise, as I stated earlier, is to learn how to program in using the object-oriented style. A shoutbox just seemed like a simple task to set for myself to learn how to program using object-orientation.

My hope is that I'll be able to make a CMS for myself, and maybe at a later date I'll release it to the general public. There are tons of CMS's already out there, but I hope to differenciate my CMS from the others. Drupal seems like the one to beat though.

What I'd like is to have an index.php file, a base "page" from which all other pages extend. That way I can set some site specific preferences and privileges, apply them to index.php, then have those settings applied to all extending pages. It should also have user specific and page specific settings, which I should theoretically be able to set by overridding the default values.

thorpe

i think i see where your getting at now, and in this sense, its no different to procedural coding.

example;

echo '<form action="'.$_SERVER['PHP_SELF'].'">';
echo '<input name="shoutpost" value="set" />';
echo '<input type="submit" name="submit" />';
echo '</form>';

if (isset($_POST['shoutbox'])) {

  $shout = new shoutbox();
  $shout->query();

}

this is not the point of OOP, but i believe it answers your question.

mijokijo

if (isset($_POST['shoutbox'])) { assumes that I already included shoutbox.php, correct?

thorpe

no, that is checking that the form has been submitted. you could just include the shoutbox class inside the if, if you wanted to.

like so;

echo '<form action="'.$_SERVER['PHP_SELF'].'">'; 
echo '<input name="shoutpost" value="set" />'; 
echo '<input type="submit" name="submit" />'; 
echo '</form>'; 

if (isset($_POST['shoutbox'])) { 

  include('shoutbox.class.php');
  $shout = new shoutbox(); 
  $shout->query(); // demo method call

}

Shrike

Originally posted by mijokijo
What I'd like is to have an index.php file, a base "page" from which all other pages extend. That way I can set some site specific preferences and privileges, apply them to index.php, then have those settings applied to all extending pages. It should also have user specific and page specific settings, which I should theoretically be able to set by overridding the default values.

I think you are missing the point of object oriented programming as opposed to procedural (forgivable, it's the hardest thing to get to grips with). An object should represent some small element of an application. With a procedural approach you might write things on a page by page basis. The goal of the object oriented approach is to create reusable and extensible elements, some, all or none of which might go toward creating a page.

mijokijo

Ok, thanks thorpe.

Shrike, let me tell you what I understand, and then you can correct me where I am wrong.

This is how I imagine the set-up would be. There would be index.php, and different elements on that page would have different privileges. So for instance, if it was a news page, there would be some news items that only Admins could see. There could also be a todo list for Admins on the left or right of the page that only Admins could see. They would get those permissions from what I like to call a "zone", a class that describes the privileges one must have to access a zone. A zone can be a whole page or pieces of a page (like the todo list).

index.php might have much more lenient rules for user access by default. These rules would be inherited by any other pages extending index.php. Not to say that I would build each page on a page-by-page basis. For instance, a forum could be default have lenient access rules for new forums (due to inheritence), and then you could restrict access by applying the Admins-only access privileges to it.

// The class structure would look something like this.

class forum // Defaults

class adminforum extends forum // Now applying certain adminforum specific settings


// Then in some database I would simply UPDATE a forum_type column for that new Admins-only forum

The logic behind it goes back to the zones stuff. You may have default access to walk down the hall and enter some conference room, but then there could be some labs down that same hall that you need extra privileges to be able to access.

Am I confused as to how OO should work?

elesueur

you seem to be using the terms Class and OOP in the wrong contexts here.

If you really want to learn about Object oriented programming and where and how it should be used, take a look at this power point presentation.

http://www.cs.auckland.ac.nz/compsci230s1c/resources/OOP.ppt

it gives a short outline on the different aspects of OOP.

In reality, your shoutbox implementation doesnt need to be oop. the database connection system could be based on OOP, but in reality, just using simple mysql commands would suffice for such a small project.

The php manual has examples on how to use the mysql functions.

The use of OOP to define security in high level program output is not what it was intended for.
If you intend to have different security levels, you are going to need to have some sort of session management tool, as well as a simple user login system.

mijokijo

As I said before, the point is not to use the best tool for the job in this instance. The point is to learn OOP as best I can using PHP5, and a shoutbox seemed like a simple way of doing so. The end goal is actually to make something bigger than just a shoutbox.

About the session management tool, that would be a class or group of classes in and of itself? You're saying that I should make a group of classes that are meant to control privileges, rather than build them into other classes like fourm and adminforum?

elesueur

ok, heres a suggestion:

class ShoutBox {

private $messages;

public function __construct() {

	$this->messages = Array();

}

public function addMessage($message) {

	$this->messages[] = $message;

}

public function getMessages() {

	return $this->messages;

}

}

$sb = new ShoutBox();

$sb->addMessage("message one");
$sb->addMessage("message two");
$sb->addMessage("message three");

$messages = $sb->getMessages();
for($i = 0; $i < count($messages); $i++)
	echo $messages[$i].'<br />';

your ShoutBox::addMessage() method could stick the message in a database.
your ShoutBox::getMessages() method could retrieve all messages from the database and return it as an array.

That's just a really simple way of using a class to represent a shoutbox.

A forum is a much bigger project. The session handling system itself could take you hours and hours to develop.

Just for your information, OO was a part of php4, and php5 built on it.
You could have done this in php4 easily.

mijokijo

Tomorrow I'll give a more thorough reply. I'd just like to say thanks so far for the help. Although giving me the code wasn't really necessary, but it is helpful.

Before, Shrike alluded to Iteration. I would use that by iterating through a database, correct? So I would modify the getmessage() method to iterate through...what? Would I load an array with the contents of a database table and then iterate through the array?

Shrike

I still think you might be seing things in terms of pages, that is, a forum class which contains a header, body and footer. The presentation layer of an application should be completely separate to the business logic. Doing so makes the code more portable and reusable, and also allows both layers to change without causing problems. Going back to your shoutbox example, I would define the following

class Shout{}
class ShoutList{}
class Database{}
class ShoutAdd{}

The Shout class defines the basic properties of an 'shout', so that would be the text itself, the author, the date it was created etc.

The ShoutList class is a container for instances of Shout. You might implement Iterator here to standardise accessing the list.

Database would be a database abstraction. You might define methods like query(), fetch(), getNumRows() etc.

ShoutAdd would contain various methods for dealing with user input and storing to a database.

All of the above classes are considered to contain business logic. They don't have any knowledge of the presentation layer. The presentation layer might just be some procedural PHP intermingled in HTML, which lays up each Shout (using the ShoutList object to gain access) and presenting the user with a form for adding more.

mijokijo

I see, I think I'm with you now, Shrike.

So you're saying that each shout should be an instance of the Shout() class, correct? Would you say that each instance of Shout() could be comparable to a row in a database? So then I imagine that I would create new instances of Shout() per row in a shoutbox table, then iterate each instance using Shoutlist().

I understand completely the separation of logic and presentation, it's the same idea behind the use of CSS for describing how text should look on a page, rather than a bunch of <FONT> tags with a bunch of different properties in each tag.

Shrike

Yes an instance of Shout would equate to a database row, or more accurately, a row of a result set from a query. It might seem a little like wasted effort to create an object from a result set, when you could just use the result set directly. But there are benefits when the time comes to subclass Shout.

It is also beneficial to implement the Iterator interface, or use one of the SPL Iterator classes in ShoutList. That way you can design the renderer in the presentation layer such that it doesn't care what it is rendering as long as the methods defined in Iterator are present.

If your feeling brave then a visit to www.phppatterns.com might be beneficial. The examples are written with PHP 4 but it's fairly obvious to see where PHp 5's features can enhance the various bits of code. There's a good explanation there of why Iterators are useful.