27 Oct
2010
27 Oct
'10
9:26 a.m.
Hi devs,
I'm changing my mind (after trying to implement the proposal below). The new proposal
is:
* Introduce a XWikiTransformationManager implementation (hint = "default"),
located in xwiki-rendering-xwiki. It overrides the DefaultTransformationManager impl.
* DefaultTransformationManager will continue to exist and be part of the rendering-api
module (and runs all transformation it can find). It's useful when running the
rendering in standalone mode.
* Introduce a RenderingConfiguration named: rendering.transformations with default values
= macro, icon
* Introduce XWikiConverter implementation (hint = default) also located in
xwiki-rendering-xwiki and which also overrides the one in rendering-api
Right now I don't think we need other transformation lists but it's easy to add
new implementations if we need and they could even be located outside of the rendering
module if we think it's best. rendering.transformations will be considered as a
generic filtering of transformations.
Thanks
-Vincent
On Oct 26, 2010, at 5:01 PM, Vincent Massol wrote:
Hi,
Requirement
==========
UC1: ability to package transformations in the platform that are not enabled by default
(for ex WikiWordTransformation)
UC2: ability in the future to install a new transformation using the extension manager
and make it active without restarting xwiki (and without complex operations to activate
it)
UC3: ability to have a list of transformations active in a given part of the xwiki code
and another list in another part of the code
Proposal
=======
* Introduce a XWikiTransformationManager implementation (hint = "xwiki"),
located in xwiki-core/
* Make it use CoreConfiguration and introduce core.viewTransformations configuration
properties (in some future we'll have a separate module to perform page rendering -
The rendering module is about rendering content not pages). Ex: core.transformations =
macro, icon (values are role hints)
* Default property value would be: macro, icon
* DefaultTransformationManager will continue to exist and be part of the rendering module
(and runs all transformation it can find). We could decide to remove it at some point if
we don't see any value although it could stay as an example implementation in the
rendering module (which can be used standalone).
This proposal solves UC1 and UC3. It's less clear how it can solve UC2.
When the extension manager is available we could simply remove this configuration
property and simply "deactivate" a given transformation, thus making it
inactive. I believe this will be the best practice in the future for
activating/deactivating (set of) components. There could be 2 ways: making it not part of
the classloader and/or telling the component manager to unregister/register a component.
Thus I believe this proposal is good enough for now.
WDYT?
Thanks
-Vincent