Description: ------------ As once discussed, a callback/function for customizing the fields in a crossLink would be nice, so that it's possible to change there WHERE and the SELECT, maybe the whole Query, or the DataObject (before ->find() is done). For example, ATM date customization and restricting the WHERE clause is not possible, all entries from the the toField-Table are shown.

Funny that you should mention this, we were recently talking about this. What exactly do you mean by "field customization" and "date customization"? My idea was to have a new callback called prepareLinkedDataObject which would get passed the DO of the linked table before the find() is done. function prepareLinkedDataObject(&$do) { //here you can do something like... if ($do->tableName() == 'images') { $do->proj_id = $this->proj_id; } }

I was the one who sparked the similar conversation. My example was such: 2 tables projects, images images has a proj_id field as each image belongs to a project projects has a img_id field that links one of the images that belong to it as a key image. Problem is when a image is chosen I dont want all images to show. I only want the images that belong to that project to show when FB is used. What I thought would be a great and simple solution, realizing that it would probably require cooperation with DataObject, is to allow the database.link.ini to handle a kind of where clause such as: [projects] key_img = images:img_id @ images:proj_id = proj_id where the '@' symbol would obviously define the where clause. Makes it super simple for the user. Here is at least some of what I did to work around the issue as is. Note that if you see this and think "hey you could have done this simpler by ...", I would love to know that thought. Dataobjects-- Images.php ... /* Change find() to provide only images selected for this project */ function find($n = false, $all = false) { if(!$all && isset($_POST['edit_proj']) && isset($_POST['submit_proj']) && ($_POST['submit_proj'] != "Edit Image")) { $this->img_project = $_REQUEST['edit_proj']; } return parent::find($n); } So code wise thats not too bad (though it took me a while to get it tweaked just right). What BOTHERS me most about it is that I have to use $_REQUEST variables in my dataobject, bleah thats yucky. It would be so much nicer if it could be defined in the link.ini. That way it is only used when that particular crosslink is accessed and you dont have to escape it for all other requests. I can think of a bunch of other 'pros' incluidng amplifying the simplicity that DO and DOFB seem to strive for. I also understand Justins concerns of a BC break and its lack of usage in DO other than to provide FB with more strenght. Hey wait isnt that enough =) Frank

Second note...Justins suggestion makes alot of sense upon further consideration. Its still pretty simple and it would allow for a variety of tweaks. But I do love the .ini setup, it seems so clean. Of course I have no idea currently what it would mean on the inside. But I would like to find out. Anyone? FF

Justin, I meant to change the selectAdd, and where WHERE, so I can do things like date customization in the cross-link. Your solution sounds pretty nice and should be very low effort to implement.

The solution with the modified .ini file is not quick and easy to implement. Not only would DataObject itself have to be changed to be able to cope with the new settings, but also the DataObject Generator needs to be modified, so that it won't overwrite your custom-made settings on the next run. Also, there are some people (including me) who are not using the .ini files at all, because they're simply impractical when dealing with larger databases. Thus, another solution would have to be present, you can't rely on the .ini files being there - and if DataObject itself does not make use of the additional settings, there won't be a corresponding data structure for this in DO.

Markus has it right, DB_DataObject would never use this data. All it does is pull records based on the link field. It has no funcitonality to pull all options for the link. This is an FB thing. *If* we put it in the ini, I would suggest to Alan that he add another function (linkWhere or some such) which would have the extra data, but I doubt he would want to add the overhead to DB_DataObject (besides, he's busy on the C extension version). The callback will be very easy to implement. I may get around to it today. Anyone have ideas on any changes? Is what I proposed good enough?

Just to clarify, the prepareLinkedDataObject() callback function would go into the DataObject from which the form is built, right? Not the DO targeted by the link. In that case, I'm all game.

Yes, it would go into the DO for the form that is being created, meaning that the function is dependant on where you'r elinking *from*, not *to*. In my example, I show how you can change it depednign on where you'r elinking to by checking the passed in DO's table.

This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. I've added the options to CVS (was only 3 lines ;-). I also added a second parameter as I thought it might be useful for some instances. See the docs on the wiki: http://opensource.21st.de/tiki-index.php?page=Callback+methods#id896154

Justin, thank you very much!