7 Jan
2011
7 Jan
'11
9:29 a.m.
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/mai…
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs