Hi Sergiu, On Sep 1, 2008, at 9:07 AM, Sergiu Dumitriu wrote:
> Vincent Massol wrote: >> 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. 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. >> 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? Yes it could be used and the VelocityService thing above could be implemented as a VelocityContextInitializer. >> 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. 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
