[TYPO3-dev] Exceptions of LocalDriver in TYPO3 6.2.x and their consequences

[Frank Gerards | FORMER03 GmbH]

Hi Philipp,
thx 4 info - i came across the Exception handling when fetching files and checking permissions.
So, if there is no switch to turn off FAL completely, maybe there ist he will to create a fast-response-task-force
on an upcoming TYPO3 event before christmas ?

Cheers,
Frank

-----Ursprüngliche Nachricht-----
Von: typo3-dev-bounces at lists.typo3.org [mailto:typo3-dev-bounces at lists.typo3.org] Im Auftrag von Philipp Gampe
Gesendet: Donnerstag, 9. Oktober 2014 17:07
An: typo3-dev at lists.typo3.org
Betreff: Re: [TYPO3-dev] Exceptions of LocalDriver in TYPO3 6.2.x and their consequences

Hi Frank,

Frank Gerards | FORMER03 GmbH wrote:

> Is there sth like a joint effort to fix this problems and - more 
> important
> - communicate the handling of FAL resources

It is not even such simple things like a missing file that creates problems all over the place, but also things like offline storages, deleted but referenced storages, etc.

The whole concept is broken here (not FAL, but the frontend using FAL). 
AFAIK there is still not concept/documentation on how the typical usage flow of a frontend call to render a file should look like.
There is not documentation on who calls what at what point and how to react on errors, what to check before calling certain functions - Not to talk about localization.
getXYZ() calls suddenly try to create folders in the middle of the call chain, because the try to fix things they should care about and completely ignore a readonly flag (processing folder creation on getRole).

There is no or little documentation (some PHPdoc, but most are useless) on how certain functions behave (e.g. ignore permissions, delete flags, etc).

There is no documentation on what functions are high level API (e.g. do everything for you; called porcelain commands in git) and what functions are the plumber commands, the kind of comments if you need to do tricky stuff.
There is no (public) concept off what to call in which situations.
There is no concept of what is a working, consistent state of a storage, when it is inconsistent or broken and who and what command are supposed to fix this and everything bring back to a consistent state. Currently it happens sometimes magically and something just not resulting to all sorts of exceptions. Partially exceptions are used as GOTO alternative, a pattern I come across regularly on OOP "experts" (nothing here GOTO main function IS the same is throwing an exception and catching it in the main function just to find out if a record exists or not; exceptions should be for exceptional conditions and not for regular program behavior and expected error conditions).

Because of this, some people - including me - fixed a few fatal errors they came across, but we can do little to mitigate the conceptual problems outlined above.
It is up the the main developers of FAL to provide a documentation on how it
*should* behave, such that others can go ahead and fix bugs based on that.

Best regards
--
Philipp Gampe – PGP-Key 0AD96065 – TYPO3 UG Bonn/Köln Documentation – Active contributor TYPO3 CMS
TYPO3 .... inspiring people to share!

_______________________________________________
TYPO3-dev mailing list
TYPO3-dev at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev