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/java/org/xwiki/bridge/SkinAccessBridge.java 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
