[TYPO3-core] RFC: Bug #6688: Use the remapStack also for updated IRRE child records

[Ingo Renner]

Oliver Hader wrote:

Hi Olly,

> Ingo Renner schrieb:
>> * why did you put the hook in a separate method?
> 
> Hm, why not? Did you see the code in context? 

I actually had a look on the patch only.

 > Before this method is a
> method "hook_processDatamap_afterDatabaseOperations". Should this old
> one be removed then? But I'd be fine with using the new hook in the
> regular way.

I actually don't see a reason why hooks should be separated into methods 
for their own even if it was done so before. This now raises the 
decision between consistency and "how it should be done". I'm for "how 
it should be done".

>> * where's the interface? - please no more method_exists in new hooks!
> 
> The result would be to check each instantiated hook objec against the
> interface class and applies for whole TCEmain. Thus, all extensions
> which use a TCEmain hook and were developed before TYPO3 4.2 won't work
> anymore. I think this is a no-go.

ok, agreed - didn't notice you were reusing an existing object. 
Regardless of breaking "some" extensions I still think it'd especially 
be cool to have an interface for TCEmain.

> By the way:
> Were is a description or CGL which points out that this interface method
> should be used for TYPO3 4.2 and also gives a hint on how it should be
> used and implemented correctly?

This still needs to be documented in the CGL. Anyways I suggest sticking 
with the way of the now existing hook+interface implementation.

> If I look to class.browse_links.php, I just see the "instanceof" check
> and a "UnexpectedValueException" with a string and a long number as
> arguments. What does this number stand for?

I explained that in a response to one of Bernhards hook requests 
already, also needs to be documented. I'm really surprised no one asked 
before when I introduced the first interfaced hook.

That number is the unix timestamp at the time you wrote that line. This 
will make it easy to find the place where the exception was thrown and 
can also be used as an error code in bug reports. It is pretty uncertain 
that the same unix timestamp will be in the core more then one time ;-)

> Shouldn't there be something more like an exception handling? Which part
> of the Core is catching and handling the exception thrown in
> class.browse_links.php? 

There's no exception handling yet, feel free to implement one =)
Maybe a generic exception handler will do for the beginning by just 
logging the exception.

 > If exactly this concept should also be taken for
> other new hooks - is it then really good, that a wrong hook in any
> extension can block the whole system?

I expect that a good extension developer will test his extension and 
notice the exception before releasing it to the wilderness of TER.

> I'm looking forward and I'm open-minded to use new techniques and to use
> more OOP, because it's the right way. But it needs some more efforts
> than e.g. just writing "proteced" before function names... 

sure, agreed. We just need to start somewhere, unfortunately there's no 
brain2code button yet...


all the best
Ingo

-- 
Ingo Renner
TYPO3 Core Developer, Release Manager TYPO3 4.2