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

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

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

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.

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.

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 (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.

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.

{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

I was also thinking about implementing something like an xowiki-based photo album application, but did not have the time yet (and probably will not in the near future).

However I want to share some thoughts, i.e. what my approach would maybe look like:

1) Using XoWiki-Folders (i.e. FormPages based on the folder.form) as albums. (alternatively, define a new form album.form similar to the folder.form)
2) Using the page_order field to define the order among the photos in the album.
3) Optionally defining an {{albums}} includelet, which can be used on the wiki startpage to display the subfolders (i.e. albums) in a special way (teaser image,...)
3) Defining a special index page for the "album folders", which holds another new includelet "grid-view", which displays the folder's photos as "thumbnails" in a typical "gallery style".
4) Using yui-carousel for the "sideshow" mode of the album.

In fact, I think it would be great to focus on the possibility to create albums, slideshows, etc. for ANY type of xowiki page (not only images). For example, if you allow not only images, but also pages to be used by the "slideshow" includelet, this would be super flexible (e.g. the user could add "separator pages" for each island in a sailing trip album).

Please note, that many of the features mentioned above are still under development, which means one would have to digg into the xowiki code, maybe enable experimental features like the Menubar, etc...

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?

Regards
Richard

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

Regards
Richard

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.

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.

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

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

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.