[TYPO3-core] IRRE implementation bugs

[Kasper Skårhøj]

Thanks for the screenshot :-)

It's no urgent issue but we should definitely have a session on  
workspaces and in that context IRRE as well at the next DevDays (hope  
I can come, will depend on school pressure).

Have a nice week.

- kasper



On Oct 21, 2007, at 23:21 , Ingmar Schlecht wrote:

> 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
> <irre-screen.png>
> _______________________________________________
> Before posting to this list, please have a look to the posting rules
> on the following websites:
>
> http://typo3.org/teams/core/core-mailinglist-rules/
> http://typo3.org/development/bug-fixing/diff-and-patch/
> _______________________________________________
> TYPO3-team-core mailing list
> TYPO3-team-core at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-core

- kasper

-----------------------------------------------------
How many women does it take to get a baby in 1 month?

Kasper Skårhøj
Tryggevældevej 8
2720 Vanløse
+45 20 999 115
skype : kasperskaarhoej


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20071022/b99dcfaa/attachment.htm