Silverstripe-framework: RFC: Create module silverstripe-assets

[sminnee]

Create new silverstripe/silverstripe-assets module with the asset code. Use git filter-branch to preserve a filtered history (https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/)

(This module can be renamed to silverstripe/assets once we are running modules in the vendor folder.)

Include at a minimum the following code:

• File
• Folder
• AssetAdmin
• DBFile
• Asset backend
• UploadField
• Image
• Image manipulation

---

_Original text_

Right now the underlying API for managing files is part of framework, but the UI is separate. This isn't a good long-term approach.

The new SS4 UI is being developed in https://github.com/silverstripe/silverstripe-asset-admin/

I see there as being two major options:

• Move back-end code into https://github.com/silverstripe/silverstripe-asset-admin/ and rename it to https://github.com/silverstripe/silverstripe-assets/
• Create an additional module, https://github.com/silverstripe/silverstripe-assets/, that has no UI

In my view, it would be cleaner to have a single module, but having separate assets and asset-admin modules has a couple of advantages:

• You can build custom asset UIs without leaving the default UI in your project
• It will be easier to preserve the history of the relevant classes

Although the SS3 file system had no versioning, I think it's okay to make silverstripe/versioning a requirement of silverstripe/assets, as to make versioning optional will introduce a number of parallel code paths that would be likely to increase the number of bugs.

[mikenz]

I have no strong argument either way.

I would prefer a single module, I don't see me needing to customize the UI and the non UI parts independently - I'd most likely be extending classes from both at the same time.

[anselmdk]

I feel it'd be overcomplicating things to have both an asset-admin and an assets module.
Thumbs up for moving asset code out of framework and merging it with asset-admin.

[kinglozzer]

Current status quo is that assets are included with framework, but asset admin isn’t, so I’d vote for two separate modules unless it would be a silly amount of work to split the admin interface out. I don’t feel too strongly about that, but it’s my preference.

[wilr]

My preference would be to move back-end code into https://github.com/silverstripe/silverstripe-asset-admin/ and rename it to https://github.com/silverstripe/silverstripe-assets/. I think it would be safe to assume if you're dealing with 'File' and 'Image' objects (say front end upload form) then some sort of CMS interface would be good.

As long as silverstripe-assets doesn't have a dependancy on CMS. Currently using silverstripe as a backend for a mobile app, users upload images (Image object) but there is no need to have Pages / other CMS functionality.

[tractorcow]

Given that asset-admin is already a module, and we have multiple competing asset admins (e.g. kickassets) I feel that separating the filesystem (very core and fundamental) to the asset admin (something that users might be more inclined to change) makes sense.

I would prefer to call the module silverstripe-filesystem :D

I feel differently in the case of assets as I do to versioned and changesets (re my comment on https://github.com/silverstripe/silverstripe-framework/issues/5288#issuecomment-209135134) as I feel that filesystem is a more fundamental component of framework to versioning, and fundamental components should be small and easily includable.

[sminnee]

Note that I would probably make the composer package name silverstripe/silverstripe-assets instead of silverstripe/assets, because otherwise the current module loader will try and load it into the assets/ folder. This restriction can be lifted once modules are placed in vendor/ like regular composer packages.

I'm not sure about the name of filesystem. If that was the language we wanted to go with, why isn't it called FilesystemAdmin? It feels like an arbitrary change and consistency seems better. If there is a logical breakdown of why some parts should be called filesystem and why some parts should be called assets, it would be good to hear the rationale.

Splitting a UI and a data model across 2 modules makes feels like an anti-pattern, as I'd expect there to be reasonably close coupling between the two. If support for multiple UIs was a strong use-case, it might be justified, but frankly if we had de-monolithicised assets before kickassets was built, it wouldn't surprise me if modules like that were better built as forks of silverstripe/assets rather than plugins to the existing backend.

One question is whether the DBFile portion of things should be separated from the File & Folder portion, as this would let people create asset modules that have different organisational paradigms (e.g. store assets in multiple folders, more like a tagging system).

[tractorcow]

yeah but then we have 'silverstripe' in a folder name. 💃

We've already been using "Filesystem" for the namespace, which is why I suggested the name, if you wanted to have a per-module namespace.

I don't feel strongly on splitting the module, but it is a preference if I had to choose.

[tractorcow]

One question is whether the DBFile portion of things should be separated from the File & Folder portion, as this would let people create asset modules that have different organisational paradigms (e.g. store assets in multiple folders, more like a tagging system).

Probably not, since they both implement the same interfaces, but you could still extend organisation by new classes that implement those interfaces rather than replacing File.

[dhensby]

:+1:

[sminnee]

VOTE: assets module containing both asset-admin and the backend-classes

Please use 👍 and 👎 on this comment to vote for this.

[sminnee]

VOTE: separate asset-admin module and assets-modules

Please use 👍 and 👎 on this comment to vote for this.

[sminnee]

@silverstripe/core-team I've put two separate voting comments for the most contentious issue of this RFC.

[tractorcow]

Thanks. :D

[chillu]

Don't forget to update docs which explain which modules are considered "SS core" - for example the second paragraph in https://github.com/silverstripe/silverstripe-framework/blob/master/docs/en/05_Contributing/01_Code.md

[chillu]

On a related note: I've just taken the last step required to split out AssetAdmin from the cms module, which is removing the old AssetAdmin UI: https://github.com/silverstripe/silverstripe-cms/pull/1590. It was temporarily co-hosted on admin/old-assets while we were building out new functionality.

[tractorcow]

Split out assets library.

PR at https://github.com/silverstripe/silverstripe-framework/pull/6723

Library at https://github.com/silverstripe/silverstripe-assets