Handling of subobject storage for new items

[gogobd]

Folderish types are designed to be able to contain content. However when you use collective.folderishtypes in Plone and you simply add a folderish item and edit it immediately you will see that all the assets you uploaded through the editor will be stored as siblings of the item you just created. This is due to the fact that the new item does not "exist" yet, that is, before it has been saved once.
That's somewhat surprising and unwanted in our usecase.

• Maybe that issue could be resolved with event subscribers that help to "track" the uploaded items (annotation in the intermediate/temporary/not-persistent parent object?) in order to move them into the type after it has been saved.
• Maybe the right way to fix this is to configure/modify TinyMCE (even if that implies a kind-of dependency)
• Maybe a combination of both?
  It would be great to find a good solution for that.

[agitator]

imho the most sane option would be to create the object first (via minimal addform) then make sure the context for uploading objects is within that object

[gogobd]

That's feasible but my intention was to strive for a generic way of handling this issue that doesn't require modification of other code outside "collective.folderishtypes" to retain modularity.

[djay]

isn't p.a.drafts supposed to solve this? https://github.com/plone/plone.app.drafts

[djay]

@datakurre might be the best person to ask about p.a.drafts or other ways to solve this

[datakurre]

Drafts does not support that ootb. It could, but because of the added complexity community seems chosen path with minimal add form + edit form with real context.

[djay]

so to your knowledge there is no solution to adding images inside a folderish types when adding a page? @datakurre (other than having a central media folder).
I thought at least castlecms solved this right @tkimnguyen ?
I thought i'd covered this in the roadblocks to going folderish way back in 2013 but can't see I had - https://docs.google.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit#

[datakurre]

Early Mosaic had support for images as tiles (in persisten tile data) that worked already on add form.

When CastleCMS was developed, add form as special case everywhere in code scared them and CastleCMS choose to show minimal add form and then show Mosaic editor only on already created page.

[djay]

To be honest a minimal add form seems like a good tradeoff to me. You change cancel button to do a delete. But if p.a.drafts is also very close to a solution why not use to solve this problem?

…

On Tue, 22 May 2018, 3:18 PM Asko Soukka ***@***.***> wrote: Early Mosaic had support for images as tiles (in persisten tile data) that worked already on add form. When CastleCMS was developed, add form as special case everywhere in code scared them and CastleCMS choose to show minimal add form and then show Mosaic editor only on already created page. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACi5KSGn3BQC1Wlffg1OA-EQ_dWclz2ks5t08nNgaJpZM4UCpMl> .

[gogobd]

plone.app.drafts looks like a very good vector! Too bad it works on persisted objects only. I was talking with @jensens and maybe there's a clean way to implement a behavior as an addon that instantly saves a newly generated (folderish) type, then redirects to the edit form.
This could be a stand-alone drop-in add-on.