Forum OpenACS Development: Image content type in content repository

Collapse
1: Image content type in content repository
Posted by Dave Bauer on 11/10/03 10:06 PM
It looks like the content repository assumes that "images" will be stored as subtypes of the image content type. What exactly counts as an image is not defined. SVG files can be used to create images, but are XML.

File storage currently stores every file uploaded as a file_storage_object which is a subtype of content_revision.

Is there a signifigance to using hte image content type? It stores the height and width of the image in the images table. I don't see that file storage uses this, but a package that created a compound object type or needed to construct an img html tag would need it. Because images can be stored as a CLOB in the database, no simple operation can get the information after it is uploaded.

So, should file storage switch to storing images as image content type?

This will not affect the user interface of file-storage one bit. It just affects the pl/sql api that creates a new file storage file.

The reason I ran into this was when I converted file-add to use ad_form and tried to use cr_import_content which forces mime types for JPG and GIF into an image content type.

Collapse
2: Re: Image content type in content repository (response to 1)
Posted by Don Baccus on 11/11/03 06:48 PM
I'm not sure, to be honest - file storage is a mess internally.  Maybe cr_import_content shouldn't force the use of an image content type but only do that by default.

Hmmm ... the reason for having the dimensions there is to allow the generation of height and width attributes to IMG tags that reference CR content (this assumes the index.vuh file is working that allows one to access CR content by URL!)

I kinda wonder how useful this is in practice ... usually we just download content, not reference it, certainly that's the file storage paradigm ...

So how about modifying cr_import_content, then, leaving the default behavior unchanged of course?

Collapse
3: Re: Image content type in content repository (response to 1)
Posted by Dave Bauer on 11/11/03 07:48 PM
Right, I am cleaning up file-storage some and this is something I ran into. I think allowing cr_import_content to create images that are not derived from the image content type would be fine. It would keep file-storage working the same as it already is in this aspect.

So i'll add a way to override the default content type setting for images.

Collapse
4: Re: Image content type in content repository (response to 1)
Posted by Dave Bauer on 11/17/03 08:18 PM
Another way to fix this is to reuse the content_type is the item to add a revision to already exists.

This actually makes a little more sense. cr_import_content should not create a revision of a different type than the cr_item specifies.

Collapse
5: Re: Image content type in content repository (response to 4)
Posted by Lars Pind on 11/17/03 08:25 PM
Dave, you might want to proof-read the first paragraph in your last post ... I *think* I get your point :)

/Lars

Collapse
6: Re: Image content type in content repository (response to 1)
Posted by Don Baccus on 11/17/03 08:25 PM
Good point ... yes, that sounds good.
Collapse
7: Re: Image content type in content repository (response to 1)
Posted by Dave Bauer on 11/17/03 08:38 PM
Ah yes. To clarify. To add a resvision to an item that already exists the content type of the existing item should be used.