Re: DB_DataObject_FormBuilder and many-many links

Norbert Mocsnik wrote:

Hello Justin, I want to make this more stable so it can really get added to FormBuilder. Thanks for your opinions, please keep me supporting with them as actually you seem to be the only one that I can talk about this. I will create a new FormBuilder.php with the latest version from CVS with all the changes we discuss here after we decided on the best way to implement them.

I also think the options should also be in the DO, not in formbuilder.

Yep, I'll move them there.

Perhaps this should be _crossLinks? No need for the auto IMHO.

Sure. Same for _tripleLinks.

'crosslinktable' should really be only 'table'.

Ok. The 'crosslink' prefix had only sense when I started implementing this (i.e. there was no _crossLinks array that time).

This should also give the full table name, not just the "to" table as naming conventions are not always the same. Ex: 'dvdsSubtitles' or 'dvds_link_subtitles'.

Right.

'masterfield' *should* be auto-findable just fine. Of course, it will require checking all of the links entries for the crosslink table. Small price to pay for less config, though.

I don't agree on this point. What if for any special reason you want have additional fields in the crosslink table, and one of them links also back to the main table? You couldn't decide which one to use.. Imagine a table which you use in multiple, very different ways and you need to use different master/detailfields for different purposes (from the same table). I do also agree with you at some level. So what about this? - you _can_ define masterfield/detailfield if you wish - if they are not defined, the _first_ link must specify the masterfield for the table in db.links.ini, the _second_ link must specify the detailfield

Yes, exactly. They should still be a configuration option, but also auto-findable. I don't agree with the first, second thing, though. What if you wanted your crosslink table to work from both tables? In this case, there would be an assumption that the first field is the "from" field when this is blatantly false as the table it links to is not the one you're "on". I would suggest that the first link field that has the table of $this->_do->__table should be the "from_field" and the first link "other" than the above one should be the "to_field". Here's some quick (non-tested ;-) code to do that: //after $links = $do->links(); in the crossLinks code if(isset($crosslink['from_field'])) { $from_field = $crosslink['from_field']; } else { unset($from_field); } if(isset($crosslink['to_field'])) { $to_field = $crosslink['to_field']; } else { unset($to_field); } if(!isset($to_field) || !isset($from_field)) { foreach($links as $field => $link) {

    list($linkTable, $linkField) = explode(':', $link);
    if(!isset($from_field) && $linkTable == $this->_do->__table) {
      $from_field = $linkField;
    } else if(!isset($to_field) && $linkField != $from_field) {
      $to_field = $linkField;
    }

} }

'detailfield' should also be auto-findable. I would suggest choosing the first link field other than the masterfield. For auto-finding these two fields, I would suggest making the config options optional but still supported for extreme (or speed consious) cases.

Yep. For easier implementation I suggested above to use the first and second links always. Do you like this?

'masterfield' could be 'from_field'. 'detailfield' could be 'to_field'.

master&detailfield sounds more professional to me but from_field and to_field is maybe easier to understand. Let's call it from_field and to_field then.

Well, one reason I don't like those names is because you could just as easily link from one side as the other. You coudl like dvd_subtitle from the dvd side or the subtitle side. Of course, there would be lots of checkboxes if you went from subtitle to dvd, but it's still valid. ;-) In this case, neither is really a "master" or "detail", except as it relates to the current form. To and from also seem easier to understand (as you said :-).

With autoTripleLinks, the table should be an option (as outlined above).

Yep, I will add it (it was auto-generated until now but it's better to have it so it can have an arbitrary name).

The fields should be auto-findable, as before.

first & second & third links, okay? - the first is the master, the other two are the details, and there may be any number of additional links (even to the master and detail tables, everything after the third line is ignored here)

Since I've already wrote it above, here's the code I'd suggest for tripleLinks as well (only slightly modified from above): //after $links = $do->links(); in the tripleLinks code if(isset($triplelink['from_field'])) { $from_field = $triplelink['from_field']; } else { unset($from_field); } if(isset($triplelink['to_field_1'])) { $to_field1 = $triplelink['to_field_1']; } else { unset($to_field1); } if(isset($triplelink['to_field_2'])) { $to_field2 = $triplelink['to_field_2']; } else { unset($to_field2); } if(!isset($to_field2) || !isset($to_field1) || !isset($from_field)) { foreach($links as $field => $link) {

    list($linkTable, $linkField) = explode(':', $link);
    if(!isset($from_field) && $linkTable == $this->_do->__table) {
      $from_field = $linkField;
    } else if(!isset($to_field1) && $linkField != $from_field) {
      $to_field1 = $linkField;
    } else if(!isset($to_field2) && $linkField != $from_field && $linkField != $to_field1) {
      $to_field2 = $linkField;
    }

} }

The linkedtable1 and 2 fields shouldn't be needed as the links.ini gives these values. 'masterfield' => 'from_field' 'detailfield1' => 'to_field_1' 'detailfield2' => 'to_field_2'

I agree. Regards, Norbert Mocsnik

-- paperCrane <Justin Patrin>