[TYPO3-core] IRRE implementation bugs

[Kasper Skårhøj]

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. 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.

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.

"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.


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.


- kasper






On Oct 21, 2007, at 0:12 , Ingmar Schlecht wrote:

> Hi Kasper,
>
> Kasper Skårhøj wrote:
>> If this is true I can't endorse that conceptually I'm afraid. And I
>> simply don't see why IRRE would require this constraint. It's adds  
>> lot
>> of new complexity to an already complex TYPO3 core and IRRE  
>> becomes less
>> flexible by not offering it's brilliant interface for applications  
>> where
>> this constraint is in fact not wanted. So maybe someone can  
>> explain to
>> me why this constraint was so important?
>
> I'm really surprised you see it that way. I always found it to be
> completely inconsistent if we ever allowed to reuse children within
> multiple parents.
>
> The technical constraint is that the IRRE saving method  
> "foreign_field"
> is written child-up instead of parent-down which means the child  
> points
> to the parent in an integer field, and therefore cannot have multiple
> parents.
>
> But the real constraint is the usability one: I think it's totally
> confusing and misleading if you are able to edit a child record in one
> place and it's changed in a totally different context as well.
>
> Could you name one real world example where you would like the IRRE
> interface but not the "unique parenthood" principle?
>
> If you think of persons having addresses (which arguably could be  
> shared
> among different persons), you'd never want it to be possible to  
> edit the
> address record inside of person A because that would unexpectedly  
> change
> it in person B's profile as well!
>
> cheers
> Ingmar
> _______________________________________________
> 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/20071021/45386c10/attachment.htm