Forum OpenACS Development: Photo-Album Includelet for Xowiki

I am about to embark on re-working a site I created some years ago which makes extensive use of photos.

Whilst in the past I hacked away at the OpenACS structures and templates, recently I have been using xowiki quite heavily because it allows me to do almost everything I could imagine needing to do without having to hack away at anything!

The golden goose for me therefore would be a photo-album includlet for xowiki so that album viewing and navigation functionality could simply be dropped into an xowiki page and styled.

I have looked at the photo-album ajax interface kindly provided by Solution Grove, and whilst this is an excellent interface for organising photos and controlling the application, its layout and the use of the java 'lightbox' style of display is not appropriate for my objectives.

If anyone knows of a photo-album xowiki includlet project already in progress I would be very grateful to hear about it before I begin! 😊

Failing that, if anyone can give me some tips or suggestions as to the best place to start, which code to target for re-use, and any existing components that would give me a head start, I would be most grateful. Having begun to develop some familiarity with YUI3, it is my intention to incorporate some asynchronous Javascript capability to smooth and speed up the navigation capability (by for example retrieving the mid-sized image asynchronously when the thumbnail is clicked instead of refreshing the whole page, and maybe improving the thumbnail page navigation features as well).

My present assumption is that there is no such thing at present, and I plan to start by analysing the existing xowiki categories includelet in an effort to understand the way it all fits together.

If anyone can guide me I would be most grateful, and if anyone would like to work with me on it, so much the better.

I apologise in advance to Jeff Davis and Gustaf Neuman because I rather suspect that my chances of success without some input from them is minimal!

Many thanks
Richard

Gustaf,

No I was not aware of this, and now that I have had a look at it I am very excited by the possibilities. Thank you.

I have created an experimental page with a single image on it, but have run into a problem:

Error in includelet 'yui-carousel':
::xotcl::__#0G: unable to dispatch method 'pretty_link'
while executing
"$entry pretty_link -download true"
(procedure "render" line 57)
invoked from within
"next"
(procedure "render" line 5)
::xotcl::__#0E ::xowiki::includelet::decoration=portlet->render
invoked from within
"$includelet render"

The url for the page is:
http://dev.oakmasters.com:8000/xowiki/available_includelets

Is this caused by something I have omitted to do?

I have studied your code and am beginning to 'get it', but I am not yet familiar enough with xotcl to know the kind of problems that create method dispatch issues. Is this a problem with the image object or a more fundamental issue? I have found the method in the links-procs.tcl and I am not really sure where to start troubleshooting to work out why this method fails on the image object.

I should mention that before I added an image object to the page, the empty YUI carousel rendered just fine. As soon as I added a child object of type image (as per the includelet code), the pretty_link method choked.

Also, I am concerned that with a very large number of images on many pages, the files may become difficult to manage since there are no folders in an xowiki admin page. I can add categories to organise the photos for display controlled by a menu, but I am concerned about the admin situation.

In the past I have used photo-album to organise images hierarchically in the admin pages and public viewing, and to use the images arbitrarily in other pages by hyperlinking them within the html. Of course this simply causes the browser to grab the image as a seperate request, whereas the yui-carousel includelet is doing all the work on the server. Is there a way to emulate the hierarchical organisation of the photo-album package in xowiki?

If not, could the yui-carousel be populated from the photo-album? Is it be feasible to enable photo-album content items (images) to be allocated to xowiki page objects as additional child objects, without disrupting their existing object relationships within the photo-album application?

Alternatively, is a lightweight {{adp /photo-album/includelet_viewer.adp {album nnnn} }} a realistic possibility for me as a means of ducking the object-tcl challenge for the time being?

Regards and many thanks
Richard

Gustaf,

Thank you, I'll do a cvs update from HEAD to grab the change.

We need around 11 folders with the capability to have up to around 60 images in each folder.

Subfolders are not essential but may be useful later to group images by project within category.

On the subject of sourcing the images from photo-album, I can see what you mean about the navigation issue. The includelet would need to know a lot about the structures within photo-album. Alternatively, photo-album could be coded to export or maintain some kind of trivial structure map for the includelet to refer to. Either way this could be ugly if not done carefully.

As far as the {{adp ..... }} is concerned, I was considering adding specific adp/tcl pairs for image display only, so I would maintain control of the nav links. However I have no sense of how big a job this might be.

I think the simplest option is undoubtedly as you have suggested. How could I improve the organisation of this many files?

Regards
Richard

NOTE:
THe current content repository image type has built in thumbnail and other size handlers similar (but simpler) than photo album.

This works for any image that is stored in the CR with image or image subtype content type.

If you address the image with the image.vuh handler ie: mysite.com/image/${image_id}/${size_name} and the size_name is configured (there is a procedure for this) it will generate the size and link it to the original image on the fly.

I would basically not use Photo album at all, unless you somehow are tied to it.

For new code I would just create a CR folder, or use a existing folder ie, from xowiki, to store the images.

Even if you wanted some sort of "album" functionality, I would recommend implementing that as a plain CR folder, or a subtype of cr_folder, or using some sort of tag or categorization scheme. This would be much easier to use and get the images back out.

I basically took the image upload handling features (except for unzipping) from photo album and added them to the CR, so yes you could adapt photoalbum, and simplify it.

See

ad_proc -private image::get_convert_to_sizes {
} {
   List of sizes to convert an image to. List of maximum width x height.
   @author Dave Bauer (mailto:dave@solutiongrove.com)
   @creation-date 2006-08-27
 
} {
   #TODO make a parameter in content repository
        # avatar size to match gravatar.com
   return [list thumbnail 150x150 view 500x500 avatar 80x80]

Which apparently, I didn't make a parameter yet :)

Quick solution is to just add whatever sizes you want there.

Longer solution is to add the parameter to CR and use that.

Note these are square dimensions b/c it will make either dimension no larger than those sizes which retaining the aspect ratio of the original.

Dave,

Last night I worked through the data model and confirmed that the photo album application does in fact use the CR. The only thing I can see that differs from your suggestion is that albums are of content_type pa_album instead of the more general content_type content_folder.

As the data model is basically sound it seems a shame to discard so much proven code. I think it would be ideal to have the existing code as a means of entering and organising images complete with Ajax ui already built, and be able to export images to an xowiki instance such that the exported images appear as xowiki::File entries. This would preserve the current bulk upload capability whilst allowing images to be used in xowiki.

I have mapped the data structure which I will post below for reference.

Richard

As an experiment last night I tried changing the parent_id of the pa_photo cr_item 1268 from the pa_album 1040 to the ::xowiki::FormPage 989. I adjusted the name field to have the file: prefix and ensured that the content type was image/pjpeg. However, xowiki throws method dispatch errors presumably because the oo inheritance has not been constructed.

I'd like to be able to export images to an xowiki instance by creating a second cr_item for each exported image that is a child of the target xowiki instance. I don't know how to do this?

I don't have any opinions or advice on integrating with xowiki really.

I'd make the parameter a Tcl list, like it is now that's easier to deal with.

You don't even need the { } around the parameter value.

I have an idea for bulk uploads but I never implemented it. Processing a zip file into a bunch of CR objects should be pretty straightforward and might be something reusable.

If this:

{avatar 80,thumbnail 150,view 500}

is looked upon as a string, then it would need parsing to take apart into its elements.

If it's (interpreted as) a tcl list, the items (4) are:
- avatar
- 80,thumbnail
- 150,view
- 500
because a tcl list is delimited by space.

Notice in Dave's function he's actually constructing a list to return. Dave, is there another function that takes this list and does something with it?

If the answer is yes, then having a different form would involve conversion from the list Dave returns, and also conversion to it.

Richard, is what you want for this to be more englishlike and more readable?

-Jim

Before you are wondering, what Michael Aram is talking about: xowiki has several new functionalities, many of those are not committed to the public cvs. One of those are the folder-procs, which provide means for organizing xowiki content in folders. The main reason, why the folder-procs are not in the public cvs is that these contains code, which i am not content with, therefore i was quiet about it. But maybe, i will remove/deactivate these parts and commit to cvs, to make the communication easier. With the folder-procs, one can activate the menu-bar and the folder display.

To see this in action, look at http://alice.wu-wien.ac.at:8000/xowiki/images/carousel-test

The code has as well bulk-upload, etc. I am these weeks very busy (xotcl 2.0, most busy time at the university, new study programs, external evaluations, fighting for budgets, track chair on a large conference, etc.), but maybe i can spend some time in the evening on that.

-gustaf neumann

PS: Richard, you should check from time to time your mailbox.

i have committed the two experimental file menu-procs and folder-procs to cvs. To activate it, set the package parameter MenuBar to 1.

Well that sounds like a list of excellent ideas! I'd love to work towards those goals, and whilst it will take me a little while to become familiar with coding using xotcl, I am more than willing to devote the time to learning how to.

I am not sure what the next step would be, so shall I wait to hear from you or is there something I can be working on?

Regards
Richard

Package_name refers to pl/sql package for the pl/sql procedures associated with that type. On postgresql its the first half of the function names ie: image__new.

If you want the content repository to generate thumbnails, a simple solution is to use the image content type and reference the image urls like so:

mysite.com/image/${image_id}/thumbnail

This will generate the resized image on the first reference and just download the correct size thereafter.

There are also image::* tcl procedures to do this if you want to generate the thumbnails on upload.

So am I correct in thinking that once an image is uploaded, you call:

image::resize [ -item_id item_id ] [ -revision_id revision_id ] [ -size_name size_name ]

and the CR automatically creates the new sizes and stores them as children of the item_id.

To retrieve them you call:

image::get_size_item_id [ -item_id item_id ] [ -size_name size_name ]

specifying the appropriate image size or use the virtual url handler you described.

R.

I have been testing some new display options for the xowiki yui-carousel includelet which makes good use of the content repository image re-sizing features.

Along the way I have been testing performance with quite large numbers of thumbnails, and I happened to notice that the imagemagick default quality for a 90 x 60 .jpg thumbnail results in a 25KB+ image. This is way too big since I can produce a thumbnail visually indistinguishable from it in about 2.5KB using Photoshop.

As a quick and dirty performance improvement I can simply manually re-process the cached thumbnail files, but I thought it might be a useful addition to enable the required default output quality to either be passed in when the procs are called or put in an OpenACS kernel parameter alongside the path to ImageMagick.

Any thoughts?

Regards
Richard

Torben,

Thank you for the reply.

ImageMagick has many command-line parameters and one of them is '-quality'. You pass it a number between 1 and 100 where 1 is poorest and 100 is best. It is supposed to default to the detected quality of the original but I suspect that this is not happening.

My suggestion really is in terms of exposing this option through the OpenACS CR API regardless of the image processor used.

Regards
Richard

OK, here is what I recommend.

Change the return style from image::convert_to_sizes to return something like this:

[list [list thumbnail {-strip -resize 150x150} view {-strip -resize 500x500]]

and fix the callers to intepret the new format. Since this is a private procedure and it is only called in two places, and only one place actually uses the dimensions part of the size specification.