[TYPO3-mvc] Using repositories in eID script

[Felix Nagel]

Am 10.10.2012 19:43, schrieb Claus Due:
> 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 was not able to get extbase realize the storagPid when initialized in 
a minimal way, aka without an action (I do not need any FE related 
stuff). Anyway, as this approach does not work I use setPid on my 
objects and this just works nice. I will post an example soon.


> 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.

I already use Tx_Extbase_Utility_Debugger::var_dump but I think I 
remember that I was not able to get t3lib_div::sysLog() work in a 
extbase commandController. I will check this again.

> 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 did not manage to log any thrown exceptions in a extbase scheduler 
task (commandController). It returns an error code (so we have a red 
error warning in scheduler module), but the thrown exception message is 
not logged afaik.
Is there a working example of this (like an extension in TER)?

> We kind of moved off topic now but perhaps you find this useful :)
Of course I do! This stuff definitely needs more documentation :-)

Thanks a lot!

-- 
Regards
Felix Nagel