Oh dear, I can't do .... OOP design

[rowan]

This is more a methodology kind of question than anything but my examples are all related to PHP/HTML.

I've tried to get into OOP a few times unsuccessfully. I've bought a few books that have a chapter or two devoted to the subject and read / practised them at least twice.

Most recently [and with most effort so far] I've been using the book "Professional PHP 4." For the first time I've got past the stage of just hating the whole subject and I feel I'm getting somewhere and some things are making sense. However I still seem to be tying myself
in a number of knots trying to get my design working cleanly. Currently I'm stuck trying to implement a few simple classes to deal with HTML, tables and forms.
To elaborate a little, validation is the area that the problem has manifested itself although the problem will be in the design:

First I've created "webpage" and "form" classes. Then I've created classes for all the different form elements [text field, password field, submit button etc. etc.] Originally I had validation handled in a separate validator class as recommended by the book [because you will probably want to validate other things than form elements as time goes by..]
I got stuck trying to implement that because I needed more than just regular expression validation [which was all that was designed to do in the book] and I couldn't see how to expand the design cleanly.
So I decided to move validation to all the various form elements hoping it would become clear given time and not be too much trouble to make a validation class at that time. This then worked how I wanted it
to. Next I made a "table" class which worked by adding a load of objects representing cell data. Now this all works fine when displaying
the table but the validation screws up; the containment looks something like this:

webpage
..|----form
.........|----table
................|----textfield1
................|----textfield2

display [generating HTML] works fine, because the display method of "webpage" adds the <html> tags etc. then delegates displaying to all objects it contains. In this case, "form" adds <form> tags etc. and then delegates displaying to all objects it contains. "Table" then adds <table> tags etc. and delegates displaying to all objects it contains.

validation fails because there is no validation method in "table", so when I ask the form to be validated and it trips up trying to call a non existant method in "table". In my mind, "table" is purely a formatting kind of class; when I had "form elements" in a "form" in a "table" it worked fine because "form" delegated validation to all objects it contained and all the objects had a validation method.

I can work around this easily by adding a validation method to the table class which will delegate to all objects contained but I'm sure that this "pass-through" method is not the right thing to do. It would only be there to work for form elements that happen to have been formatted
in a table and that goes against the grain of making classes loosely coupled - the table class would also be used to format tables of data from a database for example where validation means nothing. In fact validation means nothing to an HTML table structure so I'm certain this method shouldn't be anywhere near the "table" class but whatever I try to do I run into the same problem elsewhere..

Anyone have any ideas? Any books/articles they could recommend that might be nice and easy for someone that finds this stuff hardgoing and counter intuitive? I've only ever done procedural things before and I've only just reached the point where some things seem to make sense.

edit: TIA!

[histor]

I usually find that OOP is overkill for most PHP stuff, unless you're writing a really big web based application. If you want to get into OOP it might be worth trying Java or C++ where the OO approach seems to make more sense (to me anyway). I started learning C++ before I tried PHP, so I understood quite a bit about OOP but found it wasn't really useful for what I wanted to do with PHP and that going back to functional programming was quicker and easier.

But anyway, here's some useful links for PHP tutorials and other stuff if you don't already know about them:

http://phpresourceindex.com

http://www.phpfreaks.com

[~D4T45H4T~]

So essentially what you're saying is that HTML is a big pile of SHIT?

I heartily agree.

Sorry this post isn't really any help, but I've been battling with HTML today, and I always find it INFURIATING.

Inconsistency across browsers and all that crap is truly laughable, more so the solutions to making more advanced content within HTML - just hammer in new rules and features until you're left with a soggy, dead, lifeless frankenstein's monster of an 'information display language'.

It really is shite, but there's just SO MUCH of it out there, there's no chance for a revolutionary new webpage format, is there?

Sorry about that, as for your question - I've never touched OOP. So I don't know! Where would you be without me eh?

[noodles]

You don't need OOP to do a good web site.

[teamonkey]

I usually find that OOP is overkill for most PHP stuff, unless you're writing a really big web based application.

Yes! OOP and HTML do not mix. ASP.Net just about gets away with it because it makes substantial changes to HTML that it turns into real HTML at compile time.

Most of the validation stuff you can do in a few lines - why make it more complex than you need?

If you really, really, really must use OO for web sites, http://pear.php.net/ and http://smarty.php.net/ are essential. Oh, and if you consider a web site to be an OO application where each class is represented by a PHP script, things become easier.

[Surfr]

So essentially what you're saying is that HTML is a big pile of SHIT?

I'm afraid I find this statement completely preposterous.

HTML is a standard. If your issue is with the adoption of the standard by browser manufacturers, take it up with them.

[~D4T45H4T~]

Grumble Grumble



Sorry folks, bad day.

The programming forum is not the place for such ill-informed banter.

I'm not massively experienced in HTML, so I probably don't know what I'm talking about. I just get irritated by the layout behaviour of HTML sometimes from a design point of view.
Something will work perfectly in Mozilla and look completely fuct in IE and vice versa.

Plus my job at the moment requires me to make a certain 'off the shelf' shopping cart system look 'trendy' which involves editing lots of inconsistently (and sometimes bugged) XML templates.

I'll get me coat.

[rowan]

Thanks for the answers..
To put this into context a little; I am hooking up our internal database to a web server to make a live information system. This browser access [as opposed to various client applications] neatly solves the problem of deploying this solution to handheld devices without looking at anything to do with coding things specifically for PocketPC.

I've written a prototype that is a truly awful example of monolithic programming that is already almost impossible to expand without a complete rewrite. However it works and since users don't see behind the scenes they are none the wiser - in short they received the demonstration fairly well. Next they will want [quite a lot] of new functionality - at the moment it is purely a "read only" hyperlinked information system with about 8 different queries. Sooner or later they will want to write data back which will require user login and access rights.

So it needs a rewrite anyway and I keep reading / hearing of the advantages of OOP in that it makes things easier to "lego" together because of the extremely modular design that it encourages, saves you time in the long run through reusable code, makes things easier to debug etc. etc. Whether this is true or hype or just not applicable I can only really decide by trying it out myself and because of the reasons stated above, now seems as good a time as any. I don't know too much about how exactly I will need to expand this system [does anyone support users who know what they want? [realistically - most want the moon on a stick]] so something that isn't too constrained by its implementation is much better than a "patched kludged workaround" set of routines.

[Kemper_Boyd]

I did start writing a reply, but it got a bit waffley.

How about posing some questions and seeing if
we can answer them for you?

[t0ne]

Disclaimer: I know jack about PHP, but I'm a professional coder and do more than my fair share of web development.

What you are really looking to do is identify pieces of reusable code from your monolith, and refactor them out into something that can be reused multiple times from multiple places. Usually you'd want to seperate the UI from the business logic, but this is not always possible with web based projects.

I assume PHP allows you to include or import files, so basically you could create php files that contain nothing but your refactored "useful" routines, hopefully categorised together so that similar routines live in the same file eg. authentication code in one file, database code in another etc.

The difficult part is the identification and refactoring of these procedures. Most of it will come with experience, but your goal should be to identify genuinely useful reusable routines that can be parameterised and to keep interdependencies to a minimum ie. you don't need to have everything included just to reuse one function. Also if you can keep your business logic code seperate from your UI code (even if it's just by using copious amounts of CSS) you'll have to change less next time the site needs a facelift. Most common for me these days is using web services (Java or .NET) to generate XML which I transform with XSLT into HTML, keeping logic and UI totally seperate.

Sorry it's a bit of a off the top of my head ramble, but I hope that makes sense

[sty]

I know the original post is a little while ago now, but I've been busy and unable to read the programming forum for a while.

A quick view (from my perspective) on the original query about validation:

I don't see anything wrong in adding a validate() method to the root class (webpageroot or whatever you've defined it as) that all your web page objects (table, form elements etc.) are based on, and define the validate() method of this root class object to return validation OK.

This way you inherit from the base class in your individual page objects and only need to redefine the validate() method in objects that need validating. You're making use of Inheritance and Polymorphism now.

(Just out of interest, looking at your inheritance/heirachy diagram, I'm not sure how you have set things up, but I would define my "Page" as a container into which I put "PageElement" objects that are all derived from my PageElementRoot root object - then to validat a page you simply walk the Page container and get everything to validate themselves, and to render the page you walk the Page object and ask everything to render itself)


Is this right or wrong? well it's debatable for every specific case, like a lot of non-trivial OO design. I've found over the years that the more practice you get the better you will become, so implement something and see how it works for you, in the future you may structure your whole problem differently. It's is just like non-OO coding at first we tend to write nasty monolithic code, and eventually we get more elegant at it.

[skab]

I usually find that OOP is overkill for most PHP stuff, unless you're writing a really big web based application. If you want to get into OOP it might be worth trying Java or C++ where the OO approach seems to make more sense (to me anyway). I started learning C++ before I tried PHP, so I understood quite a bit about OOP but found it wasn't really useful for what I wanted to do with PHP and that going back to functional programming was quicker and easier.

Ah, thank you. I thought everybody was using objects in PHP nowadays, and if it's just for writing a "hello world"-class. Stupid. I see the advantages of OOP, but every time I try to actually use it I stop and think, this is stupid, the classic modular, procedural style is simpler, better to read, and faster. So WTF? If I want bloatware, I use Word...

[rowan]

Thanks for the answers.

Skab - This is how I feel nearly every day as I try to bash things out but I don't think I've been doing it long enough to get through "the pain barrier". As sty says; try to get something going and with practice one should become better at implementing.

sty - interesting idea with sticking a validate in a root class; it seems so simple when you point it out but instead I've been trying all kinds of other convoluted things. A couple of times I've thought about a potential base class for everything but in a way I've been waiting for some kind of "gentle nod" from someone a bit more familiar/comfortable with these techniques.

To be honest when I ran into a couple of problems today I think I hit what is the real issue to me underneath it: PHP probably isn't the right tool for what I'm doing, in that it's server side whereas I'm increasingly wanting client side processes. That said, validation is the main one and I have a kind of framework [hah overstatement!] that will work well enough to use.

Regarding my diagram; that was what I called "the containment" - I meant that a webpage contained a form which contained a table which contained 2 textfields. I was walking the page container getting everything to validate itself. There was no validation method in the table it fell down. Your point about having a base class with a default validate method which everything else is subclassed from solves that. At the moment I only have one inheritance structure:

FormElement
|--TextField
|--TextArea
|--PasswordField
etc.

The book I've been using seems to be good and in the short space it had [only 1 chapter on OOP] it strongly impressed on using polymorphism and delegation; writing generically and trying to avoid long lines of inheritance. The more I work with this, the better it feels when I think about it but it's all going pear shaped when I try to implement That said part of the problems are from me thinking in a "client side centric" way.

Yeah, thanks for the encouragement, I'm feeling happier about it [but I'm not at work now......]

[skab]

Skab - This is how I feel nearly every day as I try to bash things out but I don't think I've been doing it long enough to get through "the pain barrier". As sty says; try to get something going and with practice one should become better at implementing.

Ahem... I'm doing this stuff for a living. For many years now. I just don't like the OOP hype. I'd rather have a well done, clean procedural routine than a huge pile of objects by some crappy but hip OOP programmer.

I was delighted to read that programming icon Donald Knuth isn't into OOP as well. Showed me that I'm not stupid or anything

[chilliChill]

I've been using HTML and ASP for a while now to talk to backend databases , and it is very infuriating(the HTML, the ASP is OK).

But one day, I read about flash, and flash was good, but then when you link flash to your asp scripts, and then your asp scripts to a backend data source, woaah! you have some good stuff going on.

I basically have objects stored on the server which have the job of communicating with the database, so, if in ASP script, I want to load a customer object I do this:

set ocustomer = createobject("wholesale.customer_Cls")
I can then load all the details for a particular customer:
ocustomer.pop("CUST0001")

and then can get either XML, or a recordset like this:

set ocustomerSet = ocustomer.askrecordset()

I can then alter fields in the recordset, and then save back to the database by doing:

ocustomer.update(ocustomerSet)
ocustomer.save()

The customer automatically handles all the fetching and saving itself.

In HTML code, I can then assign these values to fields like:

<INPUT value=<%response.write(ocustomerSet.fields("cu_name").value)%>>

But I find laying out and controlling HTML really frustrating, when you are used to a desktop database system where you have control over everything.

This is why I find flash great, yes, it's proprietry, but a lot of people have it . Flash allow you to contol your interface exactly how you want, layout sounds etc.

So , in Flash , you can call asp code, along the lines of :

oupdate = new loadvars <--- creates a new variables object
You can assign properties, eg:

oupdate.customerid_txt = "CUST001"

call an asp script as follows:

oupdate.sendandreceive("getcust.asp",oupdate,"POST")

This has effect of calling an ASP script, you can get the customer id in the script by doing

lccustomerid = request.form("customerid_txt"), then do your customer population:
...
ocustomer.pop(lccustomerid)
and to send back to flash:

response.write("customername_Txt="+ocustomerset.fields("cu_name").value+"&telno_txt="+ocustomerset.fields("cu_Telno").value)

the variables you passback in your string would then be available to your flash object like:

txtcustname.text = oupdate.customername_txt
txtcustTelno_.text = toupdate.telno_Txt

Sorry, just wanted to share this with someone, cos I am well chuffed with it. I can write news systems, etc in flash, will all the fancy effects!