1 Sep
2008
1 Sep
'08
9:21 a.m.
Hi Sergiu,
On Sep 1, 2008, at 9:07 AM, Sergiu Dumitriu wrote:
Yes it could be used and the VelocityService thing above could be
implemented as a VelocityContextInitializer.
I'm experimenting with this. The first step is refactoring the current
introspector package to make uberspector components. I have sent you a
patch for this for review + some questions since I'm not sure why we
have both chainable and linking implementations.
Thanks
-Vincent
Vincent Massol wrote:
This is not true. First there won't be any "core" module in the future
so that's only a immediate concern. However even if you have
components that depen on core that'll still work since maven will know
which they are and build them before core.
Hi devs,
Right now we have:
platform/
|_ core/
|_ xwiki-core/
|_ (others)/
|_ plugins/
|_ ...
The problem I see is twofold:
1) We can have platform components that are not core components (for
example I'd like to commit the office component done by Wang Ning).
2) I'd like that we decide to deprecate the plugins/ system going
forward and that all new code only write components.
For 1) I'd like to propose:
platform/
|_ components/ (contains (others)/ from above)
|_ core/ (is the core/xwiki-core from above, to be removed once
fully split into components)
|_ plugins/ (to be removed once fully split into components)
|_ ...
+1. This means that we can't normally have components that depend on
the
core, since when building the whole trunks, the component will be
built
before the core, which is a pre-dependency. But this is a good
restriction, anyway. For 2) I'd
like to propose:
* Create an interface for Velocity APIs. Something like
VelocityBridge
(or VelocityAccess or VelocityApi or...). It would be empty.
* Each component that want to be accessed from velocity will need to
implement a component implementing VelocityBridge. It'll have a role-
hint being the name under which it'll be access from Velocity.
* Create a VelocityService class (component) which has a single
get(String name) method and which uses the ComponentManager to look
up
components which implement VelocityBridge using the name as the role
hint.
* Put that VelocityService in the Velocity context under the name
"services".
This looks good. However, what will happen with the
VelocityContextInitializer component? Is it to be used only for
special
purposes, like setting the $doc variables, the $services and other
essential elements? In practice
this means that users will be able to access all our
components through the VelocityBridge implementations with a syntax
like:
$services.office.convert(...)
$services.translation.translate(...)
...
Note1: We would need to be careful that it would be forbidden for any
java code to use a VelocityBridge. This is to ensure all code logic
is
put into components and not into the bridges. We should use the maven
enforcer plugin to enforce this rule.
Note2: This means we'll have 2 APIs to maintain: the velocity one
(the
bridges) + the "Java"' one (the main components). But I don't see any
other way...
I still prefer the automatic velocity API exposure from the actual
java
class, using annotations and uberspectors.