Early Sousa Devel Notes - 2007

The create new sequence form is partially implemented. Form parameters don't seem to be properly packaged up and sent to main.html. Later, the target will be shifted to edit.html, once a producer stub is put in place for it. I took out the ViewParameter reporter, so that might have something to do with it.

Create an edit.htm template and corresponding ViewProducer. Iniitally, just display the parameters passed (name and desc). Later these should be used to create a sedquence and add it to the known list.

May 21, 2007

Created MainProducer as the main entry point into the Sequencer tool.

June 8, 2007

2 hours
Got menu to work. Needed to include field names in UIInput's.
Moved form response to EditSeqProducer. Results displayed.
Links on home page new link to the EditSeqProducer page.
Problem: how is the modified sequence communicated to MainProducer so that it can update (or cancel) it? Could use a temp file.

Basic form funcgionality is working. Need to create a new sequence. Load items from an existing file. Save items out to a file. Movement.

June 10, 2007

3 hours
Designed the sequencing UI elements.
Added sequencing table to edit.html.

Sakai Conference Notes

Aaron showed an RSF component that does drag and drop sequence editing. It's very likely that this could be adapted to the sequence editor, and would make a nice story to re-use it in a new application. It will mean learning how to use Evolvers and components, but this is a good thing. Meanwhile, I will press on with the existing design.

Spoke about the Sequencer at one of the presentations. There were many who wanted to contribute, etc. I pushed back hard because this is supposed to be a fun project. There was some discussion with BU about making it a funded project, but I don't think that's likely.

The same presentation raised some interesting use cases for the sequencer. It would be good to write a couple and show how it will meet those needs.

June 16, 2007

2 hours
Fleshed out the Sequencer service and EditChain methods. Still needs more work. There are inconsistencies in this design that I don't like. It needs to be thought through more clearly and I'm hoping that the edit actions and saving out sequences will finalize what needs to be present.

June 17, 2007

2 hours
Added print methods to sequence and item. Added create sequence in EditSeqProducer. Sequence is getting created, not persisted, with no items.
Created edit chain and test for previously existing chain.
Next steps: Show UI with a single insert new item.

2 hours
Added the link to the Add Item view. In theory, this could be handled by a Resource Selection Helper or component. However, I don't know how to do that and don't have access to Antranig, being at sea off the coast of Denmark.

Getting ready to add code to allow selection of collections and resources. It occurs to me that the sequence collections are available for selection. What does it mean to include a sequence in a sequence? A sub-sequence, perhaps?

Created the Add Item view html. Added selection table. Created Add Item View Parameters object to pass info to Add Item page.
Next steps: Get collection drill down to work, the create links to select resources from collections. Eventually, filter by type.

June 18, 2007

1 hour
Got selection instructions to display. Show root folder name and icon.
Displayed contents of root collection.
Root collection is displaying. Folders have a correct link that brings back to select item page. However, recursive display of folders is not working. Need to parse the folder path.

June 19, 2007

1 hour
Got indentation working in select items. Folders are now working fully.
Next Steps: select an item!

In the edit sequence page, we could create the id of a new sequence once it arrives, since all parameters (name and description) are known.

June 20, 2007

0.5 hour
Debugged edit chain persistance. Testing selection flow.

2 hours
Adding print Edit Chain.
Changed link for resources in Add Item view to contain the parameters for an edit.
Edit is being received in EditSeqProducer and added to the edit chain. Edit chain is being persisted in session. Started work on editing the sequence based on the edit chain commands.

Next steps:

Sequencer service need methods to create, add, and move Items in the sequence list. Then implement each edit command.

June 23, 2007

1 hour
Implemented edit commands in Sequence.
Re-worked data in the item object. Name and description are now extracted from the resource given by id. For now, this is much simpler. Later, may want to expand Item to include additional information.
Implemented edit operations in getEditedSequence().
Display of edited sequence is implemented. Most of the editing functionality is now fully implemented.

Next steps:

extensive testing is needed on adding and inserting new items, deleting items, and moving them around.

June 24, 2007

.5 hour
Append is working and edited sequence is displayed. Created a sequence of two items. Controls need to be moved closer together, perhaps using a table. Links for movement edits are not functional. Insert and delete links are not present.
Added links for movement edits. Movement links are greyed at sequence boundaries (start and end). Fixed insert and delete links.
Append to end seems to be working ok. Insert is broken.
Fixed insert link. However, inserts are always being appended to end.
Movement links are broken.

1 hour
The problem with insert was that AddItemProducer is actually being used for two different operations: add and insert. It was being hard-coded to an add, thus forcing all inserts to be treated as add. Since the correct offset for add is being passed in both directions, it should be ok to convert this to a hard-coded insert instead. This effectively eliminates add as an operation, however.

Insert is fixed. It's inserting before the selected entry point, which is ok, since it's the only way to put something at the top of the list in a single operation. Append correctly adds to the end of the sequence.

Changed handling of operations in EditSeqProducer (simplified, actually). Move next and previuos work. Move last seems to work, but move first doesn't seem to do anything.

All edit operations are now functional.

Next steps:

save edited sequence. Then load sequence from file. File types and show preview. Think about creating objects to insert.

June 25, 2007

.5 hour
Cleaned up Item implementation. Added getType() and getUrl().

0.5 hour
Added type display. Image previews.

June 27, 2007

1 hour
Worked on Learning Templates document.

Next steps:

save edited sequence. Then load sequence from file. Finish textual previews.

June 28, 2007

2 hours
Initialized text preview. Works with both text and html files.

1 hour
Started work on saving and loading from XML document.
Added load() and save() to the Sequence API.
Wrote the code for save(). Not tested yet.

3 hours (on return flight)
Created MainViewParameters. Changed links to main to use it.
Catching save event. XML file is created, but has no text in it.
XML text is being saved out as:

<sequence>
	<item contentId="/group/ContentTest/Peterhoff/turtle-fountain.jpg"/>
	<item contentId="/group/ContentTest/Peterhoff/thrown-room.jpg"/>
	<item contentId="/group/ContentTest/Peterhoff/st-peters-domes.jpg"/>
</sequence>

Have the content Id's as attributes on ITEM is fine (though not my original choice). Need to add a name attribute to SEQUENCE, though.
Fixed XML generation to include the sequence name. Now looks like this:

<sequence name="Peterhoff-3">
	<item contentId="/group/ContentTest/Peterhoff/grand-allee.jpg"/>
	<item contentId="/group/ContentTest/Peterhoff/st-peters-domes.jpg"/>
	<item contentId="/group/ContentTest/Peterhoff/turtle-fountain.jpg"/>
</sequence>

Next steps:

Edit a previously created sequence, aslo delete sequence.
Can't figure out how to load XML into a Document object. I don't have any documention on it.

In the mean time, there is a lot of cleanup to do by removing all of the old gallery tool code. Deleted all gallery tool files. Renamed message bundle path. Deleted old messages from bundle.

Sept. 20, 2007

Moved Sequencer code to LearningEdge instance so I could see if it still works. It does, but I discovered that I can't launch a previously built sequence because that part of the code is missing. Darn.

Sept. 21, 2007

I've been kicking the idea around of merging the player and editor into a single application and adding the idea of page templates, see Sousa Page Layout. First off, I need to get sequence load to work, then write the player, which I think will go quickly. The design documents for player and editor need to be merged and then add the page template concepts.

Implemented the load() method in SequenceImpl using DocumentBuilder from Xerces. More testing is needed.

Sequence is loaded and displayed but the edit chain needs to be intiailized.
Initialized the edit chain. Editing now works. I can insert new items and move things around. However, when I press update, the changes are not saved.

Sure enough. Looking at Sequence.save(), I note that if a resource already exists, nothing happens. The newly edited sequence doesn't replace the old one. That should be simple to fix.

Fixed. Some debugging required. Sequences can now be loaded, edited, and updated.
Created POCS logos.

Implemented delete in user interface and sequence service.

Started working on the player. Shifted edit link to one labeled "edit", next to "delete". Link off of the sequence title will be to play / view the sequence. Created a play.html and PlayProducer.java. Stubbed out play view is displayed.

Next Steps:

Create a ViewParameters for the player that holds an offset state.
Get title, name, description and display them.
Get content and display it.

Sept. 23, 2007

Wrote a PlayViewParameters object to hold an operation (next,prev,exit), a sequence id, and a sequence office.
Modified the template to have optional elements for next and previous – one is a link, the other disabled text.
Links are now working. Able to go forwards, backwards, and exit. On the title is shown at this time.

Sept. 24, 2007

Added content display as currently defined. Now that I see it working, it needs work. Keep the title, loose the description. Append offset number to the title.
Title now has offset number appended. Description is removed. Content shown using UIVerbatim, which allows HTML content to show.

Sept. 25, 2007

Created a sample page layout description as follows:

<layout name="Aikido Opening" type="stacked">
    <tile>
	<item contentId="/group/ContentTest/Aikido/seminar.jpg"/>
    </tile>
    <tile>
	<item contentId="/group/ContentTest/Aikido/Mill City Seminar Description"/>
    </tile>
</layout>

I plan to add support to the player to identify and display formatted pages. This is the first, tentative step towards a page-object that will support Sousa Page Layout.

Oct. 5, 2007

Started work in PlayProducer to detect page layout sequence items. The first step is to detect XML files - now working.

Next steps: parse the XML, detect a layout tag, reject other XML files. Process page elements and display them.

Nov. 23, 2007

Started work on page editing.
Added a "new" link on the add resource page. This links to "newpage", where we collect a name, title and description for the new content resource. A NewPageProducer.java file was created.

The resource collection id needs to be passed into the New Page form.

Nov. 26, 2007

Here's another complication: after the page object is created or edited, how do I get back to editing the sequence? Do I need to pass around the sequence id, or will the system pick it up from where it is cached in the user context? Looked at AddItemProducer, it seems that I only have to keep track of the offset where the new item (page) is being inserted (if created).

Create NewPageViewParameters. Passed the collection id and sequence offset to the new page view. These will be passed on to the edit page view via hidden inputs.

Hidden fields are correctly rendered in the view source, ready to be passed on to edit page.
The edit page view is based on the play view. It doesn't really allow much editing, only changing the format type and providing links to edit tiles. Care needs to be taken to preserve tiles that are no longer visible. The user should be able to switch from a four cell view, to a two cell view, and then click back to a four cell and see previous content restored. This is handled by the layout object.

Created EditPageProducer and EditPageViewParameters. There is more than one entry point into the edit page view: a page can be opened for edit, a new page may be created, the page format can be changed, and a tile can be modified.

On further though, I don't need those hidden fields. RSF will do it for me with the view parameters.
Got the code working all the way through to the edit page view.

Next steps:

  1. Add an edit page link to items in the sequence that are editable pages. This may require a CHS property.
  2. Get the Edit Page to display an existing page object
  3. Get the Edit page to display an empty, new page object
  4. Add page format icons and links.
  5. Add edit tile links.

Nov. 27, 2007

Added createLayout() and getLayout() methods to the Sequencer Service. These return a Layout unassociated with a sequence. It must be added through the regular sequence editing process to be part of a sequence. Added a getId() method to Layout so that we can get the full id of a newly created Layout object, also implemented it.

createLayout() and getLayout() are currently stubbed to return null. All compiles.

Nov. 28, 2007

Implemented SequenceService.createLayout(), SequencerService.getLayout(), and a new instance of the LayoutImpl constructor to save collection, name, and description for eventual creation of the page object in the content hosting service.

Tried it. Exception on getting resource id. No surprise, since none was created.

I need a means to hold the layout object under edit in a state variable, I think. With this in place, I wouldn't need to pass the id of the layout under editing around. heck, I could even cache the sequence offset and not worry about that, either. It all be in memory until it's time to save it out.

Nov. 29, 2007

Commented out the getId() where it was failing before. It's not needed until we try to edit anyways. Page displays without error, but there is nothing on it. I need to add an initial Tile to the layout. Added tile, page displays an empty page object with a single tile. Edit Tile link is present but doesn't link to anything (yet).

Created the first four layout icons in both an off and on version. They are:

single-on.jpg, single-off.jpg

Single tile

dual-on-jpg, dual-off.jpg

Two tiles, dual columns

stacked-on.jpg, stacked-off.jpg

Two tiles, stacked rows

quad.on-jpg, quad-off.jpg

Four tiles, quadrants

Added icons to editpage.html template.
Will need to cache the Layout object to fully support layout format changes.

Caching of the edit chain (for sequence editing) is done in the SequencerService. I'm not really sure if that's the right place for it, actually. I think caching is part of the tool logic, not the service object. The service's job is to persist and retrieve the objects, though I suppose caching is often done at this level for performance reasons. Caching isn't being done for performance reasons here, however. It is for reasons of state. As such, I'm going to put this in the EditPageProducer. Later, we should think about pulling the cached edit chain into the tool as well.

Added Layout object caching. Added links to format type icons. Tossed lightly, code works.
At this point, format type editing works for a layout (page object).

Next steps:

  1. Add an edit page link to items in the sequence that are editable pages. This may require a CHS property.
  2. Get the Edit Page to display an existing page object
  3. Add edit tile links.

Nov. 30, 2007

Currently, there is nothing to distinguish one XML file from another as stored in the CHS.
It looks like metadata editing has been removed from the resources tool, which will make it hard to arbitrarily add a property for file sub-types.
In the short term, we'll allow any XML file to be edited as a POCS file. If it is such a file (each to check once the XML is loaded, we'll mark it wtih a file sub-type property with a value of "pocs-page". New page objects (once created, will also be marked with this property. Later, we can filter the list by the file sub-type. The file sub-type would also allow us to store POCS sequence files any place, not just in a special directory. This is nice, since it allows sequences and the objects it refers to to be clustered in the same resource collection.

Added a link to EditSeqProducer and edit.html to EditPageProduce if the sequence item is an XML file. Edit page properly displays the two tiles with content items in them.

Next steps:

  1. Add edit tile links.

Dec. 2, 2007

Created EditTileProducer by copying EditSeqProducer. Created EditTileViewParameters by copying EditViewParameters. Created edittile.html by copying edit.html. Wired up link in EditPageProducer to go to a stubbed version of edittile.html.

Had some trouble with UIInternalLink in EditPageProducer. I had thought that I could refer to a message id in the message string parameter, but it just didn't work, even using RSF-EL. Used MessageLocator.getMessage() in the end. I could have embedded a span and used UIOutput which I think will handle message references.

Next steps:

  1. Display items in a tile.
  2. Enable re-orderinng of items in a tile.
  3. Enable delete item from a tile.
  4. Enable add and insert items into a tile.
  5. Save tile
  6. Save page object

Dec. 5, 2007

Demonstrated POCS at the Eigth Sakai Conference in Newport Beach. It was well received, though the schedule time resulted in only 20 attendees.
Interest from Hannah Reeves of rSmart.
Several interest forms collected.

Later, demonstrated POCS at the Demo Night. More interest, including U. of Montreal, who is looking for a very similar tool.

Some ideas:

Fold in the Entity Broker to respond to clicking on a sequence or page object.
Create new media types for sequence and page object (sakai/pocs-seq, sakai/pocs-page). This could enable icons, filtering, etc.
Interest in video, audio, flash, interactive questions, grading, etc.

Some problems with back button during demonstration. It didn't always back up gracefully. There is a bug in there somewhere.

Dec. 26, 2007

Changed the name to Sousa. Several people indicated that POCS wasn't a very good name. Sousa has the advantage of being quite pronouncable, It's not an acronym, but rather a reference to the great march composer, John Phillips Sousa.

All confluence documentation updated to refer to Sousa instead of POCS. Also re-organized the structure of the pages a page to make the information more accessible and easier to find.

Started work on edit tile. The EditTileViewParameters object has an operator (op), offset, id, and tile parameters. We will need a new edit chain, since this edit operation is separate from the sequence edit chain. It might be wise to break out the edit chain support in SequencerService into it's own service. Created an EditChainService with the following methods:

public String createEditChain (List sequence) throws EditChainExists;
public EditChain getEditChain (String id);
public void clearEditChain ();
public List getEditedList (String id);

Jan. 28, 2008

Lost track of the work on EditChains. Sigh.

Since working on Suosa at Christmas time, I've been thinking about it's tool kit nature (or lack thereof). Sousa needs to be split into two editors/display applications: one for page objects and one for the sequencer. Frankly, the page objects are useful all by themselves, even if people don't sequence them. Further, that's where the really interesting parts of the project lie (media forms, etc.). Splitting these out will mean breaking out the sequencer / page services into their own Sakai component, so that they can be shared by page and sequencer applications. This makes for more re-use anyways and was intended from the start (just too lazy early on).

This factorization will happen with the migration from the pocs entry into controb to a sousa entry. At the same time, I'll change the application names. This will still be aimed at the 2.4.x branch of Sakai for now, but I'll need to migrate over to 2.5.x PDQ. The big change moving to 2.5.x will be updating the maven project files to POMs (Maven 2.x), but also presents the opportunity to integrate with the entity broker and the JCR repository.

Created a new (unchecked in) directory in mnorton called sousa. Added "sousa-api/api". Copied api's and exceptions over to this new place. Edited files to refer to a package of "org.sakaiproject.sousa.api". Created a maven project file (from chat) to build the api component. Builds and deploys without error.

Created a sousa impl tree.

Figured out where I was with EditChains. Fixed a bunch of compiler bugs. Impl now compiles. Implementation needs to be tested and integrated back into the applications. Since the apps are getting refactored, these can be moved in as needed.

Next Steps

  1. Remove getEditedSequence() from EditListImpl.
  2. Create a pack maven project. Check to see if impl component is packaged and deployed correctly.
  3. Create a sousa-tool directory with two tools in it: page-tool and sequence-tool.
  4. Enable CHS to launch a page into the page viewer.
  5. Add CHS action to edit a page view (layout).
  6. Look into enabling Entity Broker
  7. Look into adding reorderer Fluid component.
  8. Complete page editing
  9. Finalize plugin architecture
  10. Add media objects.

Jan. 29, 2008

Created a Sousa pack maven project and components.xml file. Compiles without error. Pack component is deployed to tomcat/components correctly. Naturally, the final test will be when tools are added. I think the right order of doing this is to move the tool code (as is) from POCS and get that up and running. That essentially migrates the POCS code to Sousa at it's current state of development (including the currently incomplete page editing code). Once that's up and running, the page editing code can be broken out into its own tool.

Started migration of tool code over into Sousa packages. Kept all POCS code together (break it up later). Renamed the tool to "sakai.sousa.seq". This will be the sequencer and sequence editor tool. Later, I plan to add one which is purely focused on editing pages. Updated applicationContext and requestContext to refer to sousa package names. Updated web.xml file to refer to new tool name (sakai.sousa.seq). Changed maven tool name to sousa. This may need to be further refined to sousa-seq if there is a URL naming conflict with the page tool. Added dependency to sakai-sousa-api. Some compile errors around getEditedSequence(). Two places fixed, but the one in MainProducer is still broken. This is the main save edit operation. That's gonna take a bit more thought.

Sequence tool now builds and deploys. However, it doesn't load.

Feb. 1, 2008

Tried several other ways to get app to load, without success. Eventually ping Antranig and asked him. Discussion in Chat with Antranig Feb. 1, 2008,

Feb. 2, 2008

I'm not sure I believe Antranig when he says that accessing the Sakai ComponentManager directly won't work. It should. I'm going to re-code access to the SequencerService using init() methods in the various producers, along the lines of:

	/**
	 *	Get a SequencerService instance from the Component Manager.  This used to be injected via the bean definition in requestContext,
	 *	but Sakai components are not in the classpath at bean initialization time.
	 *
	 *	@author Mark Norton
	 */
	public SequencerService sequencerService = null;
	public void init () {
		this.sequencerService = (SequencerService) ComponentManager.get ("org.sakaiproject.sousa.api.SequencerServce");
	}

Init() methods need to be declared in the bean definitions in requestContext like this:

  <!-- Define the component producer for the main view -->
  <bean id="MainProducer" class="org.sakaiproject.sousa.tool.MainProducer" init-method="init">
    	<property name="messageLocator" ref="messageLocator" />
  </bean>

Still didn't load. Same errors (dammit!). After some poking around, I determined that these errors were coming from the old POCs tool, which seens to be partially converted over to Sousa. Removed tool from Tomcat. A different error on startup referring to the "requestAddressibleParent" bean in applicationContext. I seem to have removed it's value during development, but not really sure what goes in here. Now defined as:

  <!-- Define the bean roots from the request scope file that are accessible 
  via incoming request URL (not strictly necessary for this app) -->
  <bean parent="requestAddressibleParent">
    <property name="value" value="none"/>
  </bean>

Tomcat finally loads without error.
Sakai startups without problems.
Used Sites tool to replace old POCS tool with Sousa.
On accessing Sousa, the MainProducer reports that the SequencerService is null. (sad)

I seem to recall a similar problem once in another application. Because the MainProducer is being instantiated when it is requested, it has it's own Spring context. That's what the applicationContext and requestContext are for.

One more try. I'll try turning the singleton flag off in the component pack and see if that makes a difference.
Nope, that failed too.

It looks like the factory approach that Antranig mentioned is my only course of action. This seems really broken to me. Why can't I access defined Sakai components into an RSF application?

Add a couple of print statements in SequencerServiceImpl for init() and destroy(). Neither are ever getting called.
Turned singleton flag back on (true). Restarted. Service is being started up. So why isn't it available to my application via the Component Manager?

Add a dump of existing, registered components if the sequencer service is not found in the MainProducer. It seems to be registered correctly.
Moved the initialization from the init() method into the fillComponents() method of MainProducer. This works. I think what is happening is that the producer is getting created as a bean, but that instance is not being used when it comes time to respond to the request. Frankly, as long as there is a way to get access to the sequencer service in a producer, then the code will work in it's factored form. This is WAY too complicated. RSF is doing tricky things with beans (obviously), but it seems reasonable (to me) that it honor bean definitions. Clearly, I don't understand RSF or Spring well enough. Oh well. At least I can figure it out and make it work.

Stripped out the init() methods (since they are useless). Added access to sequencer service to the fillComponent methods of the producers that require it.

Sousa comes up and shows the list of sequences available. Sequence and pages can be viewed. Editing seems to be broken, but that's not too much of a surprise. Error is related to edit chains, which was re-implemented, but not tested at all.

Feb. 5, 2008

Attempts to edit a sequence are failing in Sousa:

***** Sequence edit operation is: up
2008-02-05 13:33:57,451 WARN (RenderHandlerBracketer.java:110) - <Exception rendering view: >
java.lang.NullPointerException
        at java.util.Vector.<init>(Vector.java:149)
        at org.sakaiproject.sousa.impl.EditChainImpl.getEditedList(EditChainImpl.java:105)
        at org.sakaiproject.sousa.tool.EditSeqProducer.fillComponents(EditSeqProducer.java:160)
        at uk.org.ponder.rsf.view.support.ViewCollector.fillComponents(ViewCollector.java:56)

The edit chain list is null, which causes the copy list operation to fail.
Make some changes to EditChainImpl constructors to intialize list and stack.
Pushed failure back to EditSeqProducer:

***** Sequence edit operation is: up
2008-02-05 13:47:39,076 WARN (RenderHandlerBracketer.java:110) - <Exception rend
ering view: >
java.lang.NullPointerException
        at org.sakaiproject.sousa.tool.EditSeqProducer.fillComponents(EditSeqPro
ducer.java:160)
        at uk.org.ponder.rsf.view.support.ViewCollector.fillComponents(ViewColle
ctor.java:56)
        at uk.org.ponder.rsf.view.support.LayoutCollector.fillComponents(LayoutC
ollector.java:68)
//  Update the sequence from edit chain.
seq.setItems (chain.getEditedList());

Looks like the sequence object was null, so we can setItems() on it.
Confirmed that sequence object is null.
Needed to create a temp edited sequence from the edit chain. This used to be done by editing the sequence in place, but now the EditChain is abstracted away from sequences, we need to rebuild a sequence from an edited chain. Needed to access the sequence id stored in edit chain, so interfaces changed in several places. Added a new createSequence() method in SequencerService that takes an id and list of items. This needed a new constructor in SequenceImpl.

Editing is working, but I don't think that changes are being saved back to the original sequence. Confirmed, edits are not saved. Also, the first edit doesn't seem to be applied.

Feb. 7, 2008

Code in MainProducer was stubbed out to save sequence edit changes. Implemented using new EditChain service calls.
Well, it would have worked, but something seems to have changed in Sakai utilities. It can't find org.sakaiproject.util.Xml. There didn't used to be a problem with this. The strange thing is that it compiles.

Feb. 8, 2008

Dug deeper into the mystery of org.sakaiproject.util.Xml. Rebuilt the util package with no problems. sakai-util-util is built as a jar and then bundled into the sakai-util-pack compoment. I am including sakai-util-api and sakai-util in my maven file. This has always worked before. Including sakai-util should provide the definitions and the actual class is loaded by the Component Manager at start up time.

Tried removing the sakai-util dependency in maven. Sousa-impl won't compile without it, as expected.
The sousa-impl JAR, including the sousa package doesn't include sakai-util.

This has to be some kind of class loader issue.

Had a long Chat with Chuck on Feb. 8, 2008. The upshot is that he suggested that I need to force the utils to be bundled into the sousa pack component using code like this:

<dependency>
       <groupId>sakaiproject</groupId>
       <artifactId>sakai-util</artifactId>
       <version>${sakai.version}</version>
       <properties>
             <war.bundle>true</war.bundle>
       </properties>
</dependency>

The war.bundle flag is what causes Maven to actually include the component into my war.

Feb. 9, 2008 - Happy Birthday!

Add the war.bundle flag to the sakai-util dependency, as written above. Well, the good news is that I don't get a Class Not Defined error on the Xml class anymore. The bad news is that it doesn't save the sequence. Furthermore, it seems to be creating a new artifact in the CHS directory that's ALSO wrong. At least I can resume debugging.

If I can get Sousa to the point where sequence editing works again, I'll save it out to contrib, even though the page editing stuff is not complete.

Feb. 10, 2008

A temp sequence is being built from the EditChain and forced to save. While this sequence has the right id, a CHS resource hasn't been initialed for it, so save() thinks it is a brand new sequence and save it as such, rather than as an update.

Recoded the save operation in MainProducer to look like this:

//temp = sequencerService.createSequence (sid, items);
temp = sequencerService.getSequence(sid);
temp.setItems (items);
temp.save();

This should fetch the existing sequence and the item list updated by the edit chain list.
Well, the creation of a new sequence (rather than updating an existing one) is fixed. However, the sequence is not altered.
Printed out the temp sequence, just before saving:

SEQUENCE 'Peterhoff-3' has an id of '/group/ContentTest/ContentSequences/Peterhoff-3.xml' and a description of 'A series of images.
        0.  /group/ContentTest/Peterhoff/grand-allee.jpg
        1.  /group/ContentTest/Peterhoff/st-peters-domes.jpg
        2.  /group/ContentTest/Peterhoff/turtle-fountain.jpg

There is something wrong with the edited list of items, because I moved turtle-foundtain to the top of the list.
Added print out of edit chain. It doesn't look right either:

EDIT CHAIN for Peterhoff-3
        0.  first on  at offset of 2
        1.  first on  at offset of 2
SEQUENCE 'Peterhoff-3' has an id of '/group/ContentTest/ContentSequences/Peterhoff-3.xml' and a description of 'A series of images.'.
        0.  /group/ContentTest/Peterhoff/grand-allee.jpg
        1.  /group/ContentTest/Peterhoff/st-peters-domes.jpg
        2.  /group/ContentTest/Peterhoff/turtle-fountain.jpg

It's clear that the first edit was recorded, but the temp sequence wasn't updated. That's odd, but one bug at a time.
What's stranger is the lack of item id's. Not much can be done without references to the things being edited.
Also interesting is that these id's are not null (I added code to force a show of null).
So we need to back further up the chain and look at things while they are being edited.
The id's are null on the URLs. Added id's to the URLs – they were readily available at item.getId(), but they might not actually be needed for editing. I don't recall.
A URL for a "move to first" now looks like this: "http://localhost:8080/portal/tool/76abb399-5742-43dd-8076-5c12d3009781/edit?op=first&offset=2&id=%2Fgroup%2FContentTest%2FPeterhoff%2Fturtle-fountain.jpg"
Note that special characters are escaped. This is probably why they were dropped out.

On the first edit (move turtle fountain to first), trace output looks like this:

SEQUENCE EDIT at 2 of operation first on id of /group/ContentTest/Peterhoff/turtle-fountain.jpg
EDIT CHAIN for Peterhoff-3
        0.  first on /group/ContentTest/Peterhoff/turtle-fountain.jpg at offset of 2
SEQUENCE '/group/ContentTest/ContentSequences/Peterhoff-3.xml' has an id of '/group/ContentTest/ContentSequences/Peterhoff-3.xml' and a description of 'null'.
        0.  /group/ContentTest/Peterhoff/grand-allee.jpg
        1.  /group/ContentTest/Peterhoff/st-peters-domes.jpg
        2.  /group/ContentTest/Peterhoff/turtle-fountain.jpg

The edit chain is created and the edit operation correctly stored. However, the display sequence doesn't reflect this edit. Why?

Making the same edit again results in:

SEQUENCE EDIT at 2 of operation first on id of /group/ContentTest/Peterhoff/turtle-fountain.jpg
EDIT CHAIN for Peterhoff-3
        0.  first on /group/ContentTest/Peterhoff/turtle-fountain.jpg at offset of 2
        1.  first on /group/ContentTest/Peterhoff/turtle-fountain.jpg at offset of 2
SEQUENCE '/group/ContentTest/ContentSequences/Peterhoff-3.xml' has an id of '/group/ContentTest/ContentSequences/Peterhoff-3.xml' and a description of 'null'.
        0.  /group/ContentTest/Peterhoff/turtle-fountain.jpg
        1.  /group/ContentTest/Peterhoff/grand-allee.jpg
        2.  /group/ContentTest/Peterhoff/st-peters-domes.jpg

Now we have two edits of the same thing (this is impossible unless there are duplicate elements in the sequence items) and the display sequence reflects the change.

Modified code in EditSeqProducer to use the same technique to create the display sequence (getSequence(), rather than creating a new one.

//	Create a temp sequence (for display purposes) from the edit chain.
List items = chain.getEditedList();
String sid = chain.getId();
//seq = sequencerService.createSequence (sid, items);  -- The old way, replaced by new that follows ....
seq = sequencerService.getSequence(sid);
seq.setItems (items);

Hmm. That didn't make any difference. First edit is still not being shown. I suspect that the problem may be in getEditedList().
Close reading of getEditedList() indicates that the item id plays no role. It could be eliminated, I suspect. Still, it's useful for debugging.

Added tracing of getEditedList();

SEQUENCE EDIT at 2 of operation first on id of /group/ContentTest/Peterhoff/turtle-fountain.jpg
EDITING LIST:  1 operations to be performed.
        EDIT:  first at offset of 2
EDIT CHAIN for Peterhoff-3
        0.  first on /group/ContentTest/Peterhoff/turtle-fountain.jpg at offset of 2
SEQUENCE '/group/ContentTest/ContentSequences/Peterhoff-3.xml' has an id of '/group/ContentTest/ContentSequences/Peterhoff-3.xml' and a description of 'null'.
        0.  /group/ContentTest/Peterhoff/grand-allee.jpg
        1.  /group/ContentTest/Peterhoff/st-peters-domes.jpg
        2.  /group/ContentTest/Peterhoff/turtle-fountain.jpg

This strongly suggests that the list is being edited to move the last item (turtle) to the start of the list. So why isn't it coming up in the Sequence moments later?
Ok, added code to show item list before an after editing:

SEQUENCE EDIT at 2 of operation first on id of /group/ContentTest/Peterhoff/turtle-fountain.jpg
LIST BEFORE EDIT:
        Item at offset 0 has an id of /group/ContentTest/Peterhoff/grand-allee.jpg
        Item at offset 1 has an id of /group/ContentTest/Peterhoff/st-peters-domes.jpg
        Item at offset 2 has an id of /group/ContentTest/Peterhoff/turtle-fountain.jpg
EDITING LIST:  1 operations to be performed.
        EDIT:  first at offset of 2
LIST AFTER EDIT:
        Item at offset 0 has an id of /group/ContentTest/Peterhoff/grand-allee.jpg
        Item at offset 1 has an id of /group/ContentTest/Peterhoff/st-peters-domes.jpg
        Item at offset 2 has an id of /group/ContentTest/Peterhoff/turtle-fountain.jpg
EDIT CHAIN for Peterhoff-3
        0.  first on /group/ContentTest/Peterhoff/turtle-fountain.jpg at offset of 2
SEQUENCE 'Peterhoff-3' has an id of '/group/ContentTest/ContentSequences/Peterhoff-3.xml' and a description of 'A series of images.'.
        0.  /group/ContentTest/Peterhoff/grand-allee.jpg
        1.  /group/ContentTest/Peterhoff/st-peters-domes.jpg
        2.  /group/ContentTest/Peterhoff/turtle-fountain.jpg

Note that the lists before and after editing in getEditedList() is the same.

I think I found the problem. The various edit operations in getEditedList() are working list rather than tempList. Heh. Stupid mistake.
The behavior showing up was the method acting on the actual list in the EditChain, rather than the temporary list.
This would also explain the inability to save an edited sequence, since the new item list being returned was always the original list, hence, no changes.

Yes! Both the initial edit problem AND the save edits bug are both fixed.
Obviously, more testing of the application should be done, after that....

Tested out editing a bit more. Inserting new objects works fine.
However, when a new sequence is created, can't add new objects. Null pointer error when trying to getSequence(). This makes sense because it doesn't exist yet.
Added checks for failure to getSequence() and created a new temporary sequence when so. Things work fine now.

Stubbed out new page creation in AddItemProducer. This removes the ability to create new page objects.
Stubbed out edit page in EditSeqProducer. This removes the ability to edit existing pages objects.
Verified that both of these links are gone.

Next Steps

  1. Remove getEditedSequence() from EditListImpl. – This can be safely done now.
  2. Release Sousa to SVN. (done)
  3. Migrated to 2.5.x (add Maven POM file).
  4. Create a sousa-page-tool to display just a page. (started)
  5. Enable CHS to launch a page into the page viewer.
  6. Add CHS action to edit a page view (layout).
  7. Look into enabling Entity Broker
  8. Look into adding reorderer Fluid component.
  9. Complete page editing
  10. Finalize plugin architecture
  11. Add media objects.

Also consider a sousa-player-tool application that just displays video, audio, etc. This would be VERY useful in Sakai.

Feb. 11, 2008

Checked Sousa into SVN at contrib/mnorton/sousa.
Make a tagged release into contrib/mnorton/sousa/tags/sousa_2-4-x-1.

Updated user and design documentation.

Sousa Page Tool

Created a Sousa Page Tool by copying the Sequencer tool. Did the intial SVN check-in.
Fixed several problems (view id, for example). Changed circular links to PageObjectProducer. Dropped cancel link (not needed).
Added back in the New (page) links per collection.

Started working on displaying a page object. Created ViewPageProducer from PlayViewProducer and ViewPageParameters from PlayViewParameters.
Added a template called "view.html" for the ViewPageProducer.
After some tinkering, got the page view to work.

Next Steps for Page Editor

  1. Change content types to sousa/page (or whatever I came up with).
  2. Filter out all but page objects.
  3. Add icon for page objects.
  4. Continue implementing page editor.

Feb. 12, 2008

Checked in changes to sousa-page-tool.
Backed up page tool.

I was doing some thinking early this morning (while not sleeping) about the media plug-in mechanism. I'm thinking about a JAR file that can be shared between Sousa applications that contains RSF code. The templates would still reside in the apps, but the code to fill the component trees would be in shared utility classes. I should even be able to auto-register them using an init() method on each class, triggered by Spring.

Worked on page editing back in November of last year. I think I'll tackle the work starting at Create Page Object this timne. The should meet in the same place, but I want to get the new content types in place for page objects. It will solve problems with distinguishing them from other kinds of XML files in a collection.

A NewPageProducer already exists. Let's give it a try. Had to add NewPageProducer to the requeestContext, but once there, the form came up and collected a title and description. Hitting "Create" brought me to the editpage view, filled by the EditPageProducer. There are no tiles, so it's expected that not much would be visible, but I also don't see any links to add content:

I think the problem here is that EditPageProducer doesn't check to see if there are no tiles in the layout and add one if so.
A check to SequencerService.createLayout() indicates that a new (empty) tile is added and that the default layout type is SINGLE_COLUMN.
Perhaps the problem is that I didn't get to the point of adding items to a tile back in November.
Each tile should have an "Edit Tile" link, according to the editpage.html template and there is code for it in the EditPageProducer.
It doesn't look like it's going through the tile display loop.
Ah, the problem is that the tile has no items, therefore doesn't display any items and the link to edit is inside of this loop. It shouldn't be in there in any case, so we'll just move it outside where it belongs.
Ok, now we get a NullPointerError on that line due to the fact that the Layout was created without an id.
The problem is in LayoutImpl, which assumes that a resource is present. It's not when one is being created.
No, the problem is that the link to EditTileProducer includes an id of the layout. This isn't needed since the layout is cached in the user session anyways. I think the best approach is to eliminate this parameter. EditTileProducer isn't coded yet anyways.
Ah, the EditTileViewParameters takes the id of an ITEM, not a Layout, and only in the case were an edit is being made.
I removed the parameters for id and offset, and used an operation of OP_NEW. Edit tile links now appear:

The Edit Tile link successfully goes to the EditTileProducer view as well, though it is just stubbed out at this point.
Updated changes to CVS.

Changed the view parameters for the main page from NewPageViewParameters to PageObjectParameters. This doesn't try to carry forward a sequence or sequence offset, since it isn't needed. Verified that directory drill down still works. Cancel on Create New Page form correctly returns to PageObjectProducer. Updated SVN (before leaving).

Wrote the code to display items and edit controls on the EditTileProducer page.

Having problems defaulting the tile number going into EditTileProducer. Keep getting number parse errors.

Added an isPageObject() method to the SequencerService API and implemented as testing for a content type of "text/xml". Later, this will be changed to "sakai-sousa/grid-page".
Used this to add edit links for page objects in PageObjectProducer.
Edit links show up, but unable to advance to EditPageProducer - NullPointerError.

Started to strip offset out of EditPageViewParameters. This offset is the sequence offset, which is not needed in the pure page editor.

Ok, now I can edit an existing page object (as long as it is still of type "text/xml").

Next Steps

  1. Finish removing offset out of EditPageViewParameters.
  2. Complete EditTileProducer - movement edits, delete item.
  3. Put in add item.
  4. Save layout.

Feb. 14, 2008 - Happy VD!

Completed removal of offset in EditPageViewParameters.
That may have been pre-mature, since an offset is needed for movement edits. Put it back as a integer parameter. That will avid constructor overloading problems. Fixed EditTileViewParameters. Fixed the order edit links, but not tested.

Feb. 18, 2008

Started looking at adding edits for tiles. The Tile object is very similar to the Sequence object, in that it is a container for an ordered set of Items. Sequence has a set of methods for each editing operation. I'm now wondering if that's really the best approach. For programmatic manipulation it would be useful to have separate methods, perhaps. From a UI perspective, however, we tend to have an edit code and an offset. Use the edit codes defined in EditEvent.

Changed the tile number in EditTileViewParameters to an integer. It simplifies some things.

The movement edit buttons don't quite have the right URLs yet. The item offset number is always zero. Also, there is no edit chain in place yet.

Made some fixes to edit button URLs. Now:

http://localhost:8080/portal/tool/047b6bbc-5e46-4bbc-00d8-e90dddeb2998/edittile?tile=0&op=up&offset=1

Feb. 19, 2008

I need an edit chain for editing the tile. However, the exiting code in the SequencerService takes a sequence as an argument. A sequence is not going to help me here, since I have a Tile object. This was the original idea behind moving support for edit chains out of the sequencer service into it's own service, but it's only half way moved out.

Chained the createEditChain() method to take an id, rather than use one created by the IdManager. If I use the IdManager, I have to persist the id of the edit chain across requests. By passing it in, I can use static strings instead. Add edit chain id.

Implemented section to handle movement edits in a tile.

Feb. 21, 2008

Finally got a chance to test the movement edit links. Wonder of wonders! They work. However there isn't any way to save edits yet. That's probably the next step, followed by adding items to a tile.

Delete operation works. Cancel doesn't - parameters are wrong.
Cancel is working too well, now. Edits to format are retained in the view (but not saved).
I need to make a copy of the tile being displayed in EditTileProducer.
Added a Tile.copy() method. Used it in EditTileProducer.
Edit and canceling now works.

Added Update (not implemented yet) and Cancel to EditPageProducer.
Cancel now works all the way out of edit tile to edit page and back to page object view.

Started working on save tile. Gasp! I am missing a parameter. Once we return from EditTileProducer, I don't know what tile was edited. This could be added as a parameter in EditPageViewParameters, but I'm already caching the edit chain. I think I will add properties to the Edit Chain. This will make it a bit more general.
Saved the tile number being edited in the edit chain. Retrieved at save time.

Added Tile.print() and Layout.print() for debugging purposes.
Added Layout.save(). Stubbed to a simple message initially.
Tested save links. Opened a layout for edit, opened a tile for edit, changed order of items.
On clicking update, changed tile is correctly displayed. On clicking update again, save message is shown in std.out

Now I just need to implement Layout.save() and page objects will be persisted.
Check code in.

Later that Evening

Completed Layout.save(). It's a bit scary. I'd hate to blow away my test objects, but I guess they can be reloaded again if I completely break them. I should have continued on the new layout track because it would allow me to create new page objects from scratch. I'm not all that far away, actually. I just have to code in the ability to pick and add new items and it's already been coded once for sequencing.

After fixing a minor XML error, it works. Page objects can now be edited.

Next Steps

  1. Put in add item.
  2. Create layout and tile.

Feb. 22, 2008

Started work add item. Eabled the link in EditTileProducer. Item selection view comes up ok, but the return links are wrong.
EditTileProducer wants the tile number, so I either have to pass it to AddItemProducer (so it can be passed back) or punt on it, since it's now keps in the edit chain properties anyways. If the later, it should be stripped out of the EditTileViewProducer. The tile number HAS to be passed in for intital editing, so it can't be eliminated completely, but it can be gotten from the cached EditChain on event events.

Make some changes to EditTileViewParameters to create constructors that don't take a tileNo. For those that don't, a -1 is used to initialize the tile number. This will force an array error if it is used.

Currently, there is no link to append (ADD) and item to the end of the item list in a tile. This is a very useful operation that should be added. It will need a flag passed to AddItemProducer to signal which kind of operation is being done (INSERT or ADD).

Changes to AddItemViewParameters caused EditSeqProducer to break. This could be a good time to get rid of the old producers.
Added back in a constructor to satisfy the old code and flagged it to be removed later. All compiles now.

After messing with code for a hour (mostly debugging), got the add item function to work. Displays after selection in EditTileProducer. Saves out to XML file correctly. Can be played/viewed.

Next Steps

  1. Create layout and tile.
  2. Remove old producers.
  3. Clean up page producers.

Feb. 23, 2008

Sousa has been coming along nicely over the past couple of weeks. Programming is a lot of fun without killer bugs. OTOH, there is the thrill of victory in squashing the big ones. Still, I'll take progress anyday.

Pretty much all that's left for the Page tool is creating a new page object (layout). I think most of the code is already there, but I need to save out a new layout in PageObjectProducer.
Tested it. Create new page object link is present in PageObjectProducer. Goes to a view to collect name and description. However, when it reaches the EditPageProducer, there is no layout object present. The edit operation code was missing and defaulted to EDIT. Changed to NEW in NewPageProducer.
It now reaches the EditPageProducer, but cannot proceed to EditTileProducer - null pointer error on getting id from Layout. Make sense, since there isn't one yet.

Separate bug in View logic. If you select an image object for viewing, a XML parse error comes up.

In some ways, the UI flow of Sousa Page is confusing. If there is an error going into select item, it fails back to PageObjectProdcuer, which looks VERY similar to AddItemProducer view. Perhaps these views should be made visually different.

Modified LayoutImpl.getId() to check for a null resources (the new layout case) and construct an id from the collection Id and name if so.
Ok, some progress. No longer get the null pointer error and the EditTileProducer view is displayed - empty since there are no elements in a new layout. However, there is no append item link, so there is no way to get the first item into the tile! (smile)
More progess. Append link appears. I get to the select item page and choose an item. Then it fails back in EditTileProducer. The transition is not signalling an ADD operation, so the code is falling through to a regular edit.

Feb. 25, 2008

Added a section in EditTileProducer to check for an add operation. Append items now works fine. Can build tiles from scratch and save them back to EditPageProducer. However, when I attempt to save out the page object, it is not saved.
There is a problem with creating the new resource.

***** Save Layout:  Error while creating a content resource.
java.lang.NullPointerException
        at org.sakaiproject.content.impl.BaseContentService.addResource(BaseContentService.java:2726)
        at org.sakaiproject.content.impl.BaseContentService.addResource(BaseContentService.java:3046)
        at org.sakaiproject.content.cover.ContentHostingService.addResource(ContentHostingService.java:328)
        at org.sakaiproject.sousa.impl.LayoutImpl.save(LayoutImpl.java:334)
        at org.sakaiproject.sousa.tool.PageObjectProducer.fillComponents(PageObjectProducer.java:116)

Looks like the collectionId is null.

Added print layout to the save block in EditPageProducer:

**** Sousa page object named TEST CREATION and description of test
**** Sousa page object has id of null/TEST CREATION and lives in the collection null

There's two things wrong with this: collection id is null, and the tile is empty.
The collection turns null as soon as the cached layout is passed to EditTileProducer:

**** Sousa page object named Create Anew and description of test
**** Sousa page object has id of null/Create Anew and lives in the collection null
        Tile has no items in it.

The collection id is not being passed across the NewPageProducer view. Comes into EditPageProducer as null.
Lots of poking around and trying out various combinations eventually yielded the right way to pass the collection id across. The NewPageViewParameters wasn't getting the right collection id at all. Can now create a new page object, add items to a tile, and save it out. Can be viewed.

Next Steps

  1. Remove old producers. - done
  2. Clean up page producers. - done
  3. Change content types to sousa/page (or whatever I came up with). - done
  4. Filter out all but page objects. - done
  5. Add icon for page objects in tools and Resource tool.
  6. Create second Sousa release.
  7. Migrated to 2.5.x (add Maven POM file).
  8. Enable CHS to launch a page into the page viewer.
  9. Add CHS action to edit a page view (layout).
  10. Look into enabling Entity Broker
  11. Look into adding reorderer Fluid component.
  12. Finalize plugin architecture
  13. Add media objects.

Feb. 26, 2008

Removed the following code files from Sousa Page tool:

  • EditSeqProducer.java
  • EditViewParameters.java
  • MainProducer.java
  • MainViewParameters.java
  • NewSeqProducer.java
  • PlayProducer.java
  • PlayViewParameters.java

The following HTML templates were removed:

  • main.html
  • new.html
  • play.html

This leaves the following HTML templates, with their corresponding producers:

Template

Producer

add.html

AddItemProducer

editpage.html

EditPageProducer

edittile.html

EditTileProducer

newpage.html

NewPageProducer

page.html

PageObjectProducer

view.html

ViewPageProducer

Tested code after removing these files. All seems to work ok. However, there seems to be an unrelated problem with creating a page object, saving it out, editing it out, saving those changes, then trying to view it.
Strange, now I can't reproduce it.

Time to add the new media types for Sousa. Page objects will be created with a type of "sousa/grid-page". I'm going to add two methods to SequencerService to check for a sequence and a page object: isSequence(String id) and isPageObject(String id), both booleans. The media types will be defined as constants in Sequence and Layout (LINEAR_SEQUENCE_TYPE and GRID_PAGE_TYPE).

New type codes worked fine in the Sousa Page tool. Old page objects can't be edited, but still need to be filtered out of the available selection list.
Added a SequencerService.isViewable (resourceId) method to test if a resource is a supported, viewable object. Changed code in PageObjectProducer to filter out all non-viewable objects. Works.

However, atomic content types no longer view correctly.
As near as I can tell, the SequencerService.getLayout() always creates an empty layout and attempts to load the layout description into it. It assumes that the object is always XML and can be loaded. In the case of other media types, that's not the case. It needs to be special cased here.
Added code to SequencerServiceImpl.getLayout() to support atomic media types. Seems to work just fine.

Saved out to SVN. Made a backup.

Next Steps

  1. Add icon for page objects in tools and Resource tool.
  2. Create second Sousa release.
  3. Migrated to 2.5.x (add Maven POM file).
  4. Enable CHS to launch a page into the page viewer.
  5. Add CHS action to edit a page view (layout).
  6. Look into enabling Entity Broker
  7. Look into adding reorderer Fluid component.
  8. Finalize plugin architecture
  9. Add media objects.

Feb. 27, 2008

I was doing some thinking about media properties last night. Ideally, it would be useful to be able to edit both the content and properties (metadata) associated with media types supported by Sousa. Some of these properties could be considered global in nature (thumbnail, for example) and can be stored with the content resources in CHS. On the other hand, authors may wish to customize some properties to a particular sequence, size of a picture, for example. Given that page and sequence items refer directly to a content resource, there is really only one instance of the media object, not a copy. The key question is where to store properties. If properties should be global, then it makes sense to associate them directly with the media object. If properties are contextual to a page layout or sequence, then the properties should be kept in the XML file (page or sequence). If the later, then the XML definition of both a layout and a sequence will need to be extended to include properties.

Currently, the XML file for a page layout looks like this:

<layout type="single-column">
    <tile>
        <item contentId="/group/ContentTest/More Stuff/no-3.jpg"/>
        <item contentId="/group/ContentTest/More Stuff/no-2.jpg"/>
        <item contentId="/group/ContentTest/More Stuff/no-1.jpg"/>
    </tile>
</layout>

I proposed to extend the format to include properties within the item tags:

<layout type="single-column">
    <tile>
        <item contentId="/group/ContentTest/More Stuff/no-3.jpg">
            <property name="width">50%</property>
            <property name="height">50%</property>
        </item>
        <item contentId="/group/ContentTest/More Stuff/no-2.jpg">
            <property name="border-width">10</property>
            <property name="border-color">CCFFCC</property>
        </item>
        <item contentId="/group/ContentTest/More Stuff/no-1.jpg">
            <property name="align">center</property>
        </item>
    </tile>
</layout>

Five image properties are shown in this example:

Name

Description

width

How wide to make the image as a percent or pixels. Empty value means none.

height

How tall to make the image as a percent or pixels. Empty value means none.

border-width

Width of border in pixels. Zero means no border.

border-color

Color of border as a hex color code.

align

Alignment can be left, center, or right.

One nice thing about this approach is that older XML files will still work (not that there are any out there at this point).

Started thinking a bit about the modular content element mechanism. Updated the Plug-in page Elements page to reflect a possible design along the lines of:

interface ContentElement {
    void displayContent();
    void displayThumb();
    void editContent();
    void handleInteraction();
    void loadContent();
    void saveContent();
}

Initial work would be on displaying content and thumbnails.
Created sousa-content/util directory by using svn export on sousa-api. This cloned the directory structure and maven projects for the new module content element kit. The code needs to live in it's own JAR so that it can be shared between the sequence and page tools. Eliminated all unneeded files, changed the package path to "org.sakaiproject.sousa.util" and created a single java file called ContentElement.java, which will serve as the interface for content elements.

Ran the initial add and checkin to SVN. rev. 46031

On initial investigation (very likely to change later), content elements need three things to create the UIComponent needs to display them:

  • a UIContainer to fill
  • a template Id string
  • a Sousa item

I have changed the interface definition of ContentElement to:

public interface ContentElement {
	public void displayContent(UIContainer tofill, String templateId, Item contentItem);
}

Four content element handlers have been initially created:

CEPlainText

Plain, unstructured text.

CEStructuredText

Text with HTML markup.

CEImage

Any supported iamge.

CEGridLayout

A grid layout page object.

This covers all of the currently supported media types. To start with, I'll implement these content elements and get them working in the page viewer. Later, they need to be added to the EditPageProducer, and the sequencer. With that in place, it should be simple to add thumbnail support.

I'm going to need instances of these content element handlers, unless they are declared as static (which they could be). Since I want to be able to have these things get registered in Spring, let's avoid the static classes for now and create master content element handler class. Created a CEBase class and then modified the CE handlers to extend it. That allows me to treat all content element handlers uniformly in the ContentElementHandler.

Most handlers are now implemented, though the grid layout content element is stubbed to display a message. Error messages are displayed for unknown media types and attempts to display the generic handler (CEBase). Just need to add the code to ViewPageProducer and we can test this baby.

Tried to add new code and check it in, but stupidly include the target directory in the initial check in. Needs to be removed.
Went to add the new handler code to ViewPageProducer and immediately ran into a problem. The templateId to be passed to ContentElementHandler.displayContent() is media-type dependent. Worse, it also includes a suffix to distinguish between left and right elements in a table.

For this to work, there needs to be some de-facto agreement between the template id and the media type being managed. Currently, the template id is of the form:

"content-" plus (media type) plus "-" plus (a suffix number)

Added a suffix parameter to the content element displayContent() methods. This is optional and append if not null. Each handler is now targeted at a template element as follows:

CEPlainText

text

Plain, unstructured text.

CEStructuredText

text

Text with HTML markup.

CEImage

image

Any supported iamge.

CEGridLayout

(special case)A grid layout page object.

After compiling and building, I tried it out on an existing page object with the following error as a result:

Fatal internal error handling request: 
java.lang.NoClassDefFoundError: uk/org/ponder/rsf/components/UIVerbatim
	at org.sakaiproject.sousa.util.ContentElementHandler.displayContent(ContentElementHandler.java:71)
	at org.sakaiproject.sousa.tool.ViewPageProducer.fillPageObject(ViewPageProducer.java:138)
	at org.sakaiproject.sousa.tool.ViewPageProducer.fillComponents(ViewPageProducer.java:99)

This seems to mean that I don't have access to the UIVerbatim object. It might just be a maven problem, so that's the first place to check. Added some other dependencies, but no help. I may need to implement these as evolvers, which would make Antranig happy. Likely worth knowing anyways.

Feb. 29, 2008

Had a chat with Antranig about not being able to access RSF classes from my shared code JAR. He says it's all Maven problems, which feels right to me. I had a look at the WAR file produced by the Sousa Page tool Maven project. It has a "lib" directory that includes the RSF JARs. When I look at the sousa-content/util JAR, the RSF jars are not there. This also makes sense, since you don't want to embed a JAR in a JAR. Maybe I need to bundle this as a WAR and bundle it into the app. Or bundle the util JAR into my page tool.

Changed the Souse Page tool maven project to bundle the JAR into it's WAR. This cased the class def error to go away, but items are not being displayed. Some debugging is needed.
Well, it seems that my registration system may be failing. It's not finding an image media type.
I should have picked a static text example to work with. Images use a wild card registration in the ContentElementHandler, since there are so many kinds. Added a getHandler() method that fetches the right handler for images.
Still not working. It's getting the handler now, which is good, but item is not being shown. Problem was a disagreement in template ids: "content-picture-00" vs. "content-image-00" Changed it in the template. Works now – YES!!!!

I tested the new handlers against four kinds of media: atomic images, plain text, structured text, and a grid layout page object. All seem to work just fine. This validates the shared code approach (well, it works, anyways).

Added a Layout.getName() method to fetch the name of a layout. Replaced display of content id in Page View with the layout (or media item) name.
Added a handler to display an icon component. Create a new grid page icon (local to the tool).

Later that night ...

Added media element handler logic to EditPageProducer to show media in tiles for edit.
Added media element handler to AddItemProducer to show media icons.
Implemented ContentElementHandler.displayThumbnail() for all supported media elements.
Added media element handler to EditTileProducer to show thumbnails.

Updated Learning Design and Design documentation to describe the new extensible content element handlers.

Next Steps

  1. Design and implement the plug-in architecture - done
  2. Use ContentElementHandler in all places where media is shown (ViewPageProducer (tick), EditPageProducer (tick), AddItemProducer(tick) ). - done
  3. Implement thumbnails in media handlers. - done
  4. Replace resource id with layout tile in page viewer. - done
  5. Add icon for page objects in tools and Resource tool. - done
  6. Update the Sequence tool to use the EditChainService.
  7. Update the Sequence tool to use content handlers, etc.
  8. Remove unused views in Sequence tool.
  9. Video media type.
  10. Audio media type.
  11. HTML link media type.
  12. Virtual lab media type.
  13. Property editors.
  14. Create second Sousa release.
  15. Migrated to 2.5.x (add Maven POM file).
  16. Enable CHS to launch a page into the page viewer.
  17. Add CHS action to edit a page view (layout).
  18. Look into enabling Entity Broker
  19. Look into adding reorderer Fluid component.
  20. Add media objects.