Forum OpenACS Development: Re: Photo-Album Includelet for Xowiki

Collapse
Posted by Richard Hamilton on
Photo Album objects seem to be associated with three content_types. However, curiously the package names associated with these are not all 'photo_album' as might have been expected:

The basic photo-album package registers the following:

object_type              package_name
~~~~~~~~            ~~~~~~~~~
pa_album                  pa_album
pa_photo                  pa_photo

A comment in the code mentions that the former content_type pa_image has been deprecated in favour of using the general content repository content_type 'image'. The 'image' type is therefore not in fact registered by the photo-album package and its package name is also 'image':

object_type              package_name
~~~~~~~~            ~~~~~~~~~~~~
image                        image

A later addition intended to act as a simple clipboard for creating presentations adds this:

object_type              package_name
~~~~~~~~            ~~~~~~~~~~~~
photo_collection        photo_album

I am not entirely sure what the intended standard is with respect to setting the package_name attribute, but certainly where a package owns a content type I would have expected the package_name attribute to reflect that relationship.

Nevertheless, pa_album and pa_photo as content_types are used in a way analogous to the new ::xowiki::Folder for grouping content items together. A pa_album contains pa_photos, and a pa_photo always contains three cr_items which point to revisions of the originally uploaded image, the autogenerated 'view' image, and the autogenerated thumbnail image.

-4
|
-100 content_folder - Name, pages
|
|
979 content_folder - Name, photo-album_966
|
1040 pa_album - Name, myAlbum
|
1268 pa_photo - Name, file01.jpg
|
|___1270 view
|
|___1271 base
|
|___1272 thumbnail

When I start working on an includelet to provide an alternative to photo-album within xowiki, do you think it will be reasonable to create an ::xowiki::Folder for each image uploaded, and have the content repository autogenerate the thumnail and the view image for each uploaded image according to parameters passed in the includelet declaration?

i.e.

{{xophoto_album -autogenerate {view width "" thumb width ""} }}

(NB. This assumes aspect ratio to be preserved)

There seems to be a good case for generating thumbnails and intermediate 'view' sized images on the server in order to reduce the bandwidth requirements for the intended YUI based photo-display carousel. Otherwise, the server would have to send all the full sized images across to the browser and the browser would have to do the re-sizing.

My plan is to present an initial set of thumbnails in a carousel with a single view image on display (similar to existing photo-album but using asynchronous requests instead of refreshing the whole page). User action would then trigger additional thumbnails and view images to be retrieved from the server as required, as per this YUI2 demo:

http://developer.yahoo.com/yui/examples/carousel/csl_dynload2.html

The base image display would be a separate display mode which becomes a simple slideshow of full sized images (as per the existing {{yui-carousel}} includelet), with each being loaded asynchronously 'under the fold' and being displayed when ready.

At this stage I would be grateful for comments and suggestions.

Regards
Richard