[TYPO3-workspace] 2 workspace articles of interest

[Philipp Gampe]

On Fri, 25 June 2010 11:48:11 +0200, Ingo Renner wrote:

> I think Philipp wasn't talking about extracting WS stuff from core, but
> rather adding a file handling layer to the core to allow WS to version
> files too...

Yes, because IMHO this is the only way to implement a clean way to handle 
file versions.

Definition:
* file handling: everything related to fileadmin; typo3temp, etc. are 
excluded

This are the needs:
* a clean wrapping API, with fallback, e.g. no version -> use default
* the possibility to extent file handling by own file handling plugins, 
e.g. a cloud service
* editors should see not difference to the traditional way

What I have in mind:
* plugins can register themselves to a file handler array
* file handling is based on files and folders, it is up to the plugin to 
translate any structure into a tree (UNIX style) file system
* there will be a default plugin which does what is currently supported 
by TYPO3
* reuse the mountpoint concept: mount points are always related to a 
single file handler; if you want to have more then one file handler, you 
have to set up additional mount points


File handlers:
* need to provide an array, including which functions are available
* need to provide functions to work on files, that could be:
** listFolder($folder), e.g. listFolder('fileadmin/myFolder') which 
returns an array with all files
** getFileContent($file)
** getFileLink($file), returns the internal link (e.g. for RTE)
** getFileURL($file), return the URL for direct output, this could be 
handled by linkhandler as well (see below)
** showVersions($file/folder)
** getPermissions($file/folder), Unix style permissions ... those do not 
need to be static, but could get generated on runtime, resulting from a 
fancy acl
** etc.
* all functions are defined the the TYPO3 API, but plugins don't have to 
implement them; that means, if a plugin does not support versioning, it 
will tell about it 
* a few functions will be required, others, especially writing, creating 
new stuff will be optional
* each file handler will have a unique prefix, which is also its "root" 
path; so it will always be myfilehandler/something

Mountpoints & BE:
* have a path, a name and a file handler associated, additionally, there 
might be additional fields depending on the file handler (username, 
password, URL, whatever)
* work as usual
* the folder tree is represented as usual, with the new ExtJS version, we 
might hide all not available icons in the specific tree (e.g. no rename 
if no write)

Workflow:
* if we select add file to a content element, the file handler hast two 
options:
either it returns the URL to the file, or it returns a linkhandler link 
starting with keyword:
* each extension has to make sure it registers a linkhandler if it needs 
one, I would recommend to use the extension key (same as with prefix path)

The prefix path is necessary to support older extensions which don't know 
about the new stuff and which can work with a simple folder then. 
Moreover it adds the possibility to work with mountpoints, without 
knowing that they exists. 
The file handler would properly register an instance of themselves to the 
file handler array


What needs to be done next:
* agreement on what functions should be available for implementation
* implement the API
* implement old style fileadmin mount points as default file handler
* replace all places in core with new functions, wherever necessary 
(should not be too many)

The advantages of a file handling API would be:
* the code is no longer splitted up to many places
* the API implements fall troughs if a version does not exist, so 
versions/ workspaces are supported
* the file handling can be extended by external services, 
* or a more advanced file handling solution could be used (think of dam)

Disclaimer: I hope the concept is not too messy and the idea becomes 
clear. I don't know if any of the above makes sence, this is just what 
came to my mind after thinking about it for a while.

I am open for suggestions.

Best regards
Phil