Small thingies...

[Martimiz]

Hi Aaron,
Me again :) Some small thingies:

1. add_remove_links (config) doesn't seem to do anything?
2. delete adds an <input class="input-deleted-file" but remove (unattach) does no such thing. Is that by design or would it be an idea to add it?

Thanks again, Martine

[unclecheese]

Hi, Martimiz,

1. add_remove_links shouldn't do anything. I'll remove that from the API.

2. That's by design. When the form field saves, it erases the relationship and rebuilds it using all the IDs in the request. So if one is missing, naturally, it will be removed, by virtue of not being included in that list. Deletion is a bit different, because you actually have to carry out a separate action to modify the filesystem.

[Martimiz]

I understand - although I never would have thought that adding/removing a item to/from a many/has_many relation in the CMS would by default mean rebuilding the whole lot from scratch...

Isn't that resource intensive? I'm asking that because I'm considering using your great module in a more complex app in the frontend, where I have the freedom to do whatever I want :)

So there are other things I'm musing about...

1. Supporting an onSuccess callback to attach the image to the page on upload, so I won't end up with a bunch of uploaded images that aren't attached to any page because the user forgot to save...
2. Adding optional extra settings to each uploadfield, like for instance a category...

But maybe that isn't at all the way you'd like to go with this, I'd fully understand :)

[unclecheese]

Good, stuff, Martine!

Don't worry about the performance hit of how it is saved. That's the standard way to save a plural relationship in SilverStripe and just about any other framework. Specifically, you use setByIDList(), and it just wipes the slate clean and rebuilds it. You'll find it in CheckboxSetField, ListboxField, GridField, etc..

I'm supportive of the onSuccess callback, allowing the user to implement the functionality you're suggesting, but I'm not a fan of adding an API to autosave the record. My goal was to deliver a consistent user experience with this module, and one of the issues with UploadField is that it's never clear when the user needs to save. For instance, uploading to UploadField requires a save, but deleting and detaching do not. With dropzone, there are no client-side mutations. Everything requires a form submission, and I quite like that.

For #2, we have the foundation for that with the addParam() method, allowing you to inject arbitrary formdata into the upload request (e.g. SecurityID), but we would need to take it a step further to give you do custom saving. So how about:

FileAttachmentField::create('Test')
    ->onAfterUpload(function ($file) {
        $file->Category = 'foo';
        $file->write();
    });

[Martimiz]

Thanks Aaron,
About the way relations are saved - I just never knew that, thanks for clearing that up for me!

add_remove_links
That looks like a css issue: when set to true it still adds a 'cancel upload' / 'remove file' link by JavaScript - it just isn't visible because of list height restrictions. I noticed this because I was tweaking the css to allow for the display of custom input fields: the way it is set up now it doesn't let you insert an extra span (firefox/mac). Btw: would you be interested in that slight css/template rebuild once it's ready and tested?

autosave...
I totally agree on not adding an API for that, but an onSuccess/onFailure javascript callback make it easy to implement one, if one wanted to :)

Custom saving
Your suggestion for this looks like a good one :) but it seems to assume that the category is known in advance. I would like the user to be able to set a category for the image. This would probably exceed the scope of your module, but some slight changes in the module might make it possible:

• js onSuccess callback - again :)
• ImageID available/accessible after upload

This way you can:

1. inject custom elements (fields/actions) after upload
2. invoke Ajax to update the file and reload the preview from (custom) template

I hope you don't find all these suggestions annoying, since maybe I'm pushing too much in the direction of my special purposes :) but I'm trying to think of ways to not touch the integrity of the module, just have it that bit more extendible...

Thanks heaps anyway :)

Martine

[Martimiz]

Oh and one more thing - are you (possibly optionally eventually hopefully pretty please) thinking on making the attachments sortable?

[Martimiz]

Hi Aaron,
Things became a bit complex between your module and my app, and I get that I was obviously asking too much. So I went and started from scratch with dropzonejs, using multiple dropzones. That is now working nicely. But I'm still definitely going to use your module in the cms in the future! So thanks a lot for your efforts and explanations, greatly appreciated,
Martine