18 Apr
2014
18 Apr
'14
noon
P.S.: While this proposal does not aim directly to remove existing
rendering context, it is obvious that the availability of a single
component based context will at the end make the existing
TransformationContext and MacroTransformationContext useless and obsolete.
So, in a second implementation step, we will phase it out, if everyone
agree.
Calling a transformation would then became: 1) Setting the appropriate
context, 2) launch the transformation (Macro.transform(<no args>))
You may see the first implementation step for rendering project in
https://github.com/dgervalle/xwiki-rendering/commit/ad36200cee87130d19f69a4…
On Tue, Apr 15, 2014 at 5:48 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
Hi devs,
In order to manage authorization access based on the signature of scripts,
I need to have better knowledge on which rendering is being processed at
any moment. The rendering is the one who knows the better the current
rendering status, so it is also the best place to feed the ExecutionContext
with the TransformationContext and the MacroTransformationContext.
Therefore, I would like to introduce a dependency
on xwiki-commons-context into xwiki-rendering-api.
Since xwiki-commons-context does not have any transitive dependencies, and
is part of commons, it should not be an issue.
This is not a proposal to remove the current usage of the rendering
contexts, it will not impose existing user of the rendering project to
embrace the EC at all.
If nobody complains, I am starting working on this now, so please comment
ASAP if you are against.
Thanks
--
Denis Gervalle
SOFTEC sa - CEO
--
Denis Gervalle
SOFTEC sa - CEO