Re: DB_DataObject_FormBuilder questions
| From: | Justin Patrin | Date: | Fri, 31 Dec 2004 22:13:29 +0000 |
| Subject: | Re: DB_DataObject_FormBuilder questions | ||
| References: | 1 2 3 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-16546@lists.php.net to get a copy of this message | ||
On Fri, 31 Dec 2004 13:29:56 +0000, Peter Bowyer
<peter@mapledesign.co.uk> wrote:
> Hi Markus,
>
> At 11:35 30/12/2004, Markus Wolff wrote:
> >you can define a postGenerateForm() method and freeze individual fields there:
> >
> >function postGenerateForm(&$form)
> >{
> > $form->freeze(array('field1','field2','field3'));
> >}
>
> The problem with this (and correct me if I'm wrong) is that this has to go
> into the DB_DO class (unless I play with global variables) so requires me
> to have a subclass for 'edit' actions (as opposed to 'add' actions).
> I'm
> sure adding this hidden action field to the form is possible, and indeed I
> have it showing up after modifying preGenerateForm() to add the extra
> field, but I cannot populate it with a value?
I'm not sure exactly what you're saying about a hidden action field,
but you can always set values for fields with QF. Just use
$form->setDefaults().
As for the insert/update issue I suggest a variable in your DO class.
You can set it if fetch() is called. Somehting like this:
class DataObject_Table extends DB_DataObject {
//normal stuff
var $_fetched = false;
function fetch() {
if ($ret = parent::fetch()) {
$this->_fetched = true;
} else {
$this->_fetched = false;
}
return $ret;
}
}
Then you can check $this->_fetched in postGenerateForm to tell whether
or not to freeze the field.
>
> Tracking state is needed so I can initialise the correct class on the next
> page, and show the right fields for the action (otherwise editing goes back
> to the adding form, with extra fields.
>
> >For FormBuilder itself, I think this is a bit out of scope.
>
> That depends on the uses you see FormBuilder being put to. I'm trying to
> make it so any database table can have records added/edited online, with
> the fields shown customised so 'normal' users can't mess things up. Kind
> of like a PHPLens or phpdb idea.
I've never used PHPLens or phpdb.
I solved this problem by adding a config var to the DO which says what
user groups can edit which fields, then freezing fields the user can't
edit in postGenerateForm. Yes, this required messing about on DB_DO,
but, as Markus said, this is out of scope for FB. FB is meant to make
and process a form, no more. Adding permissions to it would be a huge
step. If you want to make a new package which extends FB that adds
permissions, that would be great. ;-)
--
Justin Patrin