[TYPO3-core] RFC: Hook request for t3lib_befunc + t3lib_userauthgroup

[Bernhard Kraft]

Oliver Hader wrote:

> Seems like it happend again that we've done similar work... ;-)
> See here: http://bugs.typo3.org/view.php?id=5613
> 
> My patch there is extending the t3lib_matchcondition instead of creating
> a new file. Maybe we could compare and merge some work if required.

Hi !!

Yes. But this time we could merge our efforts. And make some kind of "hybrid" :)

I will list the pros and cons:


+ Oliver
- Bernhard
-----------------
I created a complete copy of t3lib_matchcondition. You created a version which has
dual capabilities: BE & FE - by using a flag and putting the "data aquisition" mechanisms
(getting user/group etc.) into separate methods. Which is a better approach than mine.


- Oliver
+ Bernhard
-----------------
But on the other hand I implemented proper caching like it is done for TypoScript in
the FE :) So here my approach is better.

My version also works for User/Group TS-Config. (parsed in t3lib_userauthgroup->fetchGroupData)


- Oliver
- Bernhard
-----------------
None of our both versions works for FE-TS-Config. I know TS-Config get's used at some
places in the FE (RTE, etc.) Have a look at tslib_fe->getPagesTSconfig.

Maybe Stanislas could give us some examples how we could modify FE-Rendering (of the RTE)
by defining some Page-TS-Config ! I didn't get this to work yesterday at 1 o'clock in the
morning :) :)




Additional:
-----------------
* In the bugtracker you also noted that the evaluation of the "id" when in BE mode is
not very good. Have a look at the method "evalID" in my patch - i think it works in
most of the cases were an id is "supplied" (you do not have IDs in the extension manager
for example - which also is a be module)

* As the caching and re-matching of TS-Config is a little more complex than the currently
implemented version. And this is done on 3 places in the core:
- t3lib_befunc->getPagesTSconfig
- t3lib_userauthgroup->fetchGroupData
- tslib_fe->getPagesTSconfig
I opt for putting this method into a separate class "t3lib_tsparser_tsconfig" by extending
"t3lib_tsparser" we could probably just "glue" it into the "t3lib_tsparser" file but I see
no sense in making each file that bloated. Let's rather have some small pieces one can put
together. There is no need for TS-Config-parsing to get loaded when only TypoScript parsing
shall get done. Got my point ? (*** See PS ***)


* I made the "usage" of TS-Config conditions configurable via Install-Tool.
I think we should not put in a feature which slows down the BE that much without allowing
the Admin to especially enable this feature (As I wrote in my RFC i required TS-Config
conditions only once since some years - so rather a special case)


BTW: Oliver: If you like you could send a mail to my address containing your office or mobile
phone number and I will ring you on Monday to have a short talk about how we proceed with
this case and the IRRE localization. It seems we seldomly meet in skype.


greets,
Bernhard