| java.lang.Object
 org.apache.velocity.context.InternalContextAdapterImpl
| InternalContextAdapterImpl | | final public class InternalContextAdapterImpl implements InternalContextAdapter(Code) | | This adapter class is the container for all context types for internal
use. The AST now uses this class rather than the app-level Context
interface to allow flexibility in the future.
Currently, we have two context interfaces which must be supported :
- Context : used for application/template data access
- InternalHousekeepingContext : used for internal housekeeping and caching
- InternalWrapperContext : used for getting root cache context and other
such.
- InternalEventContext : for event handling.
This class implements the two interfaces to ensure that all methods are
supported. When adding to the interfaces, or adding more context
functionality, the interface is the primary definition, so alter that first
and then all classes as necessary. As of this writing, this would be
the only class affected by changes to InternalContext
This class ensures that an InternalContextBase is available for internal
use. If an application constructs their own Context-implementing
object w/o subclassing AbstractContext, it may be that support for
InternalContext is not available. Therefore, InternalContextAdapter will
create an InternalContextBase if necessary for this support. Note that
if this is necessary, internal information such as node-cache data will be
lost from use to use of the context. This may or may not be important,
depending upon application.
author:
Geir Magnusson Jr.
version:
$Id: InternalContextAdapterImpl.java 471908 2006-11-06 22:39:28Z henning $ |
| context | | Context context(Code) | | the user data Context that we are wrapping
|
| icb | | InternalHousekeepingContext icb(Code) | | the ICB we are wrapping. We may need to make one
if the user data context implementation doesn't
support one. The default AbstractContext-derived
VelocityContext does, and it's recommended that
people derive new contexts from AbstractContext
rather than piecing things together
|
| iec | | InternalEventContext iec(Code) | | The InternalEventContext that we are wrapping. If
the context passed to us doesn't support it, no
biggie. We don't make it for them - since its a
user context thing, nothing gained by making one
for them now
|
| InternalContextAdapterImpl | | public InternalContextAdapterImpl(Context c)(Code) | | CTOR takes a Context and wraps it, delegating all 'data' calls
to it.
For support of internal contexts, it will create an InternalContextBase
if need be.
Parameters:
c - |
| getBaseContext | | public InternalContextAdapter getBaseContext()(Code) | | Returns the base context that we are
wrapping. Here, its this, but for other thing
like VM related context contortions, it can
be something else
The base context. |
| getInternalUserContext | | public Context getInternalUserContext()(Code) | | returns the user data context that
we are wrapping
The internal user data context. |
|
|