generic filebrowser/uploader as core feature?

[manu]

While completing the imageUpload feature in tinymce4 I missed a generic uploader core feature/class. IMHO the standard file browser is close to core function but its classes arent versatile enough for generic use. I'm unsure where to draw the line between core and plugin. All the read/write properties are specified in the filebrowser plugin also..
I would welcome a discussion on how to move these classes into core and open for generic use in the near/far future.
regards
manu

[cmb]

See also http://sourceforge.net/p/cmsimplexh/fea ... quests/27/.

I would welcome a discussion on how to move these classes into core and open for generic use in the near/far future.

Personally, I'd like the idea of having an upload class in the core very much. File upload is rather easy to do with plain PHP, but there are pitfalls, and anyway some convenience is always welcome, particular with regard to the related settings and paths of CMSimple_XH.

First and foremost, I would like to have an upload model class in the core, which doesn't deal with any superglobals, but rather gets the user input from outside ("dependency injection"). The responsibilities of the class would be creating (resp. uploading), renaming and deleting files and folders in userfiles. Some (internal) helpers seem to be appropriate also, such as getting a new filename, checking for allowed filename extensions, and maybe more.

Basically this functionality is already there in Filebrowser_Controller, but I'd like to move it into a real model class.

[manu]

Oh yes indeed. Long live MVC.

[manu]

Christoph, could you describe your idea about "dependency injection" for the upload model class a bit more concrete? A core interface and remote classes in plugins?

[cmb]

Christoph, could you describe your idea about "dependency injection" for the upload model class a bit more concrete? A core interface and remote classes in plugins?

My idea was rather very simplistic for now. See, for instance, Filebrowser_Controller::createFolder(). The method directly accesses $_POST['createFolder'], what is a no-go, IMHO, because every client would have to make sure that this very key is set in $_POST. If we'd like (or have) to change the name of the key later (say, to filebrowser_foldername), any client using this method would (silently) fail. It would be better to pass the folder name as argument to the method.

Using $this->browseBase, $this->currentDirectory and $this->view might also not be optimal, but I'm not sure here. Frankly, I can't really wrap my head around the loads of properties of Filebrowser_Controller. However, I'm quite sure that it would be beneficial to restrict the access to these properties (e.g. require to pass the basic ones when constructing a new class instance, and maybe to allow to change a few of them later via public setter methods, but in any way to make the properties private). Otherwise the client has a lot of flexibility, but easily might mess up, and maybe even worse, would lock us to a particular implementation.

TL;DR: I'd prefer to have a clearly defined API (i.e. public methods; I'm not against using magic getters and setters, generally), instead of allowing access to implementation details. The latter is a relict of PHP 4 (which didn't offer private and protected properties/methods), but is moot as of PHP 5.