- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Discussion] Annotations feature current state and roadmap
by Anca Luca 20 Oct '09

20 Oct '09

Hello devs, The current state of the annotation feature in the sandbox can be described by the follwing: * there is a single type of annotation which can be added, using a specific javascript client backed by a rest service. Such an annotation contains an annotation text, the annotated content and its position and this type is highly coupled in the plugin implementation * the backing annotation storage is based on components, currently with an XWiki objects implementation but a different service can be easily created (there is one implemented for Scribo annotations stored in RDF) * for the moment, only xwiki documents and feed entries fetched by the feedreader plugin can be used as targets for annotations (the annotated documents), with the restriction that the content of the document is *not* generated using scripting. A component can be implemented for a new type of document but the current UI (the javascript client) is *specific to xwiki documents* * the javascript client (UI) is only in the state of a prototype: while proving that it works, it is not robust enough and the user experience is poor * annotation creation algorithm seems to perform well in practice, but we should put it to more real-world test (by releasing). Some *requirements* in terms of functionality, in order to make this an extensible and flexible feature, would be to: * be able to have different types of annotations (one to be able to easily specify fields for the annotations to add), with storage as xwiki objects. This needs to be flexible at all levels: UI and storage backend, preferably using xwiki scripting (no jars on the server side, or java coding) so that it can be easily customized. Also, the annotation UI should be thought of as easy to customize and create whatever forms and actions in a light manner. * be able to annotate any type of document (object inside such a document), namely all or any number of text fields in such an object. Preferably this should also be doable only using xwiki scripting or configuration. I would like to propose the following road to perfect this feature: *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs) The aim would be to take feature out of sandbox preserving its current features: allowing to add a specific type of annotation saved as XWiki object on a regular, non scripted XWiki Document. We should: - format, improve comments, generally clean up the current code sandbox to match XWiki coding styles - refactor packages and components to remove some dependencies issues and increase flexibility - simplify flow, stripping out all code which is not strictly needed by the targeted functionality (such as the Feed entry handling code), and make it easily implementable by a component in a distinct jar (so that the Scribo requirements currently implemented can be preserved) - finish the javascript client: robust user interaction, intuitive interface, cleaned up integration with XE - ensure quality assurance process by a well setup battery of tests, unit and functional At this point I propose to have the annotation feature as an installable plugin but not included by default in XE, unless after a few bugfixing cycles. *Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of next year) * first iteration on the 2 desired features. At this point one should be able to configure the type of annotation to add, UI should be accomodate this type, backing XWiki storage should be easy to integrate with any annotation storage service (for Scribo requirements), and one should easily set a field in a structured document which would support annotations. (Note that this might require heavy rewrite / refactor of the 1.0 version. We could decide to skip it and go straight to this version, but it would take longer.) * integration of Scribo requirements can be met at this point by setting the configurations according to the Scribo annotation type and target requirements. At this point, if we find appropriate, we could make the decision of including the annotation feature in XE by default *Version 1.2* (future) * finish the 2 requirements, integration with Scribo would be done in the same manner, by specific configuration and storage backend specific implementation. What do you think? For the moment I will focus on version 1's tasks while finding a good architecture to achieve the desired requirements, converting, where necessary, the direction of the development towards that goal. Thanks (for reading this very long mail), Anca

6 16

[xwiki-devs] XWikiRemoteServiceServlet for component based GWT RPC services
by Marius Dumitru Florea 20 Oct '09

20 Oct '09

Hi devs, Following http://stuffthathappens.com/blog/2009/09/14/guice-with-gwt/ I've made a simple servlet that dispatches GWT requests to corresponding components. Here's the code: public class XWikiRemoteServiceServlet extends RemoteServiceServlet { public String processCall(String payload) throws SerializationException { try { RPCRequest req = RPC.decodeRequest(payload, null, this); RemoteService service = (RemoteService) Utils.getComponent(req.getMethod().getDeclaringClass()); return RPC.invokeAndEncodeResponse(service, req.getMethod(), req.getParameters(), req .getSerializationPolicy()); } catch (IncompatibleRemoteServiceException ex) { log("IncompatibleRemoteServiceException in the processCall(String) method.", ex); return RPC.encodeResponseForFailure(null, ex); } } } I tested it with the new MacroService component (to be committed in WYSIWYG code) and it works great. I'm wondering where to place this servlet since it's generic and should be used by all GWT applications that use services. I'm hesitating to place it in web/gwt because I think this is "new" code, component oriented while the gwt module depends on the old xwiki-core. Another question is if it's OK to use Utils.getComponent(Class) or should we find a way to inject the component manager. They use a GuiceFilter to do this in the tutorial I pointed out. WDYT? Thanks, Marius

1 0

[xwiki-devs] Technical debt is increasing, let's fight it
by Vincent Massol 20 Oct '09

20 Oct '09

Hi, We now have the second run of sonar on xwiki at http://nemo.sonarsource.org/timemachine/index/178319 As you can see it's not going in the right direction and the technical debt is increasing. Even though I have been fixing several findbugs errors so it means even more were added... Can we make an effort to put it back on track and ensure it's going to be decreasing for the next run on next Monday? Thanks -Vincent

1 0

[xwiki-devs] [Proposal] Create xwiki-gwt-diff module
by Marius Dumitru Florea 20 Oct '09

20 Oct '09

Hi devs, The diff package from the WYSIWYG editor source is used only by the sync (real time) plugin and it's suppose to be generic. I propose to move this package outside of the WYSIWYG editor in a separate module: platform/web/xwiki-gwt-diff The package will become: org.xwiki.gwt.diff.* You can see the sources here http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/wysiwyg/src/main/java… Here's my +1. WDYT? Thanks, Marius

4 5

[xwiki-devs] [Proposal] Rename platform/gwt module to platform/xwiki-gwt-api
by Marius Dumitru Florea 19 Oct '09

19 Oct '09

Here's my +1. WDYT? Thanks, Marius

2 3

[xwiki-devs] [Proposal] Rename platform/web/wysiwyg module to platform/web/xwiki-gwt-wysiwyg
by Marius Dumitru Florea 19 Oct '09

19 Oct '09

In addition I'd like to changed the package from: com.xpn.xwiki.wysiwyg.* to org.xwiki.gwt.wysiwyg.* Here's my +1. WDYT? Thanks, Marius

2 2

[xwiki-devs] BoldTest.testTimeComplexity() generates StackOverflow error
by Vincent Massol 19 Oct '09

19 Oct '09

Hi Sergiu, Could you have a look at BoldTest.testTimeComplexity(). It generates a stackoverflow error in the console: java.lang.StackOverflowError at java.util.regex.ASCII.isType(ASCII.java:185) at java.util.regex.Pattern$Ctype.isSatisfiedBy(Pattern.java:3444) at java.util.regex.Pattern$CharProperty$1.isSatisfiedBy(Pattern.java: 3337) at java.util.regex.Pattern$CharProperty.match(Pattern.java:3345) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) at java.util.regex.Pattern$Behind.match(Pattern.java:4648) at java.util.regex.Pattern$LazyLoop.match(Pattern.java:4353) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227) at java.util.regex.Pattern$BranchConn.match(Pattern.java:4078) at java.util.regex.Pattern$Curly.match2(Pattern.java:3821) at java.util.regex.Pattern$Curly.match(Pattern.java:3748) at java.util.regex.Pattern$Branch.match(Pattern.java:4114) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) Thanks -Vincent

1 0

Re: [xwiki-devs] GWT tree Interact with WYSIWYG editor
by Leon Wang 19 Oct '09

19 Oct '09

Hi Marius, Since the first approach which is "1) edit the wysiwyg_createEditor velocity macro from macros.vm" is simpler, I will modify macros.vm. You said "new WysiwygEditor($jsVarName); with something like window["${fieldId}_editor"] = new WysiwygEditor($jsVarName);" Could you please explain briefly what does "window["${fieldId}_editor"]" mean? What is it for? Is it a function of javascript? In the macros.vm I found "Wysiwyg.onModuleLoad(function() {new WysiwygEditor($jsVarName); $jsVarName = undefined;});", I did not find any "window" stuff. So after the first step, I got the reference, is the reference stored in window["${fieldId}_editor"] variable? Since don't depend at all on WYSIWYG Java code is not possible and do not bring you more work, I think should go with "i) access the editor in Java (GWT) code by writing a simple native getter". For the code you provided "editorJSReference.@com.xpn.xwiki.wysiwyg.client.editor.WysiwygEditorApi::editor;" I never saw code like this, is the @ for Java annotation or Component? Is there any document I can read to learn about the related rationale/knowledge? 'cause I have no clue what it means. So this line will return the WYSIWYG editor's reference restored/declared in the macros.vm file? I tried to add a new page in the draft document for Loading GWT in Xwiki page, It seems I can't add new page, only editing existing document. Should I add something behind your "Writing GWT applications in XWiki", so you could create a new one or something else. If there are work I can do to save your time or to make Xwiki better, feel free to assign me the work. I am more than happy to help. Thank you for taking your time to help me! -Leon

2 1

[xwiki-devs] Duplications & debt - REST/XMLRPC and WebDAV
by Vincent Massol 19 Oct '09

19 Oct '09

Hi Asiri, I see there's 10% of code duplication in the webdav module: http://nemo.sonarsource.org/project/index/181898 This is the highest of all modules. Do you think you could have a look? Second worst is REST with 5% http://nemo.sonarsource.org/components/index/178319 In term of technical debt, WebDAV module is also high with 9.5% and the highest is the XMLRPC module with 12.2%. Thanks -Vincent

4 5

[xwiki-devs] Meeting Manager Annoucement
by Ludovic Dubost 18 Oct '09

18 Oct '09

Hi, We have published the Meeting Manager application which has been sponsored by "Groupe Glon". The meeting manager is an XWiki 2.0 application which allows to plan and manage meetings and meeting cycles. It's a very nice and complete application. You can plan your meeting by setting an agenda, adding participants and propose a vote for meeting dates (a little like Doodle). You can then write your meeting notes. You can download the Meeting manager application here: http://code.xwiki.org/xwiki/bin/view/Applications/MeetingManagerApplication For developers, the source code is available here: http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwiki-application-m… Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

1 0