Hi Jim,
In phpPeanuts there would be an instance of class FredEditDetails Page
that outputs the form and an instance of another class, FredSaveAction,
that updates a domain object (instance of class Fred) that updates the
database.
When the user presses the update button, FredSaveAction processes the
form. It creates an array with FormValues (instances of class
PntFormNavValue ) where it puts the values from the form. Then it asks
each of the values to convert its value (locale specific date and numner
formats, etc), and to validate it. If there is an error, the FormValue
will remember the error message. If any FormValue had an error, the
FredSaveAction creates an instance of FredEditDetails Page, sets its
error state and passes it the array with FormValues. Then it forwards
the request to the FredEditDetails Page. This will make the
EditDetailsPage output the form, the values from the form that was
submitted, the error messages, etc.
With phpPeanuts you may not have to program a specific
FredEditDetails Action: if you only need standard validation against meta
data, you can let the generic ObjectEditDetai lsAction do the work. If
you want you can make a specific FredEditDetails Action extend
ObjectEditDetai lsAction, do the inherited validations, the do you extra
validations. The same with FredEditDetails Page: if a standard Form will
do, you can simply use an ObjectEditDetai lsPage, if you need to, you can
specialize it.
For more info, see
www.phpPeanuts.org. There are examples on the
website, where you can try to enter errorneous information (for example
an email address without an @) and see how errors are reported (if there
are no errors it will tell you it is forbidden to change the data on the
website ;=) ). It does not highlight the fields, but because it has the
FormValues with error information, you can override the inherited
routine that prints the form and add the highligting in your own
FredEditDetails Page class.
Greetings,
Henk Verhoeven,
www.phppeanuts.org.
Jim wrote:
Hi,
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.
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?
There springs to mind several ways:
1) combine editfred.php and updatefred.php. Again, I'm not keen on this
but it does seem the most logical and programatically easiest.
2) use sessions to store the data, editfred.php would then check
for data in the session each time it's loaded. Is there a maximum data
size for use with session objects?
3) write code to wrap and store the data in a cookie which could then
be read by editfred.php, similar to sessions I believe. However max
cookie size is 4Kb which wouldn't be enough on some forms.
4) store the data from editfred.php in a table in the database which
again editfred.php would check for when loaded. overhead of db access
each time however.
Any other ideas? What method do you guys currently use?
Thanks,
Jim.
