I was wondering what the future plans are with FH, what is the goal? Why I'm asking this question? After reading some stuff about DataObjects/PDO/PEAR::DataObject I did some testing / playing, I find myself using FH quite often, together with a home-made-db-abstraction-layer etc...I'd love to see those things combined / related somehow.
Say you've got an application with some basic forms using a database. I want to show information from the database, mostly this happens through some query, perform and fetch-operation, through DO it would work more semanticly, the OOP-way.
Same goes for inserts/updates in FH, I haven't dived into the code but I guess no "DO" is used and queries are only generated by FH?
I know this is currently not in the scope of FH, that's why I'm asking the goals ;))
So to be short, will FH offer some way of database-abstration and data-object-handling in the future? How do you think about this? I think using PEAR::DB and PEAR::DataObject offers a very solid and widely usable platform, combined with FH it is "teh bomb" ;)
I noticed PEAR offers some package called FormBuilder, I haven't tried it yet because I'm almost sure it cannot compete with FH :D
Indeed, there are no data objects used in FH. Some time ago I've written a database abstraction class (which has now grown and named "yadal"). Currently, this class is used in formhandler. The problem of using data objects in FH is that FH needs more data then only the field's values. Version 1.2 (not released yet) checks :
- the indexes for double values (unique values),
- checkes if the fields can contain NULL,
- check if the field type is of the type "date" (so that the date has to be saved as db date)
- retrieves the primary keys automatically,
- retrieves the fieldnames of a table
Im not very known about data objects. I've worked with it once in a delphi project at school. So, im not sure if it's possible to make a database class with data objects which can do this. Maybe in combination with yadal... that could be an option...
Still, when somehting like that is realized, combining an own-made database class of the user and FH is extreme difficult. The database class of the user should always contain a set of methods where FH can rely on (interfaces).
Anyway, to get back to your question. Maybe you could take a look at the Yadal class and can combine this with your own database class. Im not known with PEAR::DB and PEAR::DataObjects, but I prefer to not use PEAR because then all users of FH should have pear, isnt it?
Had the same issue and decided to use FormHandler just to build forms and validate them. Thus I never use the database functionality of FormHandler.
My onCorrect method looks like this:
private function doRun($data){
$mapper = new UserMapper(new UserModel($data));
$id = $mapper->insert();
if($id > 0){
echo 'succeeded';
}
}
As you can see, it receives an array with inputdata. This is used to build a UserModel (fully automatic using dynamic set-functionalities). The mapper is a layer between the DAL and the Model, which holds all User related queries (like insert).
If you want more info I could try to explain this further. Just sent me an email at ruud-alberts <at> home <dot> nl
Changed at 22 December 05 / 11:17
I like the solution Ruud is giving. At this way you dont have to use FormHandlers database option. In FH3 v1.2 I've seperated the database options with the form options. So, now dbFormHandler is just a layer over de normal Form options.
It is possible to change this layer or to make your own database layer...
PS: sorry, the documentation of v1.2 is still unavailable. I'm working on this one.
