Desired Features#

While reading through this, keep in mind that I use JSPWiki within an intranet, and access is limited to a small number of users collaborating within a project. Here are some things from a high-level that I think would be useful:

1. Ability to delete a single attachment with all of its version history#

This would mean that if I wanted to protect myself from accidental damage, I could have a cron that backed up my repository (including attachments) nightly.

2. Ability to remove an attachment from view #

This might be like doing a cvs remove - version history for the attachment would be preserved, though the attachment would not appear at the bottom of the page. See #4 for how these removed Attachments might be viewed. Personally, for simplicity, I'd probably favor 1 over 2, but I can see how this might be more useful to some folks.

3. Ability to delete one or more versions from an Attachment's version history#

I wouldn't expect an average wiki page to be incredibly large (though YMMV), however that's a different story with attachments. Within our intranet, we attach all sorts of files to pages: powerpoint slides, rose diagrams, distro tarballs, and many other things besides, and some of these files can be rather large. Over time (and after frequeny updates) Attachments end up consuming more and more space.

All of the above Delete operations would be done from the Attachment View page. If the AttachmentManager was configured to provide support functionality and/or the user had proper permissions to do the operations, then there would be a button for deleting the attachment + history (#1), There would be a button to hide the attachment (#2) from the page. It could still be viewed (see #4), but otherwise invisible. Finally, the Attachment View would display a checkbox next to each version, and would allow a user to delete all versions containing a checkmark. There might also be a select all and clear button.

4. Ability to view all attachment info for a page on a separate page. #

Currently, there is something like this: For a page that has attachments, it contains a line of information about each attachment including an image (paperclip), the attachment name, and the size of the attachment. This is Ok, but when I'm viewing the content of a page, I don't particularly care to see this additional information on the page. I tend to find them especially distracting when there are a lot of them. I would prefer to see one paperclip, and maybe something saying how many attachments the page had. That link would take me to a page that would show me a bit more information regarding the attachments - if I cared to look at. At a minimum, I would like to see the following bits of meta-data for:

  • Name
  • Size: (in bytes)
  • Last Modified Date
  • Last Person who modified it (if known)
  • State: Hidden/Viewable (see #3)

The Name of each of these attachments might be selected, to view Attachment-specific information including version history, and perhaps user-supplied meta-data that would be be associated with the attachment. This information currently is displayed using PageInfo. Perhaps there needs to be something else specific for AttachmentInfo.

Features enabled/disabled#

I see a few issues here:

  1. Do admins want to be able to enable/disable the functionality described above? Would this be in addition to or instead of protection through some access privelege?
  2. What if a AttachmentProvider doesn't support functionality a subset of the functionality?

The AttachmentManager seems like a suitable class for determining what features are enabled disabled. I could see it acting as a focal point for determining which attachment-related options are enabled or disabled. One troubling issue is the role access privileges play in making the determination, if any. Where do these features come from:

1. WikiAttachmentProvider #

What if a provider did not provide the complete functionality of a WikiAttachmentProvider. For example, the BasicAttachmentProvider does not have an implementation for delete version, or delete attachment. Perhaps this interface could include a method register, which the AttachmentManager could call when a provider was set. This register method could provide a token called something like AttachmentProviderRegistration that could a few methods that returned a boolean indicating which features were supported.

2. Administrator preferences #

An admin could override any features provided by the Provider, that he does not wish to use. It should go without saying that he cannot enable features that the provider does not support, at start time this should generate warnings, at the very least.

3. Access privileges? A murky hole - I have no idea what role access privileges play since they are currently not well defined.#

The Rationale: I know that you could always throw a ProviderException if the method were not supported or something, but if this feature were configurable, It would be be nice to know whether or not it was before offering the user an opportunity to trigger it.

Misc Comments#

In the WikiAttachmentProvider interface, currently the delete version method signature looks like this:

    public void deleteVersion( Attachment att )
        throws ProviderException;

It would be nice if it contained something to call out the version, like this:

    public void deleteVersion( Attachment att, String version )
        throws ProviderException;
This assumes, of course, that the version info wasn't buried in the Attachment class, but I didn't see it in there.


Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
commons-lang.jar 64.0 kB 1 12-Nov-2004 16:57
« This page (revision-7) was last changed on 27-Feb-2004 00:25 by RobSeegel