Description: ------------ This was alluded to in another bug. When setting crosslinks, it would be nice to allow editing of other fields in the crosslink table. This will probably mean using the new ElementTable element I created for FB.

I have just committed a patch to create this funcitonality. If you define 'extraFields' in your crossLinks array you can edit extra fields, just as the normally would be in a form for that table. For example, if you have a third link field set up in the crossLink table and put that in extraFields you will get a select box. :-) var $fb_crossLinks = array(array('table' => 'crossLinkTable', 'extraFields' => array('editme1', 'editme2')));

Quick note: I've added this option to the wiki. Please let me know what you think of it.

Does this option make sense where I put it? Should this config perhaps be in the crossLink table's DO as: var $fb_extraCrossLinkFields = array('field1', 'field'2); ? The way it currently is it lets you change the fields based on where you're viewing the crosslink *from*. This new way would make it the same for all viewings of the crossLink. The reason I'm proposing an alternate method is: 1) simplicity (having it in one place for multiple invocations is nice) 2) I see possible consistency problems, kind of like for bug 2889 (reverse links). If one adds a crosslink in one form which doesn't have all of the extra fields, it may leave tje DB inconsistent. But then again, this is a job for the UI designer/programmer, not FB. What do others think of this option? Should I leave it where it is for flexibility or should I move it for convenience and consistency?

Both places have their pros and cons, as always... one might argue that the interface designer should not have any business messing around with the DataObjects, which represent business logic, so the option must go into the crosslink table class itself, because it globally defines the behaviour or forms built against it. On the other hand, until now we always had all options within the DataObject the form is built *from*, so this would introduce an inconsistency in the way FormBuilder works. Hm. Difficult. Personally, I think I'd rather go for "leave it where it is" to keep FormBuilder behaviour consistent.

This isn't quite accurate. The linkDisplayFields and linkOrderFields options go into the table that is linked *to*, not *from*. This new option strikes me as very similar to those ones, which is why I'm asking.

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 moved the option from an extraFields array key to the fb_crossLinkExtraFields option in the crossLink table. Docs here: http://opensource.21st.de/tiki-index.php?page=Formbuilder+configuration+options#id905582