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]