Re: DB_DataObject_FormBuilder: how to override processForm() method

On Tue, 16 Nov 2004 13:34:48 +0100, Giorgio Gorla <gmontag@tiscali.it> wrote: > Justin Patrin ha scritto: > > >>>>http://pear.php.net/package/DB_DataObject_FormBuilder/docs/0.10.3/apidoc/DB_DataObject_FormBuilder-0.10.3/DB_DataObject_FormBuilder.html#methodprocessForm > >> > > > > Aha...it does say to override it. However, you should be overriding it > > in a class extended from FB, not in the DO. > > > > It's clear. Even so DB_DataObject_Formbuilder::create() returns a object > from a class that extends DB_DataObject_Formbuilder: > DB_DataObject_Formbuilder_QuickForm in > DB/DataObject/Formbuilder/QuickForm.php. Due to > DB_DataObject_Formbuilder::create() function has been wrotten, it seems > to me I've to override create() (extending DB_DataObject_Formbuilder) > before, and then I've to override process() extending > DB_DataObject_Formbuilder_QuickForm. ARGH!!! > Calm down, this is still easy to do. Make your own "driver" and put it in the DB/DataObject/FormBuilder directory. require_once('DB/DataObject/FormBuilder/QuickForm.php'); class DB_DataObject_FormBuilder_MyDriver extends DB_DataObject_FormBuilder_QuickForm { function process(...) { ... } } Put that in the MyDriver.php file, then do this to instantiate it: require_once('DB/DataObject/FormBuilder.php'); $do = DB_DataObject::factory('table'); $fb = DB_DataObject_FormBuilder::create($do, 'MyDriver'); > > > > >>I have this table: > >> > >>CREATE TABLE auth ( > >> username varchar(50) NOT NULL default '', > >> password varchar(32) NOT NULL default '', > >> PRIMARY KEY (username), > >> KEY password > >> (password) > >>) TYPE=MyISAM; > >> > > > > > > Why not this? > > > > CREATE TABLE auth ( > > id INT UNSIGNED NOT NULL AUTO_INCREMENT, > > username varchar(50) NOT NULL default '', > > password varchar(32) NOT NULL default '', > > PRIMARY KEY (id), > > UNIQUE (id), > > UNIQUE (username), > > KEY password (password) > > ) TYPE=MyISAM; > > > > This way you have an auto-generated key *and* you have the unique > > username constraint. Best of both worlds. In my experience, it's > > always best to have an auto-generated key in a table. 1) because it > > just makes things simpler and 2) it saves on space and processing time > > when doing selects and when using foreign keys. > > > > Also, why are you making password a key? Are you selecting by > > password? If not, I don't see why it would be a key...I could > > understand using the username as a key, but not the password... > > > > I agree, but I'm using Auth library from Pear and the table structure > above is that one suggestested by user's documentation > (http://pear.php.net/manual/en/package.authentication.auth.intro.php). > ok....just because it's the suggested method doesn't mean you have to do it that way, though. Adding an auto-key to a table *very* rarely screws things up. > > > > >>Within Auth.php (class DB_DataObject_Auth generated by createTable.php) > >>I've set > >> > >>$fb_hidePrimaryKey = false > >> > >>in order to input primary key manually. > >>But when I try to insert a new record, DBOF does an update. > >> > > > > > > Here's my take on this. If you want to use your natural primary key, > > you should be using the forceQueryType() function of FB. If you call > > as so: > > $fb->forceQueryType(DB_DATAOBJECT_FORMBUILDER_QUERY_FORCEINSERT); > > The data will be inserted instead of updated. To check for this, > > you'll have to do a query before the processform method is called, > > then force the insert if it's a new record. > > > > You could also change the way that the update() method on your DO > > works something like this: > > function update($do = false) { > > if ($do === false) { > > $checkDo = DB_DataObject::factory($this->__table); > > if (!$checkDo->get('username', $this->username)) { > > parent::insert(); > > return; > > } > > } > > parent::update(); > > } > > This will insert the record instead of updating it if the username > > isn't found in the DB. This isn't a great system as you can't change > > your username with it. > > > > > > Ok, so that's a bad idea. Your best bet is to add a hidden field to > > the form which tells you whether you'rs updating or inserting, then > > force the query type on submit based on that value....of course, this > > is precisely what having an auto-generate PK does for you. ;-) > > > > Thanks a lot for your suggestions, J > -- Justin Patrin