Forum OpenACS Development: new attachments package

Hi,

I'd like your input on a new attachments package I've started
working on. Attachments are needed in many applications
e.g. forums, calendar, etc., but we don't want applications
to have to know about the internals of file-storage or the
CR. The attachments package, an acs_service, will be closely
integrated with the file-storage package and provide a simple
API to whichever application wants attachments. The
applications themselves will be "loosely coupled" to the
attachments package so that if you don't have, or don't want,
attachments functionality, the application will work as if
attachments never existed.

Why not just extend the current file-storage API to handle
attachments better? The reason is that we want the
attachments package to be a singleton that is re-mounted
under an application. We do this so that 1. we can use
generic URLs between the application and the attachments
package mounted under it. Also, this should also give us
nicer breadcrumbs. 2. file-storage is being used as the
backend datastore but this may change in the future.

The general idea is that the attachments datamodel will have
two main tables. The first will map the application's
package_id to one and only one package_id of a file-storage
instance. This mapping may be set automatically, if possible,
or through an admin UI. The second table, will map
file-storage objects to generic objects from the application.

Comments?

Hi Arjun,

I don't think its needs to be mounted.  I think a good set of tcl API and DB API will be good.  Some tcl API is to make make a fragment of the form much like GC.  Also it would also be good to bind the content_item to an object_id rather than package_id.  For example the one that I made in the ticket tracker lite.  For each ticket (an object) I bind many attachments to a ticket.  The way I did it was very simple I just pointed cr_items.parent_id to the ticket_id.  No more mapping tables.

I have given Vinod the code not sure it it made to the OACS code tree.  So I guess that attachment package should make it very easy to bind binary files to objects (e.g. ticket, bboard post, news items, etc.)

Arjun, I am using your general images module on 3.2.5 and think its great! For the general attachments module it would be great if you could choose what kind of attachment you're uploading... If you're uploading an image the functionality to automatically resize an image to x y-sized images would be valuable. On the other hand it would be nice to choose whether you're uploading to file-storage or db. But CR already has this functionality...

Hi,

Dave is correct that we should move the HTML stuff away from the code.

As for the general attachment packages.  My comment is to have it as a developer friendly service package.  Here is how it may go.

Develop a service based package that is a singleton.  Create tcl API for it to retrieve data, 1 page for posting form data and index.vuh to get the content out.

Lets take the ticket tracker example.  For example on the ticket page you would like to attach files to the ticket.  Here are the steps that will involve the the generel attachment package.

Attach a file.

1. Developer makes a multipart form that will post the the general-attachemnts file-upload.tcl passing the file input type and the object_id of the parent item.  In this case the object_id of the ticket.  The developer may also make this own file-upload.tcl if he/she wishes more cutomization.

2. file-upload.tcl takes in the the file, creates the new cr_items if its a new file, creates a new revision, relates the cr_items.parent_id to the passed object_id.

Attachment Download

1. Ticket page calls general-attachment::get_attachments tcl API passing the object_id of the ticket.  This returns a list of revision_ids.

2. Ticket page creates hrefs to /general-attachment/download/[file name]?revision_id=[revision_id].

Delete Attachments.

1. Ticket page makes hrefs to /general-attachment/file-delete?item_id=[item_id].

2. file-delete deletes the item_id passed to it.

All of the above just make use of the CR api but it makes is very easy for developers to make attachment capability to any packages.

What do you guys think?  The ticket tracker list attach file functions similar to this way.  But Arjun is correct to make a generic general attachment package that way we have a single API to use.

#2 ... general comments should be rewritten/tweaked for this reason alone.  This abuse of ACS Messages needs to stop! :)

<blockquote> Help me with the concepts here: What is the advantage (or maybe
distinction) of a multi-mounted singleton vs. a singly-mounted
singleton?
</blockquote>

The advantages are cleaner breadcrumb generation and better site
organization. Although both attachments and GC are global "services",
attachments maps one application instance (e.g. a forums instance) to
one FS root folder so its "file-picking" UI is scoped by default to
the package_id of its parent node. e.g. If I wanted to attach a file
to a post in "alumni forums", attachments would only show me files
in the "alumni fs" instance to pick from.

This organization makes for cleaner application code. And all the
breadcrumbs and other site-node-based stuff, important to dotlrn,
would be complicated if attachments wasn't mounted under applications.

<blockquote> Why wouldn't it make sense to make the attachments package be a
regular application (vs. a singleton).
</blockquote>

Attachments is actually an apm_application (not an acs_service) so
that it can be instantiated once, but it's a singleton to prevent it
from being re-instantiated from the site-map. There's no need to
have multiple instances of attachments.

<blockquote> Can/could a redone GC package use the attachments package as a service?
</blockquote>

Maybe, but I haven't looked at the GC code to see what this would involve.

Take a look at the code. It's  now in the oacs CVS tree.

stephen,

you can still upload a new file or create a new url and use it as an attachment. if you upload a new file as an attachment to the "Alumni Forum" it will upload the file to the "Alumni File Storage" and use it as the attachment. remember that we are using file-storage as the data store for attachments. check it out for yourself, it works pretty well.

yon.