intradoc.common
Interface ExecutionContext
- All Known Implementing Classes:
- ExecutionContextAdaptor
- public interface ExecutionContext
This interface is a key part of the filter structure for the Intradoc application.
There are some critical issues that have to resolved before a filter plug-in and
the application it is plugging into can properly interact. Some of the issues:
1. Generally when a plug-in is called it is called at the point the application
is trying to accomplish a particular task. The plug-in needs to be able indicate
any of the following at the time it returns from being called.
a. To continue normal activity as though the filter had not been called,
other additional filters can be called and the task has yet to be resolved.
b. To abort the task, but not as an error, but as a normal action. All
action on the task is aborted, but other execution can proceed.
c. To indicate that a task was accomplished. No additional filters need to
called but other code that needs to be called to accomplish the task
should be called as appropriate.
d. To throw an error exception to indicate that the current execution
thread should be aborted. Usually such errors will be reported to the
user or to a log.
The interface FilterImplementor in the "intradoc.shared" is an example
of how these needs can satisfied using the "final static" variables "CONTINUE",
"ABORT", and "FINISHED" as possible return values combined with the ability
to throw DataExceptions or ServiceExceptions. An example of usage, might be a
plug-in that is called at the time a variable is being substituted into an HTML page.
Returning "CONTINUE" would mean the variable had not been resolved, returning "ABORT"
would indicate that no substitution should be done for the variable,
and returning "FINISHED" would mean that an appropriate value has been readied
for substitution. Note: for many tasks not all return values are appropriate.
2. The plug-in needs to be able to access the data relevant to the particular task,
but it needs to do it in a "generic" fashion. The filter can be thought of
as a pipe that narrows at the connection between the application and the plug-in
and the filter technology needs to allow negotiation of intimate contact between
application and plug-in (this was how the "QueryInterface" call of the
Microsoft COM architecture got born). The ExecutionContext is the hot point
for such negotiation. In particular, the method "getControllingObject" allows
access to an object that should implement application functions needed by
the filter. Using the 'instanceof' keyword should allow the filter to determine
what functions are available. In the case of the interface "FilterImplementor"
it passes in both a workspace for accessing the database and a DataBinder
object used to hold all active data for the execution thread, so these functions
are already provided by the filter without having to be negotiated from the
controlling object.
3. The plug-ins need to interact with other plug-ins that are being called in sequence
during the same execution thread. In order to do that they need to cache data
to be used by other plug-ins in the same execution thread. The
'getCachedObject(...)' and 'setCachedObject(...)' are used to satisfy this need.
Note: when a group of 'plug-in's are cooperating, the cached object may
actually have the implementation code for the plug-in to make it easier to access the
shared instance data. An example might be an ActiveX or JavaBean plug-in object
that implements some of the standard filters with each different filter
associated with a particular event of the component. The event driver for
the ActiveX or JavaBean component would be placed into the ExecutionContext cache.
4. The plug-ins need to be able to indicate return values to the caller of the filter.
The 'getReturnValue()' and 'setReturnValue(...)' satisfy this need. Note:
these services use Objects. Generally strings should be returned unless the specific
filter specifies that other Objects can be returned. More complicated return values
tend to be put into the cached objects area.
getControllingObject
public java.lang.Object getControllingObject()
getCachedObject
public java.lang.Object getCachedObject(java.lang.String id)
setCachedObject
public void setCachedObject(java.lang.String id,
java.lang.Object obj)
getReturnValue
public java.lang.Object getReturnValue()
setReturnValue
public void setReturnValue(java.lang.Object retVal)
getLocaleResource
public java.lang.Object getLocaleResource(int id)
(c) 1996-2005 All rights reserved. Stellent, Inc. |
