...
Created a static test page at: file:///C:/Documents%20and%20Settings/Mark/My%20Documents/_work/uCompass/steam-engine.htm
Talked to Tom Petz on the phone.
My domain needs to be registered. He is registering "localhost" for me.
He will also add some Octate tools to demonstrate.
...
24 sub-pages, most of which are no help.
Other interesting pages:
- Content Hosting /wiki/spaces/ARCHIVE/pages/19428638826 - written by me, no less.
- Content Hosing Service - largely about migration to JCR, which was implemented but never quite went all the way. Got derailed by Sakai-3 (OAE).
...
After analyzing all of the files in the content tool, I have found the following references to getContent():
- FilePickerAction.java - extends PagedResourceHelperAction, one instance of getContent() ****
- ListItem.java - one instance of getContent() ****
- ResourcesAction.java - extends PagedResourceHelperAction, one instance of getContent() ****
- ResourcesEditItem.java - extends ResourcesBrowseItem, one instance of getContent() ****
- ResourcesItem.java - three instances of getContent() ****
So the next step is to put hook messages in every one of these places and see if they get triggered when content is displayed.
Hooks are now in place.
...
Built JavaDoc using "javadoc:javadoc", which is deprecated but seems to still work. The comment mentioned "javadoc:aggregate".
JavaDoc got built to file:///C:/dev-sakai/kernel-1.2.6/target/site/apidocs/index.html
Copied the following JARS into the lib section of oct:
...
Also interesting is the fact that the id's are given as class names. The id of the HTML page is "org.sakaiproject.content.Types.HtmlDocumentType. I examined these class back in June of this year. It has several tool actions defined for it, including an ACCESS_CONTEST action that has been either deprecated or no longer used. Perhaps I can replace it with a new one.
Oct. 25, 2011
Yesterday I managed to list out all of the registered resource types. Today, I'm going to focus on the HTML type.
Verified that I can get the HTML Resource type and view it's associated actions.
I see that the HtmlDocumentType is in the Sakai Content code. Structures for resource types and resource tool actions are all part of the Sakai kernel, which is what you'd expect of good separation of data vs. structure. This opens the possibility of modifying operation of the Resource tool without having to modify the kernel (which would be difficult).
The finalize() method of a ResourceToolAction presents some possibilities. It is passed a reference to the resource, so I could modify it on demand, but it would be a permanant modification, I believe - not what I really want. What I want to do is to set up a way to intercept a call to getBytes() so that I can inject the Octane power cell.
It seems like ResourceToolActionPipe is the thing I want to take control of. It has a getContent() method that presumably can be used to modify code on the fly.
ResourceToolActionPipe provides a conduit through which ResourcesAction and an unknown helper may communicate about the execution of ResourceToolActions in which the registered action specifies that some part of the action is handled by a helper.
Looking through ResourcesAction, I note that the ResourceToolActionPipe is stored in a tool session attribute. I think it is created when an action is started, persisted as a runtime attribute, then deleted when done. ResourceToolActionPipe objects are not created in ResourcesAction. So where are they created?
A ResourceToolActionPipe can be passed into the creation of a ResourcesItem in the Resource tool, but I have console flags in place that should signal when this happens. It didn't in previous tests.
Just to see if I might gain access via an action, I uncommented support for ACCESS_CONTENT in HtmlDocumentType and added an Octane hook alert in HtmlDocumentAccessAction.finalizeAction(). Didn't get any alerts or messages. Darn.