I've used PHP as a basis for a few home-grown database-based applications, and I've learned a lot in each project. What I haven't learned, and haven't found is a "best practice" for handling the information access cycle that seems to come up in every application I build.
To clarify, when building a php application which manages data in a database, I find that there are some specific functional needs which always come up:
(1) Insert new record
(2) Find existing record
(3) Edit existing record
(4) Delete existing record
Now my question focuses on the best way to write an interface for one or more of these functions. Take for example the insert, with a hypothetical item table.
One implementation would be to have one file contain the insert form, a second file do the insert processing, and a third file display the result of the insert:
insert-form.php -> insert-process.php -> insert-results.php
A second implementation would be to have one file which displays the form, processes the form, and displays results depending on context:
insert.php?function=form -> insert.php?function=process -> insert.php?function=results
or something along those lines.
To add a whole new layer of complexity, one could combine the insert and edit functions by using an idiom like editing record 0 results in an insert:
edit.php?record=23513 (edit record 23513)
edit.php?record=0 (insert a new record)
edit.php (display the form which asks which record number to edit)
I'm sure there are other implementations of these basic db functions.
I'm sure it's possible to maintain some kind of meta-information from which one dynamically generates an interface.
So.
In a dynamic development environment, where even table structures might change, what is the best practice for the layout of the interface? I haven't read any articles on this. Every book seems to have their own home-grown interface method which I've generalized above. Can any multi-project developers offer their experiences?
Thanks.
John
To clarify, when building a php application which manages data in a database, I find that there are some specific functional needs which always come up:
(1) Insert new record
(2) Find existing record
(3) Edit existing record
(4) Delete existing record
Now my question focuses on the best way to write an interface for one or more of these functions. Take for example the insert, with a hypothetical item table.
One implementation would be to have one file contain the insert form, a second file do the insert processing, and a third file display the result of the insert:
insert-form.php -> insert-process.php -> insert-results.php
A second implementation would be to have one file which displays the form, processes the form, and displays results depending on context:
insert.php?function=form -> insert.php?function=process -> insert.php?function=results
or something along those lines.
To add a whole new layer of complexity, one could combine the insert and edit functions by using an idiom like editing record 0 results in an insert:
edit.php?record=23513 (edit record 23513)
edit.php?record=0 (insert a new record)
edit.php (display the form which asks which record number to edit)
I'm sure there are other implementations of these basic db functions.
I'm sure it's possible to maintain some kind of meta-information from which one dynamically generates an interface.
So.
In a dynamic development environment, where even table structures might change, what is the best practice for the layout of the interface? I haven't read any articles on this. Every book seems to have their own home-grown interface method which I've generalized above. Can any multi-project developers offer their experiences?
Thanks.
John