Forum OpenACS Development: new attachments package

Collapse
Posted by Arjun Sanyal on
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?

Collapse
Posted by Roger Williams on
I thought that the General Comments package can be used to attach attachments (sorry!). I know that GC is not hooked into all of the applications that it should, but this seems to already have the desired (user) functionality. On our system, GC provides the following functions:

Actions

Attach a file or picture
Attach a web link

It also (claims to) keep revisions, so I would guess it is hooked into CR already.

Maybe we should work to hook it into all of the existing packages. Just a suggestion.

Regards..

Collapse
Posted by Jun Yamog on
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.)

Collapse
Posted by Vinod Kurup on
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.)

Yup, I committed this to the devel branch a while ago, but thanks for reminding me, because I had forgotten to commit the (very simple) upgrade script until now. People should check out Jun's new version of ticket-tracker-lite because the interface is much cleaner than the original version.

Collapse
Posted by David Kuczek on
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...
Collapse
Posted by Dave Bauer on
Jun,

I think we want to move away from having tcl procs generating HTML to pass around. The service contracts will provide the information to the packages so they can incorporate it into their templates.

I was thinking of a more general version of this idea. It would allow you to relate any content item to any other content item. I was planning on using acs-rels to create different relationship types. So one type might be a related link to another page inside the site. Or is could be an image link. We ould just store the content repository item_id or revision_id of each related item and use a service-contract to ask the owning package for the items' detail information.

I have to think about this some more, but it seemed related to this attachment package.

Collapse
Posted by Jun Yamog on
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.

Collapse
Posted by Arjun Sanyal on
Roger: general-comments looks useful, but it's
unsuitable for what we want to do for a couple of
reasons:

1. general-comments is a singleton package mounted at
one location in the site-map, not multi-mounted.

2. general-comments is based on acs_messages as its
datastore. We want to use file-storage as the datastore
for attchments so that it's integrated the rest of
file-storage.

Jun: We need the package to be multi-mountable since we
want to provide a nice, scoped "file picking" interface
from the file-storage instance that's mapped to
it. That's really the main idea: integration with a
file-storage instance. A purely CR-based attchments
package won't fit our requirements.

David: You must have me mistaken for somebody else
since I didn't write any publicly available ACS 3 code
:) I'm not a CR expert, but it seems that the image
manipulation stuff is better implimented in the CR
itself. I know there is some image specific stuff in
there already.

Collapse
Posted by Don Baccus on
#2 ... general comments should be rewritten/tweaked for this reason alone.  This abuse of ACS Messages needs to stop! :)
Collapse
Posted by Roger Williams on
Help me with the concepts here:

What is the advantage (or maybe distinction) of a multi-mounted singleton vs. a singly-mounted singleton?

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

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

TIA.

Regards..

Collapse
Posted by Arjun Sanyal on
<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.

Collapse
Posted by Stephen . on
This doesn't sound like *attachments*:

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 is *linking* to pre-existing stuff. I can still attach a file from my hard drive, right? How does this work? Would I still get a list of files people had already attached to pick from?

Collapse
Posted by Yonatan Feldman on
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.