[TYPO3-mvc] Using repositories in eID script

[Claus Due]

> Neither me nor my college really understand your text :-/
> We have only have one rootlevel TS template on our root page. This TS template includes all other (file based) TS.

This is exactly what I meant - and looks like this is already perfect.

> My loadTS function is still needed to initial load TS, correct? If so, is it enough just to generate it?

There is some TCA-related loading going on (see Frank's example from earlier) so that may be something you need to manually load when working in an eID. In Frank's example it is loaded into $GLOBALS['TSFE'] so I assume that does not happen automatically.

I think Frank's example is a good way to approach things. Either that or use a special typeNum/format such as json (sorry I can't point you directly to the docs about this, but it involves setting some TypoScript which will execute an Extbase plugin but without the page design, allowing you to output JSON for example.

>> syslog(LOG_ERR, Tx_Extbase_Utility_Debugger::var_dump($var, NULL, 10, TRUE, FALSE, TRUE));
>> 
>> That will place the debug info in your system's error log (and on a Mac, make it inspectable through the Console).
> 
> t3lib_div::sysLog()? What is the magic here? the LOG_ERR constant oder the Tx_Extbase_Utility_Debugger::var_dump parameters?

The "syslog" function is not the t3lib_div one but the native PHP syslogging command. Instead of logging to TYPO3 it does raw logging using system calls, which will not fill up your database. But of course you can use t3lib_div::sysLog (or devLog) instead if you prefer.

The benefit of using the system log is that you can "tail" it from a terminal. This is one of my preferred ways to debug systems that are otherwise close to impossible to debug - and Scheduler tasks is a great example of such a system because it internally has to catch Exceptions that are thrown and will provide no output whatsoever apart from logs.

Another part of the trick above is that the Extbase debugger is used; it will protect against outputting infinite recursion which is impossible for var_dump and var_export to handle. So, in order to debug Extbase objects which have dependency injection with a very high likelyhood of recursion - always use the Extbase debugger. The arguments I used above will ensure plaintext output with a fair degree of detail. If you have size issues limit the "10" number (which is the max nesting level to be included) to something much less.

The blank screen you mention is in almost all cases caused by trying to use var_dump/var_export on a recursive object. Using the debugger completely solves that problem - it should tell you more about the problem you are experiencing.

> Felix Oertel told us to throw exceptions but I never found out how to display these.

Since Exceptions are thrown as errors you will only see them the TYPO3 error log if they happen in a Scheduler task. The reason for this is that the Scheduler catches Exceptions and does not exit the CLI job with a non-zero exit code indicating an error - so you can only rely on the internals of TYPO3 and tricks such as the above syslog dumping (or hours of fighting with xdebug) for debugging. But generally speaking Exceptions are absolutely a nice way to know exactly what goes wrong (but remember that it depends on the "displayErrors" setting in TYPO3 install tool how much detail you'll get).

We kind of moved off topic now but perhaps you find this useful :)

Cheers,
Claus