[TYPO3-core] IRRE implementation bugs

Martin Kutschker martin.kutschker-n0spam at no5pam-blackbox.net
Sun Oct 21 12:07:17 CEST 2007


Kasper Skårhøj schrieb:
> 
> On Oct 20, 2007, at 18:41 , Martin Kutschker wrote:
> 
>> Kasper Skårhøj (GMAIL) schrieb:
>>>>>
>>>>
>>>> Well, that's not quite true. When you look at moving or copying of
>>>> records, IRRE children are always copied/moved along with the parent.
>>>> (That is also why it's highly suggested to disable showing IRRE child
>>>> tables in the list module.)
>>>> So in those cases, they ARE treated as one object inside TYPO3s core as
>>>> well.
>>>
>>> OK, but thats a bit I don't get. Why shouldn't it be possible to share a
>>> child between two records as we can with normal group fields?
>>>
>>> In an implementation with these constraints, it has many implications
>>> for the core parts elsewhere. What if I make a copy of a child? What if
>>> I move it? What if I delete it? What if I link to it from another
>>> record? Am I not then breaking the concept of "exclusive parenthood"?
>>
>> You're question lead to one answer: a child record may neither be listed
>> not manipulated on it's own. TCEmain must decline any command that
>> request this and Web>Page, Web>List etc should honour this as well.
> 
> 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 was only deducing that constraint, which obviously is not been 
enforced, from the recent comments on WS and IRRE. I know a bit about 
WS, but nothing about IRRE.

But I get the feeling that the WS guys (or guy as it seems only you, 
Kasper, knows it) and the IRRE guys should, nay must, have a chat and 
talk about the whole thing before it turns into a mess.

Masi


More information about the TYPO3-team-core mailing list