[TYPO3-mvc] !!! FYI: Committed big refactoring of Fluid; v4 and v5 are now in sync again

[Franz Koch]

Hi Bastian,

>> In Tx_Fluid_Core_Parser_Syntaxtree_ViewHelperNode you're referring to
>> some FLOW3 stuff in line 95 (FLOW3_AOP_Proxy_getProxyTargetClassName).
>> I'm pretty sure that it's on your TODO list to decouple FLUID from
>> framework specific stuff, I just wanted to point you to that spot I
>> coincidentally noticed.
>
> Yes, the lines you're talking about are
> if (FALSE /*FIXME*/) {
> $this->viewHelperClassName =
> $this->uninitializedViewHelper->FLOW3_AOP_Proxy_getProxyTargetClassName();
> }
>
> -> As we don't have to take care of Proxy Classes in v4 this condition
> is never executed. So technically this is not a problem. But I agree,
> that we could improve the backporter here so that it removes this check
> completely.

Acutally I don't think it's a issue of the backporter, but more a 
general issue of FLUID and it's more or less tight integration into 
FLOW3/v4. What I would expect from a templating framework, is that I can 
easily integrate it in my project, be it a custom CMS, some small PHP 
app or whatever. So in my eyes, there should be something like a 
framework-interface that has to provide certain methods FLUID depends on 
(getClassName, makeInstance, storeInSession,...), but the framework has 
to take care of (like in FLOW3 the AOP stuff etc.). I haven't dug that 
deep into FLUID yet, but I think such a approach is currently not 
considered - but would be the way to go in my eyes. I understand that 
the FLOW3 version of FLUID might need some special treatment (using 
namespaces etc), but besides of that it could/should be somewhat generic 
and just a matter of switching the framework-interface, no?

-- 
kind regards,
Franz Koch