Hi Jim,
In phpPeanuts there would be an instance of class FredEditDetailsPage
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 FredEditDetailsPage, sets its
error state and passes it the array with FormValues. Then it forwards
the request to the FredEditDetailsPage. 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
FredEditDetailsAction: if you only need standard validation against meta
data, you can let the generic ObjectEditDetailsAction do the work. If
you want you can make a specific FredEditDetailsAction extend
ObjectEditDetailsAction, do the inherited validations, the do you extra
validations. The same with FredEditDetailsPage: if a standard Form will
do, you can simply use an ObjectEditDetailsPage, 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
FredEditDetailsPage class.
Greetings,
Henk Verhoeven,
www.phppeanuts.org.
Jim wrote:
[color=blue]
> 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.
>[/color]
