Forum OpenACS Development: Adding categories support to file-storage

We want to use file-storage as the basis of a simple knowledge base, and for that I want to integrate categories with file-storage (most documents fit in more than one category, folders are just not flexible enough).

Together with the webdav support this then makes for a simple yet effective docmgr. In the forums I read that this was also more or less on the roadmap. After mailing with Dave he suggested to ask around on the forums if anyone is also working on this or interested.

My plan is to:
- add an admin page to allow for tree mapping [DONE] (that was the easy part
- in the browse interface create two tabs
  - 'browse by folder'
  - 'browse by category'
- at the properties page for a file add a category selection box.

Perhaps we can even expose the 'browse by category' functionality through the webdav interface (sort of virtual folders - from what I've seen from the current implementation the 'folders' are currently also essentially mappings to a query). Though I haven't looked in depth at this, any pointers are welcome.

While poking around in file-storage (HEAD version) I also noticed something which seemed to me a bit of an inconsistency.

When you give a file a title when uploading, the link in the folder listing refers to the title instead of to the actual filename, and you can't download it. This seems to be so because the name of the actual object has been set equal to the 'title' property and the object name is used for constructing the url. The CR knows the object by its actual filename though.

I've now changed it to always use the 'file_upload_name' (in file-chunk-*.xql) when constructing the url - this works, but would it not make more sense to always use the actual filename as the object name, use that throughout the whole interface as its primary name and consider the title just a property (if its existance even makes sense at all)? Or am I missing something here?

Rgds,
Jeroen

Ok, I've done some more code-digging and it seems there's indeed an unmerged patch.

If you look at file-storage-views-create, the view fs_objects, then you see that fs_objects.name (which is used to construct the urls) is a coalesc of cr_items.name or cr_items.label. In 5.1 its just cr_items.name.

I've made some changes so that:

* fs_objects.name==cr_items.name==file_upload_name
* file_upload_name is removed from fs_objects (its redundant?)
* the cr_revisions.title attribute is added to fs_objects as 'label'
* folder-chunk uses the new fs_objects.label attribute as a label if it is not equal to fs_objects.name, displaying it
  below the actual filename.

This way the label ('title') becomes sort of an optional one-line description for the file and in that context the 'artifact' becomes something that actually makes sense.

Do I have to open a bug for this and then submit a patch on this bug?

Another thing, when trying to dl a file from file-storage (head version) I get the following error

Too many positional parameters specified
    while executing
"content::item::get_live_revision__arg_parser"
    (procedure "item::get_live_revision" line 1)
    invoked from within
"item::get_live_revision $item_id"
    (procedure "content::init" line 44)

If I explicitly pass a revision_id in the url it goes OK (because get_live_revision is not called). It's probably something small, however, I do not fully understand the error message. I.e. get_live_revision takes exactly one parameter (item_id), it gets exactly one value (item_id), ... what's the problem? In what sense are there 'too many positional parameters'?

Can someone shed some light on that for me? Thanks in advance.

Rgds,
Jeroen