On Wed, Oct 27, 2010 at 09:26, Vincent Massol <vincent(a)massol.net> wrote: Why do you need to overwrite DefaultConverter if you already overwrite default implementation of TransformationManager ?

> 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