This objects/methods things is a bloody pain. Web application design is a bloody pain. UI -- that's a bloody pain too. Steps, or, a web application howto:
-
User interface
Think about what the user wants to be able to do. Make it really simple. Don't even consider what programming the bastard thing will then entail.
-
Front end scripts
The code on the front end should be barely more than augmented html. At this point you consider where your loops are and decide on your method calls for your back end. Do not at any point think about the programming. No referencing of data-structures; no subroutines. Simple simple simple.
-
Database
Now shift your attention to the database. Think about what data you have, where the relations are, and design tables which will minimise accesses, remove any replication of data, and inevitably bear no resemblence at all to the user interface. Still: Don't think about the programming.
-
SQL
You have to pull and update database data with elegant SQL that, again, minimises database accesses. Good database accesses are very important: There are risks here in data integrity so look out. The importance of it means you can't distract yourself by thinking about the back end yet.
- Back end
Finally! On one side you have a user-interface designed for the user, and therefore the object methods you're going to use are already defined, with no thought to how you're going to program the damn thing. On the other side, your database structure is already decided. Your job is to tie the two together, making best use of abstraction and inheritance to allow easy extensibility. You may now begin thinking about the programming.
Apparently the payoff is magnificent, but to be honest I can think of things I'd prefer to be doing.
This objects/methods things is a bloody pain. Web application design is a bloody pain. UI -- that's a bloody pain too. Steps, or, a web application howto:
Think about what the user wants to be able to do. Make it really simple. Don't even consider what programming the bastard thing will then entail.
The code on the front end should be barely more than augmented html. At this point you consider where your loops are and decide on your method calls for your back end. Do not at any point think about the programming. No referencing of data-structures; no subroutines. Simple simple simple.
Now shift your attention to the database. Think about what data you have, where the relations are, and design tables which will minimise accesses, remove any replication of data, and inevitably bear no resemblence at all to the user interface. Still: Don't think about the programming.
You have to pull and update database data with elegant SQL that, again, minimises database accesses. Good database accesses are very important: There are risks here in data integrity so look out. The importance of it means you can't distract yourself by thinking about the back end yet.
Finally! On one side you have a user-interface designed for the user, and therefore the object methods you're going to use are already defined, with no thought to how you're going to program the damn thing. On the other side, your database structure is already decided. Your job is to tie the two together, making best use of abstraction and inheritance to allow easy extensibility. You may now begin thinking about the programming.
Apparently the payoff is magnificent, but to be honest I can think of things I'd prefer to be doing.