org.apache.velocity.context
Class InternalContextAdapterImpl
java.lang.Object
org.apache.velocity.context.InternalContextAdapterImpl
- Context, InternalContextAdapter, InternalEventContext, InternalHousekeepingContext, InternalWrapperContext
public final class InternalContextAdapterImpl
extends java.lang.Object
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.
$Id: InternalContextAdapterImpl.java,v 1.8.12.1 2004/03/03 23:22:54 geirm Exp $
context
(package private) Context context
the user data Context that we are wrapping
icb
(package private) InternalHousekeepingContext icb
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
(package private) InternalEventContext iec
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)
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.
containsKey
public boolean containsKey(Object key)
Indicates whether the specified key is in the context.
- containsKey in interface Context
key
- The key to look for.
- Whether the key is in the context.
get
public Object get(String key)
Gets the value corresponding to the provided key from the context.
- get in interface Context
key
- The name of the desired value.
- The value corresponding to the provided key.
getKeys
public Object[] getKeys()
Get all the keys for the values in the context
- getKeys in interface Context
put
public Object put(String key,
Object value)
Adds a name/value pair to the context.
- put in interface Context
key
- The name to key the provided value with.value
- The corresponding value.
remove
public Object remove(Object key)
Removes the value associated with the specified key from the context.
- remove in interface Context
key
- The name of the value to remove.
- The value that the key was mapped to, or
null
if unmapped.
Copyright B) 2002 Apache Software Foundation. All Rights Reserved.