You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2001/12/21 13:14:22 UTC
Application Context
This is hyprid user/dev, so it's going to -user...
After using and thinking about the app contexts (new in 1.3-dev) to get it
documented so we can do a 1.3 release soon, I think we should make a change.
Currently, the API is
Velocity.setApplicationContext( Object )
and internally, a component can access this object via
runtimeServices.getApplicationContext();
The idea is to allow a channel for the application to talk to custom
components like loaders with whatever stuff, and an Object was used to keep
it entirely up to the app - we don't want to force anything goofy on the
apps.
Now, in doing some of the Struts integration work, I thought this was a
terrible decision, because since there is only one 'application context' per
application, you have to be really careful - if you want to pass objects to
more than one component (say a loader and a cache) then you need to make a
custom object that they both understand, or define a set of interfaces so
that each component can instanceof for the interface and then use the
methods it wants to.
So I propose we change it to
Velocity.setApplicationContext( String key, Object o );
And
runtimeServices.getApplicationContext( key )
And just implement with a map.
Then each component can have their own key, and things are separate.
Sound ok? Any better ideas?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Application Context
Posted by Martin Stepanek <ab...@wo.cz>.
> -----Puvodní zpráva-----
> Od: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Odesláno: 21. prosince 2001 14:12
> Komu: velocity-user@jakarta.apache.org
> Predmet: Re: Application Context
>
>
> Well, the point with the application context is that we (Velocity) don¹t
> want to inflict anything upon them (application developers).
> It's meant to
> be a transparent 'channel' between the app layer and custom core
> components.
> That's why it was a naked object at first.
Yes, it's perfect idea. I like it very much :o)
> But by making it a map, we really don't change that. It lets you put
> whatever you want into the map under whatever name you want, then you can
> implement whatever strategy you need for your components, and a more
> 'standard component' can have a published key, like in my case maybe the
> fully qualified class name to avoid collisions.
>
> Does the above address what you meant?
Yes, you're right. The only difference between your and my conception is
that the potential tree structure in your case starts one level higher than
the mine. And in my case I added some tools for manipulating it, but I admit
it isn't really necessary...
So, good luck! :o)
Martin
> > Btw. why the VelocityContext doesn't implement the Map interface?
>
> Oversight ? :) I think we can do that w/o any harm.... Hm. The new
> VelocityContext in 1.3 does take a Map as an arg as the backing
> store, so if
> you have a Map, you can give that to a VC at instantiation time...
>
> geir
>
> > Maybe it's stupid. Dunno. Only an unverified idea... :o)
> >
> > Regards
> >
> > Martin
> >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Strange behaviour with Tomcat 4.0.1 -- manager/reload
Posted by Thomas Åhlen <th...@obidobi.net>.
>
> Hm. I just downloaded a fresh 4.0.1, took the servlet_example2 code with a
> velocity-dep-1.3.jar and it worked as expected. I could do a manager
reload
> with no problems.
>
> I'll persue this w/ 1.2 and see what I can find out.
>
When you are at it check the memory usage to. I have problem with the tomcat
manager and reloading. Runs out of memory after lots of reloads. I haven't
had time to look in on that, have always thought it was my application ;).
Thomas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Strange behaviour with Tomcat 4.0.1 -- manager/reload
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/21/01 10:17 AM, "Martin Stepanek" <ab...@wo.cz> wrote:
> Hi all,
>
> I'm not quite sure if this is question for Velocity community or rather for
> Tomcat community. But maybe you'll have some idea.
>
> I use Velocity 1.2 rc 2 with Tomcat 4.0.1. After using the Tomcats
> manager/reload function Velocity suddenly can't locate the templates. It
> needs to remove the web application and reinstall and then it works well...
>
> Isn't it strange?
>
Hm. I just downloaded a fresh 4.0.1, took the servlet_example2 code with a
velocity-dep-1.3.jar and it worked as expected. I could do a manager reload
with no problems.
I'll persue this w/ 1.2 and see what I can find out.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Strange behaviour with Tomcat 4.0.1 -- manager/reload
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/21/01 10:17 AM, "Martin Stepanek" <ab...@wo.cz> wrote:
> Hi all,
>
> I'm not quite sure if this is question for Velocity community or rather for
> Tomcat community. But maybe you'll have some idea.
>
> I use Velocity 1.2 rc 2 with Tomcat 4.0.1. After using the Tomcats
> manager/reload function Velocity suddenly can't locate the templates. It
> needs to remove the web application and reinstall and then it works well...
>
> Isn't it strange?
>
That's really strange. There have been a couple of weird anecdotal things
about 1.2, some with Tomcat 4.0.1, some otherwise.
Can you send me your servlet code (direct to my private email if you want)
so I can reproduce and fix?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Strange behaviour with Tomcat 4.0.1 -- manager/reload
Posted by Martin Stepanek <ab...@wo.cz>.
Hi all,
I'm not quite sure if this is question for Velocity community or rather for
Tomcat community. But maybe you'll have some idea.
I use Velocity 1.2 rc 2 with Tomcat 4.0.1. After using the Tomcats
manager/reload function Velocity suddenly can't locate the templates. It
needs to remove the web application and reinstall and then it works well...
Isn't it strange?
Martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Application Context
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/21/01 10:56 AM, "Paulo Gaspar" <pa...@krankikom.de> wrote:
> Answer inline,
>
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>> Sent: Friday, December 21, 2001 3:50 PM
>>
>>> ...
>>>
>>> No please!!!
>>>
>>> Actually _maybe_ the Context interface is already just a bit overkill.
>>
>> It is a touch overkill. But we were talking about VelocityContext the
>> app-level class, not Context the interface.
>>
>> You don't have to use VelocityContext - nothing internally will
>> ever depend
>> on it's functionality.
>
> Ops, I understood you were talking about the Context interface. Sorry!
I was thinking that this was getting all confused -
Originally, this was about the application context, which is something
completely different. It's a per-engine 'thingy' that lets apps communicate
directly with things like loaders...
>
>
>>> The simpler the interface, the easier it is to back it up with any
>>> implementation the application decides on.
>>
>> That won't change.
>>
>>> Of course that for the primary Context (or whatever is the name of the
>>> context closer to the template) to support bean access, the #set and
>>> #foreach directives, it must at least be like this:
>>>
>>> public interface Context
>>> {
>>> public Object put(String key, Object value);
>>> public Object get(String key);
>>> public boolean containsKey(Object key);
>>> public Object remove(Object key);
>>> }
>>
>>
>> This really has nothing to do with #set() or #foreach()
>
> I assumed wrong then. But then why are put() and remove() necessary?
Some kind of mechanicals like that are necessary - I just meant that the
implementations of #set() and #foreach() weren't tightly bound to that
interface - you could replace it with something else.
But yes, you are right. #set() and #forach() need to modify the context. I
misunderstood your 'drift'.
>
>>> The extra bit:
>>> public Object[] getKeys();
>>>
>>> present in the current org.apache.velocity.context.Context seems to
>>> open interesting possibilities in terms of a potential functionality
>>> to dump all the context contents... but:
>>> - Is it really wise to provide such functionality?
>>> - It forces the context to also collect values from a inner context
>>> to have this functionality complete;
>>> - And then maybe some Context implementers do NOT want to provide
>>> such key list! A context could even be backed up by some weird
>>> registry that would not support iterating trough its keys.
>>>
>>> An alternative is for the Application programmer to provide such
>>> key list functionality trough a specific context implementation +
>>> an access bean, but I am not sure it should be "promised" by the
>>> interface.
>>
>> I sort of agree. A bit late though... And remember, an implementation
>> doesn't have to support 'inner' context if it doesn't want to... Nor does
>> then the inner have to support the method meaningfully if dangerous... The
>> context says nothing about chaining/wrapping.
>
> Of course. But making the interface shorter it is clearer what MUST be
> implemented when someone _wants_ to use a inner Context.
Right
>
>>>
>>>
>>> Moreover, maybe there should be a simpler InnerContext interface
>>> for the application programmers simply like this:
>>>
>>> public interface InnerContext
>>> {
>>> public Object get(String key);
>>> public boolean containsKey(Object key);
>>> }
>>>
>>> It is a minimal effort to back such interface.
>>
>> Except that any Context can be used as an 'innerContext'. Our interfaces
>> say nothing about inner contexts - that purely an application issue, an
>> 'invention' of the VelocityContext (well, the AbstractContext) and I think
>> we should leave it that way.
>>
>>
>>> Putting the data in the context would be implementation specific.
>>> For backward compatibility we would have:
>>>
>>> public interface Context extends InnerContext
>>> {
>>> public Object put(String key, Object value);
>>> public Object remove(Object key);
>>>
>>> // and according to such proposal a deprecated...
>>> /** @deprecated */
>>> public Object[] getKeys();
>>> }
>>>
>>>
>>> Now, I am not saying that Velocity is not good without this, but
>>> it looks a better design option to me.
>>>
>>
>> Maybe. I think that not baking the notion of inner context into
>> the context
>> API is cleaner, but I honestly haven't thought ever about doing
>> it the other
>> way, and will do so...
>
> Well, if the Context interface could shrink to what the InnerContext
> above has, one would be enough. But I see nothing wrong with the inner
> interface thing.
No but it would introducing into the 'core' Context something that has so
far been an application-level implementation.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Application Context
Posted by Paulo Gaspar <pa...@krankikom.de>.
Answer inline,
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Friday, December 21, 2001 3:50 PM
>
> > ...
> >
> > No please!!!
> >
> > Actually _maybe_ the Context interface is already just a bit overkill.
>
> It is a touch overkill. But we were talking about VelocityContext the
> app-level class, not Context the interface.
>
> You don't have to use VelocityContext - nothing internally will
> ever depend
> on it's functionality.
Ops, I understood you were talking about the Context interface. Sorry!
> > The simpler the interface, the easier it is to back it up with any
> > implementation the application decides on.
>
> That won't change.
>
> > Of course that for the primary Context (or whatever is the name of the
> > context closer to the template) to support bean access, the #set and
> > #foreach directives, it must at least be like this:
> >
> > public interface Context
> > {
> > public Object put(String key, Object value);
> > public Object get(String key);
> > public boolean containsKey(Object key);
> > public Object remove(Object key);
> > }
>
>
> This really has nothing to do with #set() or #foreach()
I assumed wrong then. But then why are put() and remove() necessary?
> > The extra bit:
> > public Object[] getKeys();
> >
> > present in the current org.apache.velocity.context.Context seems to
> > open interesting possibilities in terms of a potential functionality
> > to dump all the context contents... but:
> > - Is it really wise to provide such functionality?
> > - It forces the context to also collect values from a inner context
> > to have this functionality complete;
> > - And then maybe some Context implementers do NOT want to provide
> > such key list! A context could even be backed up by some weird
> > registry that would not support iterating trough its keys.
> >
> > An alternative is for the Application programmer to provide such
> > key list functionality trough a specific context implementation +
> > an access bean, but I am not sure it should be "promised" by the
> > interface.
>
> I sort of agree. A bit late though... And remember, an implementation
> doesn't have to support 'inner' context if it doesn't want to... Nor does
> then the inner have to support the method meaningfully if dangerous... The
> context says nothing about chaining/wrapping.
Of course. But making the interface shorter it is clearer what MUST be
implemented when someone _wants_ to use a inner Context.
> >
> >
> > Moreover, maybe there should be a simpler InnerContext interface
> > for the application programmers simply like this:
> >
> > public interface InnerContext
> > {
> > public Object get(String key);
> > public boolean containsKey(Object key);
> > }
> >
> > It is a minimal effort to back such interface.
>
> Except that any Context can be used as an 'innerContext'. Our interfaces
> say nothing about inner contexts - that purely an application issue, an
> 'invention' of the VelocityContext (well, the AbstractContext) and I think
> we should leave it that way.
>
>
> > Putting the data in the context would be implementation specific.
> > For backward compatibility we would have:
> >
> > public interface Context extends InnerContext
> > {
> > public Object put(String key, Object value);
> > public Object remove(Object key);
> >
> > // and according to such proposal a deprecated...
> > /** @deprecated */
> > public Object[] getKeys();
> > }
> >
> >
> > Now, I am not saying that Velocity is not good without this, but
> > it looks a better design option to me.
> >
>
> Maybe. I think that not baking the notion of inner context into
> the context
> API is cleaner, but I honestly haven't thought ever about doing
> it the other
> way, and will do so...
Well, if the Context interface could shrink to what the InnerContext
above has, one would be enough. But I see nothing wrong with the inner
interface thing.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Application Context
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/21/01 9:41 AM, "Paulo Gaspar" <pa...@krankikom.de> wrote:
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>> Sent: Friday, December 21, 2001 2:12 PM
>>
>>>
>>> Btw. why the VelocityContext doesn't implement the Map interface?
>>
>> ...
>>
>> Oversight ? :) I think we can do that w/o any harm.... Hm. The new
>> VelocityContext in 1.3 does take a Map as an arg as the backing
>> store, so if
>> you have a Map, you can give that to a VC at instantiation time...
>>
>> ...
>
> No please!!!
>
> Actually _maybe_ the Context interface is already just a bit overkill.
It is a touch overkill. But we were talking about VelocityContext the
app-level class, not Context the interface.
You don't have to use VelocityContext - nothing internally will ever depend
on it's functionality.
>
> The simpler the interface, the easier it is to back it up with any
> implementation the application decides on.
That won't change.
> Of course that for the primary Context (or whatever is the name of the
> context closer to the template) to support bean access, the #set and
> #foreach directives, it must at least be like this:
>
> public interface Context
> {
> public Object put(String key, Object value);
> public Object get(String key);
> public boolean containsKey(Object key);
> public Object remove(Object key);
> }
This really has nothing to do with #set() or #foreach()
> The extra bit:
> public Object[] getKeys();
>
> present in the current org.apache.velocity.context.Context seems to
> open interesting possibilities in terms of a potential functionality
> to dump all the context contents... but:
> - Is it really wise to provide such functionality?
> - It forces the context to also collect values from a inner context
> to have this functionality complete;
> - And then maybe some Context implementers do NOT want to provide
> such key list! A context could even be backed up by some weird
> registry that would not support iterating trough its keys.
>
> An alternative is for the Application programmer to provide such
> key list functionality trough a specific context implementation +
> an access bean, but I am not sure it should be "promised" by the
> interface.
I sort of agree. A bit late though... And remember, an implementation
doesn't have to support 'inner' context if it doesn't want to... Nor does
then the inner have to support the method meaningfully if dangerous... The
context says nothing about chaining/wrapping.
>
>
> Moreover, maybe there should be a simpler InnerContext interface
> for the application programmers simply like this:
>
> public interface InnerContext
> {
> public Object get(String key);
> public boolean containsKey(Object key);
> }
>
> It is a minimal effort to back such interface.
Except that any Context can be used as an 'innerContext'. Our interfaces
say nothing about inner contexts - that purely an application issue, an
'invention' of the VelocityContext (well, the AbstractContext) and I think
we should leave it that way.
> Putting the data in the context would be implementation specific.
> For backward compatibility we would have:
>
> public interface Context extends InnerContext
> {
> public Object put(String key, Object value);
> public Object remove(Object key);
>
> // and according to such proposal a deprecated...
> /** @deprecated */
> public Object[] getKeys();
> }
>
>
> Now, I am not saying that Velocity is not good without this, but
> it looks a better design option to me.
>
Maybe. I think that not baking the notion of inner context into the context
API is cleaner, but I honestly haven't thought ever about doing it the other
way, and will do so...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Application Context
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Friday, December 21, 2001 2:12 PM
>
> >
> > Btw. why the VelocityContext doesn't implement the Map interface?
>
> ...
>
> Oversight ? :) I think we can do that w/o any harm.... Hm. The new
> VelocityContext in 1.3 does take a Map as an arg as the backing
> store, so if
> you have a Map, you can give that to a VC at instantiation time...
>
> ...
No please!!!
Actually _maybe_ the Context interface is already just a bit overkill.
The simpler the interface, the easier it is to back it up with any
implementation the application decides on.
Of course that for the primary Context (or whatever is the name of the
context closer to the template) to support bean access, the #set and
#foreach directives, it must at least be like this:
public interface Context
{
public Object put(String key, Object value);
public Object get(String key);
public boolean containsKey(Object key);
public Object remove(Object key);
}
The extra bit:
public Object[] getKeys();
present in the current org.apache.velocity.context.Context seems to
open interesting possibilities in terms of a potential functionality
to dump all the context contents... but:
- Is it really wise to provide such functionality?
- It forces the context to also collect values from a inner context
to have this functionality complete;
- And then maybe some Context implementers do NOT want to provide
such key list! A context could even be backed up by some weird
registry that would not support iterating trough its keys.
An alternative is for the Application programmer to provide such
key list functionality trough a specific context implementation +
an access bean, but I am not sure it should be "promised" by the
interface.
Moreover, maybe there should be a simpler InnerContext interface
for the application programmers simply like this:
public interface InnerContext
{
public Object get(String key);
public boolean containsKey(Object key);
}
It is a minimal effort to back such interface.
Putting the data in the context would be implementation specific.
For backward compatibility we would have:
public interface Context extends InnerContext
{
public Object put(String key, Object value);
public Object remove(Object key);
// and according to such proposal a deprecated...
/** @deprecated */
public Object[] getKeys();
}
Now, I am not saying that Velocity is not good without this, but
it looks a better design option to me.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Application Context
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/21/01 7:42 AM, "Martin Stepanek" <ab...@wo.cz> wrote:
> Hi Geir,
>
> I hope it doesn't look like impertinence to suggest Velocity design when I
> have no insight into it. I will probably look like possessed by the idea of
> nested objects of all kind, but I really think it's a elegant solution to
> internal representation of more complex data structures... :o)
>
> Wouldn't it be applicable to this problem? The application context could
> serve as a root context with more complex tree structure of nested contexts.
> This structure could be as complex or as simple as desired. Or there could
> be only one context in plain cases.
>
> I think such Hashtable structure is something like internal and more
> effective analogy to XML DOM. You can easily extract arbitrary subtree from
> the tree, if you know the appropriate path to it. Especially, if the context
> would have some utility method to access subtree, something like Object
> get(String path) and put(String path, Object nested), where path could be in
> the form of "root.nested1.nested12" and the like.
Well, the point with the application context is that we (Velocity) don¹t
want to inflict anything upon them (application developers). It's meant to
be a transparent 'channel' between the app layer and custom core components.
That's why it was a naked object at first.
But by making it a map, we really don't change that. It lets you put
whatever you want into the map under whatever name you want, then you can
implement whatever strategy you need for your components, and a more
'standard component' can have a published key, like in my case maybe the
fully qualified class name to avoid collisions.
Does the above address what you meant?
>
> Btw. why the VelocityContext doesn't implement the Map interface?
Oversight ? :) I think we can do that w/o any harm.... Hm. The new
VelocityContext in 1.3 does take a Map as an arg as the backing store, so if
you have a Map, you can give that to a VC at instantiation time...
geir
> Maybe it's stupid. Dunno. Only an unverified idea... :o)
>
> Regards
>
> Martin
>
>> This is hyprid user/dev, so it's going to -user...
>>
>> After using and thinking about the app contexts (new in 1.3-dev) to get it
>> documented so we can do a 1.3 release soon, I think we should
>> make a change.
>>
>> Currently, the API is
>>
>> Velocity.setApplicationContext( Object )
>>
>>
>> and internally, a component can access this object via
>>
>> runtimeServices.getApplicationContext();
>>
>>
>> The idea is to allow a channel for the application to talk to custom
>> components like loaders with whatever stuff, and an Object was
>> used to keep
>> it entirely up to the app - we don't want to force anything goofy on the
>> apps.
>>
>> Now, in doing some of the Struts integration work, I thought this was a
>> terrible decision, because since there is only one 'application
>> context' per
>> application, you have to be really careful - if you want to pass
>> objects to
>> more than one component (say a loader and a cache) then you need to make a
>> custom object that they both understand, or define a set of interfaces so
>> that each component can instanceof for the interface and then use the
>> methods it wants to.
>>
>> So I propose we change it to
>>
>> Velocity.setApplicationContext( String key, Object o );
>>
>> And
>>
>> runtimeServices.getApplicationContext( key )
>>
>> And just implement with a map.
>>
>> Then each component can have their own key, and things are separate.
>>
>> Sound ok? Any better ideas?
>>
>>
>> --
>> Geir Magnusson Jr. geirm@optonline.net
>> System and Software Consulting
>> Be a giant. Take giant steps. Do giant things...
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Application Context
Posted by Martin Stepanek <ab...@wo.cz>.
Hi Geir,
I hope it doesn't look like impertinence to suggest Velocity design when I
have no insight into it. I will probably look like possessed by the idea of
nested objects of all kind, but I really think it's a elegant solution to
internal representation of more complex data structures... :o)
Wouldn't it be applicable to this problem? The application context could
serve as a root context with more complex tree structure of nested contexts.
This structure could be as complex or as simple as desired. Or there could
be only one context in plain cases.
I think such Hashtable structure is something like internal and more
effective analogy to XML DOM. You can easily extract arbitrary subtree from
the tree, if you know the appropriate path to it. Especially, if the context
would have some utility method to access subtree, something like Object
get(String path) and put(String path, Object nested), where path could be in
the form of "root.nested1.nested12" and the like.
Btw. why the VelocityContext doesn't implement the Map interface?
Maybe it's stupid. Dunno. Only an unverified idea... :o)
Regards
Martin
> This is hyprid user/dev, so it's going to -user...
>
> After using and thinking about the app contexts (new in 1.3-dev) to get it
> documented so we can do a 1.3 release soon, I think we should
> make a change.
>
> Currently, the API is
>
> Velocity.setApplicationContext( Object )
>
>
> and internally, a component can access this object via
>
> runtimeServices.getApplicationContext();
>
>
> The idea is to allow a channel for the application to talk to custom
> components like loaders with whatever stuff, and an Object was
> used to keep
> it entirely up to the app - we don't want to force anything goofy on the
> apps.
>
> Now, in doing some of the Struts integration work, I thought this was a
> terrible decision, because since there is only one 'application
> context' per
> application, you have to be really careful - if you want to pass
> objects to
> more than one component (say a loader and a cache) then you need to make a
> custom object that they both understand, or define a set of interfaces so
> that each component can instanceof for the interface and then use the
> methods it wants to.
>
> So I propose we change it to
>
> Velocity.setApplicationContext( String key, Object o );
>
> And
>
> runtimeServices.getApplicationContext( key )
>
> And just implement with a map.
>
> Then each component can have their own key, and things are separate.
>
> Sound ok? Any better ideas?
>
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Be a giant. Take giant steps. Do giant things...
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>