[TYPO3-core] IRRE implementation bugs

[Ingmar Schlecht]

Hi Kasper,

Kasper Skårhøj wrote:
> It seems that IRRE is made only for M-1 relationships (many children to 
> one parent). And I didn't realize that the shown records was limited to 
> those pointing to the parent as you describe. 

Well, the foreign_field saving method is just one of the possible saving 
methods. There's the option to save the relation in a separate relation 
table (MM table) or in a comma-separated string field as well, which 
would allow for M-M relationships. I just mentioned it as one saving 
method that wouldn't support a multi-parent approach, so at least for 
this method versioning would have to automatically create versions of 
the children as well or otherwise loose the relationship.

> And I don't dispute that 
> it is logical for a user that copying the parent should copy the 
> children. However, copies are often made by users as templates for new 
> objects. In such a case it is not given that a user wants all children 
> to be replicated as well if they are interested in starting a new parent 
> based on another ones base information.

It's the same with pages, isn't it? If you uses a page as a 
copy-template, the records on that page are copied as well.

> About IRRE being purely M-1 is not logical for me. The full potential is 
> if it can handle M-M. For me many M-M situations warrants that I can 
> edit the children directly in the parent form, even if they are children 
> of other parents. That is a question of convenience.

I find it inconsistent usability-wise if IRRE children are sometimes 
copied along and sometimes not; changes in children sometimes affect 
other parent's children and sometimes not (same goes for moving, 
deleting and versioning) and at the same time found that the "treat as 
one object" approach is the one that is more often to be found and 
therfore the one to go for.

But there's something called combination view (useCombination=1) in IRRE 
which makes it possible to actually edit MM relations. The trick is that 
the 1:n IRRE relationship actually goes to an intermediate table (the MM 
table) which has a full TCA configuration and connects the two other 
tables. If one of the fields of that intermediate table is a DB relation 
field (group or select) then IRRE offers to edit the record that 
relation field points to directly inside of the form as well, with big 
red warning labels so you know you're editing something that affects 
other places as well.

Have a look at the attached screenshot I prepared for you :)

The form in the screenshot actually affects three (!) database records: 
The parent, intermediate and child record.

What's pretty handy is that even the intermediate table can have 
editable fields (unlike traditional MM tables used for e.g. group fields).

> "Could you name one real world example where you would like the IRRE
>> interface but not the "unique parenthood" principle?"
>
> Lets take parent/children literally:
> We have a mother and a father. They have a common child. There are M-M 
> relations (2) between the child and mother/father. I would like the 
> child record to show for both the mother and the father when I edit 
> them. If the child changes name the day she gets married, I would be 
> able to enter both the father and mother record can change the name there.

Hmm... OK... Valid example :)

> ah... whatever. The point is that you can never know how people want to 
> use your technology and IRRE shouldn't impose judgements on that either. 
> Of course you should allow people to copy the whole parent-tree in one 
> go, but it shouldn't be a hard coded constraint I believe.

I could live with that (would need someone to implement it though).

Regarding the question of versioning though we have to find a solution 
for the current 1:n approach, regardless of whether M:M will be 
supported as well at some point.

cheers
Ingmar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: irre-screen.png
Type: image/png
Size: 11007 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20071021/71a99b95/attachment-0001.png