March 14, 2006
Created original code in skb-content. Consists of two modules: content-service and content-tool.
Difficulties creating a test harness (ContentTool).
April 14, 2006
Fixed Content Test Tool. Compiles and runs.
April 19, 2006
I can't get the top level of skb-content to compile. Jelly errors, a maven problem of some kind. While it would be useful to preserve the package names of the interfaces in a separate JAR, it might be simpler to just merge them all into the content-tool for now.
Merged interfaces and tool into a single module. Not quite working yet.
April 20, 2006
Retained Entity interface and Exception definitions in their package name.
Created a new ContentHostingService interface in tool directory. This interface is currently empty, but does extend EntityProducer. The idea is to focus a bit on just getting the entity support working first.
The content hosting service implements entity producer. This is intended to
The entity producer uses Reference objects to gain access to entities. This object is already implemented as a legacy component. Re-implementing is likely to be a great deal of work, and not desirable as the odds of understanding the conventions, and OBAs (not documented) are not good. Using this implementation would require bringing in legacy implementations and likely have dependency resolution problems. This effort might be better done in the mini-devel environment of Sakai 2.2.
Moved ContentCollection interface into the content tool folder. It extends Entity and adds a few methods, so I left them all in.
May 20, 2006
Couldn't find the modified interface definitions described in the previous entry.
Created FSCollection which currently only implements entity (edit) in a stubbed mode.
Created FSResource which also stubs enty/edit.
Added code to FSCollection and FSResource to include methods for ContentResource, ContentResourceEdit, Contentcollection, and ContentCollectionEdit. All stubbed.
Added constructors for FSCollection and FSResource, both taking a File object. These are currently defined as public, but later will be moved to protected, once the FSHostingService implmentation is started.
The intial implementation is focused on actual collection (directory) and resource (file) objecgts. Later, this will be extended to include properties (metadata), which is actually the harder part of the problem.
Created FSHostingService initially containing a public constructor and a single method to get a collection given an id. Implemented the getUrl(), getId(), and getReference() methods of FSCollection to return the full path, id, and reference respectively. Created a rootCollectionTest() in the ContentTool. Runs correctly.
Worked on an implementation of ResourceCollection.getMembers(). Currently returns a list of file names in the directory associated with the collection.
May 21, 2006
Started to implement FSHostingService.getResource(). What happens when a collection id is passed to this method? I suspect that collections extend resources and thus can be treated as such. However, there are methods in ContentResourse that don't seem to apply well to collections, such as getContent(). As such, we will treat them separately, and throw UnusedIdException if a collection is requested.
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:
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:
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?