org.apache.velocity.context
Class InternalContextAdapterImpl
public final
class
InternalContextAdapterImpl
extends Object
implements InternalContextAdapter
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.
Version: $Id: InternalContextAdapterImpl.java,v 1.8.12.1 2004/03/03 23:22:54 geirm Exp $
Author: Geir Magnusson Jr.
the user data Context that we are wrapping
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
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
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.
public boolean containsKey(Object key)
public Object get(String key)
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
public String getCurrentTemplateName()
public
Context getInternalUserContext()
returns the user data context that
we are wrapping
public Object[] getKeys()
public Object[] getTemplateNameStack()
public void popCurrentTemplateName()
public void pushCurrentTemplateName(String s)
public Object put(String key, Object value)
public Object remove(Object key)
public void setCurrentResource(
Resource r)
Copyright B) 2002 Apache Software Foundation. All Rights Reserved.