Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Reading closer, this is what TypeException is for. TypeException will be thrown if the id is not of the proper type (resource or collection).

Jun. 2, 2006

Updated CH page with notes on identifiers. Since both resources and collections can be directly accessed from the ContentHostingService, identifiers will have to include full path names. The current content hosting service doesn't seem to have the concept of an active directory, though this might be present in the Resource Tool.

Started working on CHService.getCollection() starting with getting the root collection. Eventually the root will be relative to some context (site), but for now it is hard wired.

Added an FSCollection constructor that takes a File. Implemented CHService.getCollection() to create a File based on a root and the id passed. Added a small piece of code to ContentTool to test this and it works in that it returns "fsroot", the name of the directory designated as the root directory.

Under fsroot is another directory called test. Modified ContentTool code to access the test directory by passing "/test" as the identifier. This returns an id of "test". Note the problem in these identifiers: they can be passed back to the ContentHostingService to get the collections again. The path relative to the root need to be prepended.

Fixed this by passing in the id String as well as a File to FSCollection constructor. This allows the id to be kept apart from it's File representation, though this could lead to inconsistency with the File form. Tested against getId(). Implemented and tested getReference(). Both work properly now.

Created FSResource. Implemented constructor, getId(), and getResource() very similar to those in FSCollection. Added and implemented getResource in FSHostingService.

Added a few lines to ContentTool to test resources. Works correctly, with the following output:

Info

Test collection identifier: /test
Test collection identifier: /content/test
Resource identifier: /simple.txt
Resource identifier: /content/simple.txt
Resource size: 1315
Resource type: unknown-type

Jun. 3, 2006

Documented issues around context and identifiers. Should content be included in all identifiers?

Implemented getUrl() for both FSCollection and FSResource. Tested. Implemented getting content as stream and bytes in FSResource. Untested.

Added the rest of the ContentHosting methods to status page. There are quite a few of them. It's nice to have a hobby like this one. Keeps me busy and out of trouble!

Jun. 4, 2006

Implemented:

  • FSCollection.getMembers(),
  • FSCollection.getMemberResources(),
  • FSCollection.getBodySizeK().

Most of the basis methods in resource and collection are now implemented, except for properties. Since properties are to be saved in a file, we need a file based implmentation of entity.ResourceProperties. The name of resource properties are formed by replacing the file name of the resource's extension with ".properties".

It's not clear that collection properties are used in Sakai at this time, but clearly they could be useful. Since there is only one collection properties file in a given directory, it can be given a unique name, "collection.properties". As long as this file is filtered from the list of files in a directory, all will be fine.

Entity properties contain support for simple, multi-valued, and typed properties. Properties may be live, meaning that they are auto-saved once modified.

There are a number of convenience methods including in entity.ResourceProperites including:

Panel

getNamePropCreator();
getNamePropModifiedBy();
getNamePropCreationDate();
getNamePropDisplayName();
getNamePropCopyrightChoice();
getNamePropCopyrightAlert();
getNamePropCopyright();
getNamePropContentLength();
getNamePropContentType();
getNamePropModifiedDate();
getNamePropIsCollection();
getNamePropCollectionBodyQuota();
getNamePropChatRoom();
getNamePropTo();
getNamePropDescription();
getNamePropCalendarType();
getNamePropCalendarLocation();
getNamePropReplyStyle();
getNamePropNewAssignmentCheckAddDueDate();
getNamePropNewAssignmentCheckAutoAnnounce();
getNamePropSubmissionPreviousGrades();
getNamePropSubmissionScaledPreviousGrades();
getNamePropSubmissionPreviousFeedbackText();
getNamePropSubmissionPreviousFeedbackComment();
getNamePropAssignmentDeleted();
getNamePropStructObjType();
getTypeUrl();

Many of these have no right living in a generic service like entity. Recommend to Glenn that these be moved up into their respective modules.

Stubbed all of the methods of ResourceProperties in FSProperties. There is a basic implementation in the entity model called BaseResourceProperties. It appears that this class can be extended to handle all of the basic interaction cases, except loading and saving.

How are multi-value properties saved in a Properties object?
A: Value is stored as a List object (usually a list of strings).

There is a reference to formatted properties. How are they formatted?