Cross-Tool Integration

Cross-Tool Integration & Tool Interoperability

Cross-tool integration is the ability of one tool to leverage the content of another tool and/or navigate to/from another tool. This page contains the notes of the Cross-Tool Integration break-out group (Dec-2-2007).

Goals

1. support contextual action: replacing the wizard-like (helper tool) approach which takes user out of a tool context with 'embedded' helper tool view
2. support option for existing wizard-like helper-tool approach
3. support helper tools that cross presentations (e.g. velocity/jsf/rsf)
4. enable workflows (helpers that invoke helpers)

Usage Scenarios

• OSP: Selecting an assignment and linking to a OSP Matrix Cell
• OSP: Viewing an attached assignment
• OSP: Linking an assignment to a goal
• Assignment: creating/linking a gradebook entity
• ImageViewer: linking a resource (file-picker)

Discussion

• support for separating the service from helper tool (such that Tool A is not aware of Tool B)
• support for integrating helper views with external applications
• Form Builder (http://confluence.sakaiproject.org/confluence/x/4bQ contrib tool) provides a nice example of contextual action for saving XSD files to Resources

  Proposal Notes

Interaction Styles

Currently Helpers within Sakai only support the simplest user-facing "workflow" - a link leads to a series of separate views managed by the helper, which completely replace the current view, and at some later time return to it when the helper is "done". This is sometimes the appropriate style, especially for bulky and/or complex "wizards" but mostly causes a poor UX experience due to loss of locality and context from the users original task. We would like to build a system that supports the following use cases, preferably with the minimum "formality" or code intrusion on both client and helper:

i) "flat" portalised view in which the helper body is rendered inline in the context of the original page, with all links rewritten to top-level portal links.
ii) AJAXified portalised view, again rendered inline, but with links decorated with AJAX triggers which cause a rewrite only of the helper material itself.
iii) "Thickbox" style modal view which temporarily "overlays" the current view but does not completely obscure it.
iv) The current "whole-page" replacement style.
v) iframe-based rendering of the helper.

Of these, the most valuable are ii), iii) and iv) since they cover the majority of reasonable design contexts and user requirements. ii) and iii) are essentially the same mechanism differently packaged. i)/ii) in particular enables a very important UX Design Pattern, that of "/wiki/spaces/DESPAT/pages/21109243921" where a part of the UI "unfolds" to show more specific controls in context in response to a user interaction.

"Helpers" outside Sakai:

It was observed during the session that a particular value behind ii)/iii) relative to i) was that this mechanism could be used to include sources of application fragments outside Sakai entirely, in the style of Facebook widgets or Google "mashups". This sort of model requires tight constraints on the types of markup and interaction which are permitted in the "inner world" - it is generally only feasible in an environment which to some extent is controlled.

Strategies

• Leverage Entity Broker to facilitate locating/returning helper tool view (http://confluence.sakaiproject.org/confluence/x/F7M)
• Requesting helper tool view for an new entity may employ the convention of using "/new-<guid>"
• decorate entity URLs with parameters of client tool request
• helper tool view will be displayed as an embedded HTML snippet within client tool view

API requirements

The core cases ii) and iii) are dependent on a very simple API method (which could be implemented in a service or separately in presentation technology support packages) appearing as

public String getMarkup(String urlStub);

This accepts a "url stub" which is in essence a context-relative URL encoding a particular resource. In general these will be "entity URLs" of just the same form which may follow the mount point of the "Direct Servlet" provided as part of the Entity Broker - that is, the resource that would be accessed at the path protocol://servername/direct/urlStub

For convenience the use of this API should not require direct visibility of the "plumbing" of being able to locate an HttpServletRequest/PortletRequest or other environmental artefacts - although an implementation might well require caching of the "live" versions of these artefacts in ThreadLocals temporariliy. However a prime benefit of the EntityBroker is a "lightweight" method of being able to "originate" new requests into the system without the involvement of the container, be it a portlet or servlet container. Therefore a "blank" or "non-live" HSR or PR should be acceptable for all presentation technologies which are used to host these helpers. Q: Does this rule out JSP-based tools?

Advanced points - saving related cross-context entities

The session considered the particular use case of the assignments tool requiring to create a collateral "Gradeable" entity amongst the workflow of creating an assignment. It is an important UI goal that these two entity creation UIs should be presented homogeneously, or at the very least side by side to avoid interrupting the workflow. Since these two entities may be managed by different services, this creates a considerable architectural challenge in coordinating the transaction to ensure that one entity is not created without the other. Different styles were also considered for arranging for submission of data across the two services. Two options are possible:

1. A "transitive binding" style, where the "helper" entity exports both a special "binding object" in response to an API call which can be placed within the request context of the client renderer, which is responsive to "traditional" SpringMVC/RSF style reflective binding operations. It was considered this represented a potential hazard for JSF-based tools, but that it might be handled by development of a special "component".
2. A "fully AJAXified" submission style, where the HTML form being built up contains a "magic area" where submissions are targeted via AJAX to a completely differnet submission URL managed by the helper.

In both of these approaches there is the considerable risk of determining when both parts of the submission are definitely concluded. In general there will be a "dependent" entity and a "primary" entity, which must be committed to persistent storage in a definite order - one would expect in general the primary entity would be that from the client, but this might not always be the cases. The helper and client would need to coordinate between themselves to ensure that both entities were saved reliably in the correct order, potentially requiring a concept of a cross-context transaction within Sakai. Such a thing is currently supported, but essentially by "accident" since we have a single global Hibernate SessionFactory with associated TransactionManager. To enable this properly would require an upgrade of the global Sakai transaction manager construct JIRA and document.

Outstanding Issues

• how to handle transient objects? e.g. Assignment tool adds transient gradebook object, which needs to be saved later (when saving Assignment)
• how to return values from helper tool view to client tool? e.g. return url, session data, sakai events, ...

Action Item

• Continued discussion during the "The Future of Helpers in Sakai" BOF, Tuesday, 11:15 am in the Sunset room.

• Code to handle case ii) (& help with iii) is already available as part of the "rsf.js" library. An important deliverable for this work is to break out this logic as a dependence-free client-side library suitable for use with any rendering technology.