Any php coders out there?

[handyman]

in my basic test I had customer, event, event dates and a master table for bookings onto dates. For event I had a separate page to do the following add/added/update/updated/delete/deleted plus an index page to list all events.

[Damien]

I wouldn't have each different type of operation in their own file. Events could hold all the code. Maybe spilt the files into database operations (save/delete/get/update etc) and another for any logic.

[handyman]

I'll give that a bash with my lil 4 table tester and see how I get on. Thanks

[Damien]

My last post may not have been clear. I mean all database operations for a given 'thing' reside in one file. (it is possible a 'thing' spans multiple tables. Like Events and Event Locations will likely be different tables but the responsibility of a Event file. In that case it makes sense to have one file but more than one table).

[handyman]

You are likely very clear however I am still learning so still confused.

For the customer table I have and index.php file that extracts all of the customer data and displays this as a table. At the top I have a link to add a new customer and at the end of each customer record I have a link to delete or update. If I add a delegate this goes to add.php which is a form to capture the details which then sends this to added.php which performs the database addition. Similar for update/ updated. Delete.php is a 'are you sure' page which then sends the user to deleted.php on clicking 'yes' and deletes the row. This is repeated with the other tables.

I will PM you a link to what I have created so far. This is just my first attempt at working with relational tables so probably doing this all wrong. Hey it works though :-)

[Damien]

Yes. I see what you mean now. My points were referring more to code you store in makeshift classes and then call when needs be. I don't think having a file for each operation is a good idea. Instead you should be calling the methods (delete and so on) but they should reside in a smaller number of files than the url suggests.

I am not a PHP programmer so cannot really help you with that. I suggest you look at MVC frameworks for PHP or drop Punky a PM and ask him. I use .Net and related technologies and have code/systems which means a single class handles a lot of requests.

So if you were to go: somesite.com/products/edit/1

products would be the file
edit would be the method
1 would be a argument.

If you plan to make this quite large I suggest you go down the MVC path or ask Punky how PHP programmers deal with stuff like that

[Graham M]

Frankly, do it how you want it, if it keeps the code neat and tidy, do it the way you've been doing it. The only thing I will say is make sure the pages that don't need to be called separately can't be called separately, IE check they are referenced from the place they're meant to be or that the correct input data has been given rather than just making assumptions in your code - or you could end up in a world of pain later on.

Hope this helps

[punky]

Originally Posted by Damien

If you plan to make this quite large I suggest you go down the MVC path or ask Punky how PHP programmers deal with stuff like that

There are some MVC libraries for PHP including ZendFramework, CakePHP or CodeIgnitor. I think that would cause more problems than it would solve though. MVC programming isn't completely straightforward, especially for novices. Although for ZendFramework in particular (haven't used the other two) it does do a lot of the grunt work for you by abstracting DB access etc.

As for the thread, just go with what's logical and you can manage easy. Worry about coding within certain patterns when you are part of a coding team at a company.

Quite often when people ask for coding help the code they've put is really badly structured but i've learnt its easier in the long run to try and tweak it to work rather than completely restructuring it into how I or most others would do it.

[Damien]

Originally Posted by punky

There are some MVC libraries for PHP including ZendFramework, CakePHP or CodeIgnitor. I think that would cause more problems than it would solve though. MVC programming isn't completely straightforward, especially for novices. Although for ZendFramework in particular (haven't used the other two) it does do a lot of the grunt work for you by abstracting DB access etc.

As for the thread, just go with what's logical and you can manage easy. Worry about coding within certain patterns when you are part of a coding team at a company.

Quite often when people ask for coding help the code they've put is really badly structured but i've learnt its easier in the long run to try and tweak it to work rather than completely restructuring it into how I or most others would do it.

How would you suggest avoiding having a Php file for every possible operation? Seems messy too have a file for each update/delete and so on.

[punky]

Originally Posted by Damien

How would you suggest avoiding having a Php file for every possible operation? Seems messy too have a file for each update/delete and so on.

Well Apache doesn't care and if HM understands it fine then it doesn't really matter.

I've done a variety of patterns, it depends on the project. One idea is to perform a switch on the query string.

/events.php?do=add
/events.php?do=edit&id=55

then:

PHP Code:

switch($_GET['do'])
{

case 'add': performAdd();
break;
case 'delete': performDelete($_GET['id'])
break;
default:
//invalid operation
break;
}

} 


Seomtimes you split it up per database or table/model (like in MVC). Sometimes you split it up by operation. If you have a lot of operations you can split it up logically byu directory. It depends on experience and the project.