Task #36800

Streamline Resource object API

Added by Robert Lemke over 9 years ago. Updated about 8 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)
PHP Version:
Has patch:


The API and mechanism for resources is, for some time now, not as intended. What we basically need to achieve is:

  • make sure that identical resources (same sha1) share the same file
  • allow to create multiple combinations of sha1 / file name so that the original file name is preserved even if identical resources are uploaded
  • still make sure that Resource objects with the same combination of sha1 / file name are unique (@identity for $hash and $filename)
  • make sure that if a Resource object is deleted, the related file is deleted as well
  • make sure that a Resource object is removed if it is not used anymore (no relation from another entity exists anymore)

For this to achieve we need to do (among other things) the following:

  • remove the ResourcePointer class and move the getHash() and __toString() method to Resource
  • implement some onDelete event handler for Resource objects which cleans up non-used files
  • fix orphaned entity handling for aggregate members

The last point is especially important as it is an important feature for the overall persistence.


Feature #33587: Automatically remove unused ResourcesNew2012-02-01

Feature #33469: Support for temporary ResourcesRejected2012-01-26


Related issues

Related to TYPO3.Flow - Bug #36717: Remove Identity from ResourceResolvedChristian Müller2012-04-30

Related to TYPO3 Flow Base Distribution - Story #42407: Asset ManagementNew2012-10-26

Related to Base Distribution - Work Package #45003: Media BrowserAcceptedChristian Müller

Blocked by TYPO3.Flow - Bug #36804: Orphaned entities within aggregates are not removedNew2012-05-03


Updated by Adrian Föder over 8 years ago

  • Estimated time set to 0.00 h

above, there are particularly two bullet points I want to comment on:

  • make sure that a Resource object is removed if it is not used anymore (no relation from another entity exists anymore)
  • fix orphaned entity handling for aggregate members

(both the last in each list)

Make sure to not consider resources always bound or related to entities. Especially in light of #33469, "Support for temporary Resources", Resources might also be, for example, temporary generated and minified CSS and JS which even must be published.

So in these cases the surveillance of orphans is even more complicated because lateron it can't be reliably said whether such a resource is still necessary or not.

While thinking about all of this, I saw a lot of "overlap" with the Caching framework. The Caching framework supports tagging, deletion, lifetime, ...

So maybe the Resource framework can joint venture the Caching framework in these regards. I could imagine some kind of a "PublishableFrontend(Interface)" or such, where a Resource is wired to a Cache entry.
Maybe publishing could be a method/feature of the (Cache-)FrontendInterface at all...

//addition: considering the (Cache-)FileBackend, it could carry an additional interface ResourcePublishable, which will result into a symlink created pointing to the cache entry.
Or, there won't be only a Resource object, but a network of a FileResource (being just like the current Resource), and a CacheResource. The fact that a Resource always intrinsically means a present file on disk is probably also unlucky.

Currently the literal identifier of a resource is its sha1 hash. I wanted to create a resource out of a curl-stream (incoming), which was not possible because I didn't know the final hash of course. How could this be achieved?


Updated by Karsten Dambekalns over 8 years ago

  • Status changed from New to Accepted
  • Assignee set to Robert Lemke

Updated by Adrian Föder about 8 years ago

  • Estimated time deleted (0.00 h)

Also available in: Atom PDF