PHP Pear - Re: [PEAR] FormBuilder linkNewValue issue

Author

Re: [PEAR] FormBuilder linkNewValue issue

Justin Patrin

2005-05-26, 8:59 pm

On 5/19/05, Alessandro Pasotti <ale.pas@tiscali.it> wrote:
> Hello,
>=20
> I have a big problem here:
>=20
> * I have a FB form with one linkNewValue linked table (PK on linked table
> points to FK on main table)
> * When there is an error in the main form, the linked new value in sub-fo=
rm is
> inserted correctly in the DB, but the form is displayed again as nothing
> would happened in the sub form.
> * When I correct the main form and submit it again, FB try to insert the
> sub-form
> values again and fails because DB constraints check for uniq in the linke=
d
> table.
>=20
> I don't know if this is a bug or I did'nt understand how it works.

So basically you're getting a DB error on inserting the main record.
How are you handling this? FB doesn't do any transactional stuff, so
it can't really rollback. You could easily start a transaction before
you process the FB and then roll it back if processForm returns an
error. In fact, this is what I suggest you do. FB assumes that if the
form validates it will process correctly. The DB processing is not
fault tolerant at all. If something fails it's up to the calling app
to deal with it.

If you're getting lots of DB errors I suggest you re-think how you're
entering data. If you're clashing on a UNIQUE field it's a really good
idea to add a QF formRule which checks to make sure that that field
(or set of fields) is unique. Granted, it is still possible for the
unique constraint to fail if two users submit the same data at the
same time, but this will avert 90%+ of unique constraint problems.
Also, this allows you to give a nice QF-friendly error message for the
field(s) which must be changed instead of a big DB error message which
says who knows what. This also has the added bonus that you don't do
*any* DB operations at all and the form itself doesn't validate.

Now all that said it *might* be possible to deal with linkNewValues
specially..however, due to the nature of the system, it will be hard
to do. The form is created before any processing happens and the
processing function has no way to access or change the form as you've
already been given it. This would make it impossible to alter the form
to select the correct value and hide the linkNewValue form (or to give
the linkNewValue form the correct record ID). linkNewValue forms are
simply not set up to edit records, only to insert them.

I suggest you combine the two methods I mentioned above. Check your
constraints in a formRule and also use transactions on the DO.

>=20
> Expected behaviour:
>=20
> there are two possibilities:
>=20
> 1 - kind of rollback on insertion of linked sub-forms when the main form =
fails
> 2 - set the sub-form hidden PK to the value of the last inserted row and =
set
> the main form linked field to the same value
>=20
>=20
> Any help would be higly appreciated.
>=20

--=20
Justin Patrin

Alessandro Pasotti

2005-05-26, 8:59 pm

Il 02:23, venerd=EC 20 maggio 2005, Justin Patrin ha scritto:
> On 5/19/05, Alessandro Pasotti <ale.pas@tiscali.it> wrote:
le[color=darkred]
in[color=darkred]
>
> So basically you're getting a DB error on inserting the main record.
> How are you handling this? FB doesn't do any transactional stuff, so
> it can't really rollback. You could easily start a transaction before
> you process the FB and then roll it back if processForm returns an
> error. In fact, this is what I suggest you do. FB assumes that if the
> form validates it will process correctly. The DB processing is not
> fault tolerant at all. If something fails it's up to the calling app
> to deal with it.

Thanks for the quick answer, I implemented commit/rollback stuff and now it=
=20
works great.

I have another problem yet (the DB design is unfortunately not my choice):=
=20

* Imagine you are adding a new record in the same scenario described above,=
=20
* When you call validation method _before_ the subform is processed it fail=
s=20
because the required FK for the linked table is null.
* To make it work, I had to modify fb->processForm to posticipate validatio=
n=20
of the main form _after_ the subform is processed.

Is there a more "elegant" solution for this problem?

=2D-=20
Alessandro Pasotti
ICQ# 245871392
Linux User #167502

Ken Restivo

2005-05-26, 8:59 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, May 20, 2005 at 07:52:10AM +0200, Alessandro Pasotti wrote:
> * Imagine you are adding a new record in the same scenario described above,
> * When you call validation method _before_ the subform is processed it fails
> because the required FK for the linked table is null.
> * To make it work, I had to modify fb->processForm to posticipate validation
> of the main form _after_ the subform is processed.
>

I ended up having to implement my own FB-like functionality (mostly API-compatible with FB, in case I want to switch later), and this is exactly how I had to do it.

My custom validate() and process() methods loop through all the subforms first, and deal with them before the main form is looked at.

- -ken
- --
- ---------------
The world's most affordable web hosting.
http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCjg7ie8HF+6xeOIcRAo0gAKDtEO6aMS0Z
k54vUrnXUCtJG4AclwCg4dKj
neUtyzSMBHksSmgDknrBuXg=
=Mcnt
-----END PGP SIGNATURE-----

Sponsored Links