PHP OOP, Ajax and MySQL

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
obiron
Forum Newbie
Posts: 15
Joined: Fri Nov 10, 2006 4:50 am

PHP OOP, Ajax and MySQL

Post by obiron »

I'm trying to get my head around OOP and Ajax at the same time (there's nothing like making life hard for yourself)

Lets take a simple example: - A sales order

The order can be considered an object with properties (order number, customer number etc...) and methods (getOrderID, setOrderID etc..)

An order will also have lines and each line will have certain characteristics (product number, price, qty etc...)

The lines can be regarded as an array of the Order object but could also be considered as objects themselves. Which way should this be done, or can it be done as both at the same time.


If I am building a rich internet application using Ajax and MySQL where the operator can dynamically add and remove lines and changes need to e sent bback to the server for validation against business rules using PHP processes, where do I store my objects (javascript client side or php server side).

Each url request for validation needs to know the whole of the order (headers and lines) and modify the line values (e.g. multi-buy discount). How do you send that information becuase I can't pass it as an object.

When I have finished with my object how do I save it out to the database, or should i be saving changes in properties as I go along.

What happens if the browser crashes or the user hits refresh. I have plans for recovering the point in the application but can't work out a way to recover the object to the browser session.

I am hopefully looking for a cookie and preferably a session free solution.

Thanks in advance

Aaron
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Ahhhh ... a question about POOPJAX! (just kidding ;))

Seriously, Ajax is just another way to submit HTTP requests to the server. It is the way to do it without requiring a user action which makes it very handy, but it is still just a plain old HTTP request. It seems like your real question is about passing structured data and providing error checking for that data. On the data front there are a number of options from regular delimited data to XML to JSON. There are a number of PHP libraries that do the "objects on both ends" thing so you may want to look at those an either use one or use the ideas for your implementation.

Error checking requires both transport errors and data errors be checked. That is a pretty large subject, so perhaps if you had specific questions we could provide some ideas for you.

Finally, I believe current practice is to implement an Action based controller architecture so that you can package together the methods that respond to the various requests of a page and have a straightforward interface to invoke them.
(#10850)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

I haven't paid too close attention to this topic, but isn't AJAX the classic case of another controller+view set of classes? A different controller because the AJAX call has its special protocol for querying, and a different view because you return different types of data then HTML pages.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: PHP OOP, Ajax and MySQL

Post by Ollie Saunders »

obiron wrote:I'm trying to get my head around OOP and Ajax at the same time (there's nothing like making life hard for yourself)
Ahh yeah, I wouldn't do that unless you know you can cope with it. I once tried to learn OOP in C++, OpenGL and the Windows API all at once for a very important college assignment. Amazingly, I did make progress but it was very slow and painful. I handed in about 5% of what I wanted to achieve. Still got a good mark because I 'demonstrated' a load of stuff; Isn't modern education marvellous! :)
The lines can be regarded as an array of the Order object but could also be considered as objects themselves. Which way should this be done, or can it be done as both at the same time.
Store an array of lines in the order object.
If I am building a rich internet application using Ajax and MySQL where the operator can dynamically add and remove lines and changes need to e sent bback to the server for validation against business rules using PHP processes, where do I store my objects (javascript client side or php server side).
I think you are trying to get at is how to manage race conditions. This isn't an AJAX specific problem by any means.
Problem: If one user is in the process of adding lines to an order and another user completely removes one of those lines from sale what happens to the order?
Answer: Perhaps you need to have a limit on deletion of lines so that a line is frozen when it needs to be deleted and then can no longer be used in any new orders but still work with existing ones. Then periodically check whether frozen lines still exist in active orders if its not it can finally be deleted; this is a lot like garbage collection really. All of these actions will take place on a database level and although there can be objects representing lines and orders these and just representations of what is in the database.
When I have finished with my object how do I save it out to the database, or should i be saving changes in properties as I go along.
Save changes as you go along.
What happens if the browser crashes or the user hits refresh. I have plans for recovering the point in the application but can't work out a way to recover the object to the browser session.
Work in the database not in objects. If something is incomplete maybe have a field indicating so.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Ambush Commander wrote:I haven't paid too close attention to this topic, but isn't AJAX the classic case of another controller+view set of classes? A different controller because the AJAX call has its special protocol for querying, and a different view because you return different types of data then HTML pages.
There are a number of different mixes. It can be an additional client side Controller and View, but many times to me it feels like split Models, Views and Controllers -- so MMVVCC (which makes me as dizzy looking at it as it does to debug it ;)). I think it depends on how you look at it. I guess you could even think of it as MVC+MVC where the response of the Ajax MVC is the request of the PHP MVC.

But in practice the Models and Controllers are usually linked (maybe mirrored might be a better term). The Views can be linked or the View can be pure client side. So that would be MM-VV-CC or MM-V-CC.

I am not sure if that makes any sense to anyone but me...
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

I'm in planning for an AJAX app, so I can share my own thoughts.

AJAX requires the exact same setup server side you would typically have for any PHP application (MVC or otherwise). If you take an example of managing a MySQL database by adding rows. Using AJAX mainly just replaces the page reload from a form submission with a less intrusive behind the scenes submit and refresh of the current data.

In this case the controller logic is the same - the only change is to the View. Rather than serving HTML, you are now serving a data format (typically JSON, or XML if you really like DOM). The business of formatting and templating is shifted to the client side where Javascript DOM creates new, or removes old, table entries from the user's client view. If you like, the View in MVC is now split across the server and the client. The server's View is now all about encoding data for a response, and a package of presentation logic is now pushed out to whatever Javascript code handles that data to update the current page.

The challenge here is doing the Javascript. Depending on the app's complexity and reliance on AJAX, you can easily wind up falling back on procedural coding (creating tons of Javascript functions without much refactoring), rather than putting in effort to make a more OOP style Javascript library. Currently I'm using Prototype to create classes, and trying to find a Javascript library capable of taking an HTML template and converting into Javascript DOM instructions. There's one called Miro, I think, that requires using ant - http://ajaxian.com/archives/miro-light- ... ing-engine .

Arborint makes a very good point above - if you end up with Split Controllers/Models/Views than you're doubling up on complexity. You can escape much of that by segregating Actions into methods, and having a forwarding method to move from Action to Action (or skipping unnecessary Actions if only updating part of a page with AJAX). Doubled Views are sort of inevitable though - you need a View to handle data responses from the server, and another client side to convert that data into updated HTML.

Back to the OP:
If I am building a rich internet application using Ajax and MySQL where the operator can dynamically add and remove lines and changes need to e sent bback to the server for validation against business rules using PHP processes, where do I store my objects (javascript client side or php server side).
You store the object where its manipulated and operated. Given two users can alter one or more lines at similar time, that the object is originated from a database, etc. That would be the server. Of course the client also needs to know about the current contents in order to display them, so you can easily have a simple value object client side which is pretty much restricted to being a cache of current rows the Javascript can manipulate and manage to update the HTML list, check user requests are valid (not ignoring the need for server validation), etc.

AJAX is a bit weird until you get used to it. As someone noted on the project I'm doing, the PHP application was looking more and more like a REST Web Service which focused primarily on serving data. The majority of presentation logic was tied up in the client side Javascript.
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Re: PHP OOP, Ajax and MySQL

Post by BDKR »

ole wrote:
If I am building a rich internet application using Ajax and MySQL where the operator can dynamically add and remove lines and changes need to e sent bback to the server for validation against business rules using PHP processes, where do I store my objects (javascript client side or php server side).
I think you are trying to get at is how to manage race conditions. This isn't an AJAX specific problem by any means.
Problem: If one user is in the process of adding lines to an order and another user completely removes one of those lines from sale what happens to the order?
Answer: Perhaps you need to have a limit on deletion of lines so that a line is frozen when it needs to be deleted and then can no longer be used in any new orders but still work with existing ones. Then periodically check whether frozen lines still exist in active orders if its not it can finally be deleted; this is a lot like garbage collection really. All of these actions will take place on a database level and although there can be objects representing lines and orders these and just representations of what is in the database.
Race conditions in AJAX is something that has gotten a good amout of attention primarily because it's definitely an AJAX issue. Read this and the links to other articles from it.

http://www.sitepoint.com/blogs/2006/11/ ... -sessions/
http://thwartedefforts.org/2006/11/11/r ... -sessions/

Cheers
User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Post by Kieran Huggins »

Normalize your input and you can (and rpobably should) use the same controller for web / ajax / json / etc. The business logic is the same.

Outputting depends on your implementation, I use XSLT so it's just a matter of writing a different transform for each type of request.

OOP is a fine tool in many cases, but don't hang yourself with the rope you're using to build bridges. Ok... that made sense until I read it. What I mean is this: OOP is "a good thing", but working software is essential.

Cheers,
Kieran
Post Reply