468,514 Members | 1,636 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,514 developers. It's quick & easy.

edit/update - all in one PHP pages?

Jim
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.

Aug 25 '05 #1
10 1766
Hi!

Are you looking for "serialize()" ?

Best
Olaf
Aug 25 '05 #2
Jim
I don't believe so. I'd still have the same problems. If I serialise
all the form data, I still need to send it back to the original input
page and that'll have to be done either through cookies, database or
text file. The only other way I can think of is the risky use of
javascript to submit a hidden form produced by the update page.

I'm struggling to find justification for not putting the edit/update
functionality in one php file, my original worry (other than the fact
that I just don't like the idea of having the two processes combined)
was the performance issue of the interpreter having to parse a file
probably twice as big as it needs to be.

Jim.

Aug 25 '05 #3
Hello!

Put the serialized data in a session Variable....

Olaf
Aug 25 '05 #4

Olaf Schinkel wrote:
Hello!

Put the serialized data in a session Variable....


Session values are automatically serialized when they are stored. No
need to serialize them first. Just store everything you need in session
variables.

Ken

Aug 25 '05 #5
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:
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.

Aug 25 '05 #6
On 2005-08-25, Jim <ji***@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>
Aug 25 '05 #7
Jim
> 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?
Here's how I currently name my scripts:

view*.php - viewing data only
edit*.php - an editable form with data populated ready for changing
new*.php - blank form ready for new record entry
update*.php - processes contents passed from the edit script
create*.php - processes contents passed from the new script
delete*.php - deletes a specific record

So as you can see each individual operation is separated in to a
different php page, this keeps the pages cleaner and shorter although
admittedly, there is duplication of validation and form design although
I've never found this to be a problem.
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.


This is advocating the "all in one" script approach, which I must admit
I don't like the thought of but it is clearly the most logical. What's
the overhead like for the extra parsing the interpreter needs to do? If
I combine the files I'm probably gonna end up with a single php file
around 150% bigger.

Thanks,

Jim.

Aug 26 '05 #8
On 2005-08-26, Jim <ji***@yahoo.com> wrote:
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?


Here's how I currently name my scripts:

view*.php - viewing data only
edit*.php - an editable form with data populated ready for changing
new*.php - blank form ready for new record entry
update*.php - processes contents passed from the edit script
create*.php - processes contents passed from the new script
delete*.php - deletes a specific record


Each task is spread over two pages now. And as you mentionned
already, you now introduced the problem that you have to share data
between the two pages.
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.


This is advocating the "all in one" script approach, which I must admit
I don't like the thought of but it is clearly the most logical. What's
the overhead like for the extra parsing the interpreter needs to do? If
I combine the files I'm probably gonna end up with a single php file
around 150% bigger.


No it's not advocating "all in one". It advocates that you group
everything that logically belongs to each other together.

Eg: An "insert" script first displays empty fields (meaby a couple of
default values are filled in), and then inserts them into a database.
An update script displays fields (with existing values) and then updates
the database.

They have in common that in both cases you have to display a form with
fields (and meaby values). They are distinct in the processing that is
performed after the data is posted.

Therefor i advocate to have an "edit" base that shows the form (with
eventual values). And then make your insert/update an extension
(inheritance) of that edit base.

If you now change your base a little, you can introduce the concept of
a read only-field. This allows you to use the base also for
enquire/delete (where you first want to display the actual record).
Thus, an enquire/delete script also extends the base edit. Once
again, they have a different "process posted data" implementation.
--
Met vriendelijke groeten,
Tim Van Wassenhove <http://timvw.madoka.be>
Aug 26 '05 #9
Jim wrote:

1) combine editfred.php and updatefred.php. Again, I'm not keen on this
but it does seem the most logical and programatically easiest.


We do it this way and it works out well. The trick is to divide the
processing into two stages. First is data processing ( do an update,
insert or delete), and second is display.

You can then control flow by having the results of data processing, stage 1,
determine what happens in stage 2.

So for example the user requests to input a new row. This is a simple case
where there is no data processing yet, so you do nothing at Stage 1 and at
Stage 2 you return the HTML INPUT controls to enter a new row.

Going further, the user now saves the new row, so at Stage 1 you must do the
insert. If the insert succeeds, then in Stage 2 you go to Display mode and
show them the row they just put in. But if the insert fails, you set the
flag to return them to Insert mode and display the error message.

In like fashion, you work out what you want to happen on each data
processing action. What happens when it fails, what happens when it
succeeds. So perhaps on a successful delete you move to the next row in
the search results, but on fail you return to display mode and show them
the row with the error message.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
Aug 26 '05 #10
Jim
Thanks to all for the replies.

I've decided to keep the pages separate and use sessions to pass data
between them when an error occurs. The reason for this is that in
reality, these errors will hardly ever be generated. It's only when the
user has javascript turned off that this functionality will be needed
as javascript validation will capture errors from all but one field out
of about 15 forms.

This keeps my pages simple (just like me) and means that the
interpreter won't be wasting processor power.

Thanks,

Jim.

Aug 26 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

25 posts views Thread by dixie | last post: by
4 posts views Thread by DC | last post: by
9 posts views Thread by rn5a | last post: by
1 post views Thread by chromis | last post: by
2 posts views Thread by slinky | last post: by
1 post views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.