Forum OpenACS Development: Proposal for simplified site-wide image upload

I have written a propsal for a simple site wide image upload feature to replace or complement the current file-storage based solutions.

Its in the XoWiki
https://openacs.org/xowiki/pages/en/site_wide_image_upload_widget

Any comments here or in the wiki are appreciated. Thanks to Don and Gustaf for commenting on the first draft and asking good questions.

Collapse
Posted by Torben Brosten on
I like where this development style is going.

Could an option be to pass a parent_object_id to the widget so that each application can choose the most appropriate parent object_id?

Collapse
Posted by Dave Bauer on
Torben that makes sense, I like it :)

Basically the widget will need to get an object_id to attach to, and it won't know or care which object that is. Hopefully it will be possible to do this in a simple way that can be reused without having to rewrite every form in the toolkit.

Collapse
Posted by Malte Sussdorff on
Not sure how you can tell Xinha to the use the image if the URL of the image contains the item_id of the object the file belongs to (e.g. the question), which will only be created once the question exists which is after the download.

If the item_id is the item_id of the file, then you can use just plain /o access, but this would prevent you from reusing images that have been uploaded to an item (e.g. if 5 images have 12345 as the parent item_id, calling /images/12345/ could result in an UI that shows you all the images stored with 12345).

I definitely like the clipboard idea and it might be easier to come by:

You could upload images, mark them as private (then the parent_id is your user_id), package (then the parent_id is the package_id of the package calling XinHA) or site_wide making it available site wide. The insert image button in Xinha would then look at the clipboard and display all images in the clipboard from which you can choose to upload and insert.

Collapse
Posted by Dave Bauer on
Malte,

Sure using the package_id of the current package works pretty well, and would probably set permissions in a reasonable manner. Or using the subsite_id (or package id of dolrn community, in that case) would also make sense, restricting the image to the subsite it was contributed in.

The clipboard adds additional effort to use the image. In our case we want to mainly support adding the image during authoring of the content, so we definitely want to allow inline uploading.

The image url would just contain the item_id of the image object in the content repository and would not refer to any other objects, so it should be totally generic. Using /o/ makes sense, but we want the URL to _look_ like and image url and contain the filename, so we need a handler that can do that.