On Jan 31, 2008, at 10:45 AM, rssh wrote:
On Thu, 31 Jan 2008 10:05:52 +0100, Vincent Massol
wrote
On Jan 31, 2008, at 9:58 AM, rssh wrote:
On Thu, 31 Jan 2008 09:13:32 +0100, Vincent
Massol wrote
On Jan 31, 2008, at 7:41 AM, rssh wrote:
> On Wed, 30 Jan 2008 23:24:21 +0100, Sergiu Dumitriu wrote
>> Hi,
>>
>> Velocity tools is not enabled yet. However, this is planned (I
>> was
>> about to do it in the 1.2 timeframe, but didn't have time to
>> commit
>> the code).
>>
>
> O - are you have ready patch ?
> If yes, can you publish one ?
>
> (I now need in velocity tools, so I can test this patch on 1.3
> SNAPSHOT)
It's very simple. You just need to add the MathTool java bean
instance to the velocity context and you're done! No need for
velocity tools servlet or stuff like that.
-Vincent
Yes, but if we want more generalized stuff, than sintuation become a
little
more complex:
I think the 'right way' is to keep somewehere static instance of
ToolManager,
create and configure one from some well-known path (better
configurable) on
demand, than in VelocityRendere.prepareContext() merge new-created
context
with context of ToolManager.
(of course, if we want provide standard velocity-tool services,
which can be
externally configured)
The main reason I haven't been touching this part is because I've
written a new Velocity component in the new xwiki architecture and
I'd like to replace our current velocity code with it. The
component is in xwiki-core/xwiki-velocity if you want to have a
look.
My idea would be to provide component configuration that allows
users to add any bean they want to the velocity context.
WDYT?
Nice.
I looked in xwiki-velocity and was not able to figure: what is it. Now
understood that it is just not finished ;)
exactly...
Functionality you tell about is exactly a ToolManager
in
VelocityTools 2.0:
it read class name from configuration, get through reflection
annotation
'DefaultKey', than add tool to context (in application scope).
I guess, that you have implementation plan like next:
Step 1.
1.1. add to VelocityManager method 'createContext' (or initialize
existing
context), which will create
Yes exactly.
1.2. call VelocityManager.createContext from
VelocityRendere.prepareContext()
Yes and anywhere the code needs to get either a velocity engine object
or a base velocity context.
(it's means that classes must be moved to
xwiki-core package ?)
Not sure what you mean xwiki-core since it's already in xwiki-core. Do
you mean moving it into a component? If so the answer is yes....
eventually since all xwiki-core/ code will be eventually moved to
components. See
http://dev.xwiki.org/xwiki/bin/view/Design/ArchitectureV2
for more information.
Since this is big work we'll need to do it slowly piece by piece.
1.3. add configure method to VelocityManager, which
will read name
of classes
and keys from some property or configuration (and may be, if key is
not
configurated -- use some analog of DefaultKey annotation, which we
than change
to org.apache.velocity.tools.config.DefualtKey when
VelocityTools-2.0 will be
released)
Yes.
I don't know about VelocityTools v2.0.
But yes, the idea is for the moment to use the definition in
components.xml and later to use XWiki's Configuration service when
it's there. This is one service I need to work on since it'll be
needed by almost every components.
release this as snapshot.
Step 2.
4. for plugins: may be velocity-aware plugins want to add some
objects or
macroses to default velocity context, than add velocity context
initialization
callback to plugin interface.
release this as snapshot.
For the moment the plan is to continue putting the velocity context
into the XWiki Context so any code (plugins or other code) requiring
the velocity context can get it from the XWiki Context.
And what a time frame ? Can I help in something ?
(for example by
writing
1.1,1.2,1.3 and submitting a patch)
Time frame is ASAP so if you can help that's great.
Re 1.3 please do something similar that is already done for
configuring the velocity engine.
Thanks!
-Vincent
[snip]