[TYPO3-media] RFC: make use of t3lib_extFileFunctions API in VIDI - func_move

[Ingmar Schlecht]

Hi Fabien,

Am 17.11.11 08:17, schrieb Fabien Udriot:
> Hi,
>
> Here would be the RFC which I would like to have feedback before
> merging: http://review.typo3.org/6704

Benni and me just looked trought it, looks all good (except that we 
wouldn't add the addMoveOfFile() function, lets just remove both 
addCopyOfFile() and addMoveOfFile(), so those actions always work from 
the object you want to move or copy, i.e. only offering moveTo() and 
copyTo()).

I also changed the documentation accordingly:
http://docs.typo3incubator.org/File/_build/html/2-LowLevel/2-copying-and-moving.html

> The concern is about making use of t3lib_extFileFunctions API within
> VIDI. In my eyes, t3lib_extFileFunctions can be seen as a kind of
> wrapper around the FAL API. Consider the func_move function bellow:
>
> http://git.typo3.org/TYPO3v4/Incubator.git?a=blob;f=t3lib/class.t3lib_extfilefunc.php;h=9ccff3215e6e5b3a4c04e5c405ecde80ca228c98;hb=refs/heads/project-fileabstraction#l511
>
>
> Notice the current patch works in term of functionality: I can drag an
> drop files in the VIDI UI and get file moved.

Yep. It does look a bit weird at the moment making use of the "old 
style" extFileFunc API within vidi, but it does get the job done 
including logging and that way we test our backwards compatibility API 
(extFileFunc) at the same time by actually using it.

In a later version of FAL (maybe for 4.8) we can think of adding logging 
possibility to the Storage directly.

The code with such a "new" API could then e.g. look like this:

$storage->setLogging(TRUE);

if ($file) {
     try {
    	 $result = $file->copyTo($folder);
		 // only runs if no exception was thrown?
    	 new t3lib_FlashMessage("Success");
     } catch (Exception $e) {
		 // an error occured
    	 new t3lib_FlashMessage($e->getMessage());
     }

And this would then be exactly how the vidi ExtDirect/File/Actions.php 
would use it. It would then no longer need to use extFileFunc. But for 
the first version, we still go with extFileFunc.

> However, it introduces
> some changes in the API that needs validation. The patch r6704 tries to
> fix different problems:

The changes you made to the API look all useful. Great that you fix it 
in all the layers down to the driver.

> * Folder can be instantiated as File
>
> To explain it, I let take this example:
>
> $object =
> $this->fileFactory->getFileObjectFromCombinedIdentifier($identifier);
>
> Say that $identifier is the identifier of a folder. What should be the
> value of $object in the code above ? Currently, it returns a
> t3lib_file_File object but I am not 100% convinced the result is the one
> expected (even tough a folder can be consider as a file, strictly
> speaking).
>
> I have changed the API towards a NULL value because I need a way to
> distinguish the two different objects (file and folder).
> https://review.typo3.org/#patch,sidebyside,6704,1,t3lib/file/Service/Driver/LocalDriver.php

Very good.

> * I have added addMoveOfFile to be coherent with addCopyOfFile. Can you
> check it and let me know whether it makes sense.
>
> https://review.typo3.org/#patch,sidebyside,6704,1,t3lib/class.t3lib_extfilefunc.php
>
> https://review.typo3.org/#patch,sidebyside,6704,1,t3lib/file/Folder.php

As written above, lets just drop those functions and only work from the 
object you want to move. $file->moveTo($destinationFolder).

> * Besides, I / we are still in the search of a good concept for
> extfilefunc. API is not really nice IMO. Take as example the code on
> this link. I wish we could have a more elegant wrapper. Just collecting
> idea for now...
>
> https://review.typo3.org/#patch,sidebyside,6704,1,typo3/sysext/file/Classes/Service/VidiDragAndDrop.php

See above as well. The more elegant layer (with logging done by the 
Storage) will follow in a later version, after we have the first version 
integrated in the core.

Thanks a lot for your work, it looks really good solid!

cheers
Ingmar