[xwiki-devs] [Vote] Create component API for skinx
Hi devs, I wanted to create a component to define the interface for the skin extension mechanism: @ComponentRole public interface SkinExtension { public void use(String resource); public void use(String resource, Map<String, Object> parameters); } in a module in platform/core called xwiki-skinx-api or xwiki-skinx-bridge-api and then implement it with ssx, jsx, ssfx, jsfx, ssrx, jsrx hints in the skinx plugin. Basically the implementation will do nothing else but grab the XWikiContext from the Execution, grab XWiki from there, get the plugin api and call the use function on it. This will be useful to write code that needs the skin extensions but doesn't want to depend on the core (macros, for example) and it will serve as a bridge towards the future implementation of the skinx plugin as a component. My +1 for the proposed interface in xwiki-skinx-api and the implementation in the plugin. WDYT? Thanks, Anca
What would it cost to completely replace the skinx module with components? Why not do that now? +0 otherwise for a xwiki-skin module that would include both skin APIs and skin extension ones. Thanks -Vincent On Jan 4, 2011, at 3:14 PM, Anca Luca wrote:
Hi devs,
I wanted to create a component to define the interface for the skin extension mechanism:
@ComponentRole public interface SkinExtension { public void use(String resource); public void use(String resource, Map<String, Object> parameters); }
in a module in platform/core called xwiki-skinx-api or xwiki-skinx-bridge-api
and then implement it with ssx, jsx, ssfx, jsfx, ssrx, jsrx hints in the skinx plugin. Basically the implementation will do nothing else but grab the XWikiContext from the Execution, grab XWiki from there, get the plugin api and call the use function on it.
This will be useful to write code that needs the skin extensions but doesn't want to depend on the core (macros, for example) and it will serve as a bridge towards the future implementation of the skinx plugin as a component.
My +1 for the proposed interface in xwiki-skinx-api and the implementation in the plugin.
WDYT?
Thanks, Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 01/04/2011 03:22 PM, Vincent Massol wrote:
What would it cost to completely replace the skinx module with components? Why not do that now?
I don't know exactly. What I know is that it takes me 3 hours, let's say, to wrap it. I looked a bit at transforming it into a component and it's not really straightforward (not for me at least). Since I needed this in order to be able to write my container and dashboard macros nicely without xwiki-core deps and especially to test them, and since I am, let's say, a bit in a hurry with the dashboard impl, and since this approach should not normally hurt anyone (if somebody wants to make it a component later, they can easily) I proposed it like this, since it matches my capabilities of expertise and time investment, at this point.
+0 otherwise for a xwiki-skin module that would include both skin APIs
remind me again what are the skin APIs... Thanks, Anca
and skin extension ones.
Thanks -Vincent
On Jan 4, 2011, at 3:14 PM, Anca Luca wrote:
Hi devs,
I wanted to create a component to define the interface for the skin extension mechanism:
@ComponentRole public interface SkinExtension { public void use(String resource); public void use(String resource, Map<String, Object> parameters); }
in a module in platform/core called xwiki-skinx-api or xwiki-skinx-bridge-api
and then implement it with ssx, jsx, ssfx, jsfx, ssrx, jsrx hints in the skinx plugin. Basically the implementation will do nothing else but grab the XWikiContext from the Execution, grab XWiki from there, get the plugin api and call the use function on it.
This will be useful to write code that needs the skin extensions but doesn't want to depend on the core (macros, for example) and it will serve as a bridge towards the future implementation of the skinx plugin as a component.
My +1 for the proposed interface in xwiki-skinx-api and the implementation in the plugin.
WDYT?
Thanks, Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jan 4, 2011, at 3:35 PM, Anca Luca wrote:
On 01/04/2011 03:22 PM, Vincent Massol wrote:
What would it cost to completely replace the skinx module with components? Why not do that now?
I don't know exactly.
What I know is that it takes me 3 hours, let's say, to wrap it.
I looked a bit at transforming it into a component and it's not really straightforward (not for me at least). Since I needed this in order to be able to write my container and dashboard macros nicely without xwiki-core deps and especially to test them, and since I am, let's say, a bit in a hurry with the dashboard impl, and since this approach should not normally hurt anyone (if somebody wants to make it a component later, they can easily) I proposed it like this, since it matches my capabilities of expertise and time investment, at this point.
+0 otherwise for a xwiki-skin module that would include both skin APIs
remind me again what are the skin APIs...
APIs that are currently in xwiki-core such as XWiki.getSkinFile(), etc and which in some future would need to be moved to a xwiki-skin module. Note: We haven't had an official discussion about this. I started putting some info here: http://dev.xwiki.org/xwiki/bin/view/Design/FrontEndArchitecture Thanks -Vincent
Thanks, Anca
and skin extension ones.
Thanks -Vincent
On Jan 4, 2011, at 3:14 PM, Anca Luca wrote:
Hi devs,
I wanted to create a component to define the interface for the skin extension mechanism:
@ComponentRole public interface SkinExtension { public void use(String resource); public void use(String resource, Map<String, Object> parameters); }
in a module in platform/core called xwiki-skinx-api or xwiki-skinx-bridge-api
and then implement it with ssx, jsx, ssfx, jsfx, ssrx, jsrx hints in the skinx plugin. Basically the implementation will do nothing else but grab the XWikiContext from the Execution, grab XWiki from there, get the plugin api and call the use function on it.
This will be useful to write code that needs the skin extensions but doesn't want to depend on the core (macros, for example) and it will serve as a bridge towards the future implementation of the skinx plugin as a component.
My +1 for the proposed interface in xwiki-skinx-api and the implementation in the plugin.
WDYT?
Thanks, Anca
On 01/04/2011 04:40 PM, Vincent Massol wrote:
On Jan 4, 2011, at 3:35 PM, Anca Luca wrote:
On 01/04/2011 03:22 PM, Vincent Massol wrote:
What would it cost to completely replace the skinx module with components? Why not do that now?
I don't know exactly.
What I know is that it takes me 3 hours, let's say, to wrap it.
I looked a bit at transforming it into a component and it's not really straightforward (not for me at least).
I agree. Here's what I found to be missing in order to make it a component: * ability to change the response content before it is served back to the client; plugins can do this by implementing endParsing; skin extension component implementations need to replace the "hook" (an XML comment in the HTML page header) with the corresponding import declaration * query document references (e.g. all documents that have skin extension objects attached) * get object numbers for class (e.g. iterate all skin extension objects attached to a given page) * create a XWiki class (e.g. create the skin extension XWiki classes) * query if a document has an object of class X with prop=value * get request parameter * get default wiki/space/page name
Since I needed this in order to be able to write my container and dashboard macros nicely without xwiki-core deps and especially to test them, and since I am, let's say, a bit in a hurry with the dashboard impl, and since this approach should not normally hurt anyone (if somebody wants to make it a component later, they can easily) I proposed it like this, since it matches my capabilities of expertise and time investment, at this point.
+1
+0 otherwise for a xwiki-skin module that would include both skin APIs
remind me again what are the skin APIs...
APIs that are currently in xwiki-core such as XWiki.getSkinFile(), etc and which in some future would need to be moved to a xwiki-skin module.
I guess this means moving http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-bridge/src/main... to xwiki-skin module? Should we also expose the various skin extension component implementations as script services and deprecate $xwiki.[skinx].use? Thanks, Marius
Note: We haven't had an official discussion about this. I started putting some info here: http://dev.xwiki.org/xwiki/bin/view/Design/FrontEndArchitecture
Thanks -Vincent
Thanks, Anca
and skin extension ones.
Thanks -Vincent
On Jan 4, 2011, at 3:14 PM, Anca Luca wrote:
Hi devs,
I wanted to create a component to define the interface for the skin extension mechanism:
@ComponentRole public interface SkinExtension { public void use(String resource); public void use(String resource, Map<String, Object> parameters); }
in a module in platform/core called xwiki-skinx-api or xwiki-skinx-bridge-api
and then implement it with ssx, jsx, ssfx, jsfx, ssrx, jsrx hints in the skinx plugin. Basically the implementation will do nothing else but grab the XWikiContext from the Execution, grab XWiki from there, get the plugin api and call the use function on it.
This will be useful to write code that needs the skin extensions but doesn't want to depend on the core (macros, for example) and it will serve as a bridge towards the future implementation of the skinx plugin as a component.
My +1 for the proposed interface in xwiki-skinx-api and the implementation in the plugin.
WDYT?
Thanks, Anca
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Anca Luca -
Marius Dumitru Florea -
Vincent Massol