|
|
Posted by Tim Van Wassenhove on 08/26/05 02:20
On 2005-08-25, Jim <jimyt@yahoo.com> wrote:
> Let me explain how I'd generally do things. For a page where the user
> edits data, I'd generally call it something like editfred.php (for
> example), the page which updates the data would be called
> updatefred.php and equally the page which processes a delete would be
> deletefred.php. I like splitting the pages up this way, it feels less
> cluttered and more organised than throwing all the functionality in one
> fred.php.
KISS :)
> Here's the problem though. If the user enters erroneous data into the
> form editfred.php which is subsequently processed by updatefred.php
> then that error needs to be reported to the user. Traditionally what
> I've done is have updatefred.php list any errors it finds and then
> provide a link to go back or ask the user to hit the back button on
> their browser. This is no longer viable, instead I'd like to
> automatically throw them back to editfred.php with all their data
> already filled in and the fields causing errors to be highlighted. My
> question is: what's the best way to do this?
I have a hard time to understand why you would want to have a editfred
if you also have a update/add/delete script? What does the edit script
add of extra value?
You could make a base script/class that shows the details of a fred
form. Depending on the "mode" it also show existing values and decided
which input controls it should show... mode=edit for add/update.
mode=read for enquire/delete.
And then write an update/read/delete/add specific functionality that
extends the base script/class.
--
Met vriendelijke groeten,
Tim Van Wassenhove <http://timvw.madoka.be>
Navigation:
[Reply to this message]
|