xwiki-devs October 2008

xwiki-devs@xwiki.org

40 participants
133 discussions

[xwiki-devs] Selecting a tool to manage localization

by Ludovic Dubost

Hi team, I wrore a report about the different localization strategies we could have for XWiki comparing: - a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Lo… Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us. Let's discuss. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years, 1 month

[xwiki-devs] Rewriting the comments plug-in into a component

by Florin Ciubotaru

Hi devs, We currently have a comments plug-in that is written for a custom core. This plug-in enables us to have hierarchical comments and several storage implementations. The issue I encounter when rewriting it to a plexus component is that I cannot make it independent from the core. I need both read and write access to the storage, and I could not find a bridge to it. All I can do is retrieve data, with org.xwiki.bridge.DocumentAccessBridge and org.xwiki.bridge.DocumentModelBridge, but not write data. Does anybody know how can I write a component that needs read/write access to the storage without using XWiki,XWikiDocument and XWikiContext classes? Thanks, Florin Ciubotaru

16 years, 1 month

[xwiki-devs] [Proposal] Support use of local and external JS libs with JSX

by Jerome Velociter

Hello, Following the open question #1 here http://dev.xwiki.org/xwiki/bin/view/Design/SkinExtensions#HUsage " Open question 1: Should $jsx.useFile("filename.js") work for files located on the disk? This allows the same pull process to be used with files located in the skin, without requiring SX documents and objects. I'd say yes. Then, what should the URL look like? /xwiki/bin/jsx/skins/albatross/somestyle.css is OK? " I would like to propose to go even further, and to allow injection of script tags referring libraries on the cloud or on a different server using the jsx plugin. This would allow to not have users writing scripts tags in the body of the document to add a library. I would see something like : $jsx.use("http://maps.google.com/maps?file=api&v=2&key=XXX") or $jsx.useFile("http://maps.google.com/maps?file=api&v=2&key=XXX") What do you think ? Regards, Jerome.

16 years, 1 month

[xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros

by Jerome Velociter

Hello all, I started working on a {{map}} macro (http://jira.xwiki.org/jira/browse/XWIKI-2784). This raise the question of how (or if) we should work when writing macros depending on JS APIs (being here google maps, yahoo maps, etc.). The variants I've envisaged so far : 1a. We write all the needed JavaScript in the macro itself. We do it in Strings we transform in lists of WordBlock + SpaceBlock we append as children of a XMLBlock "script". I find this a little painful and not very natural. 1b. We write all the needed JavaScript in the macro itself. We do it in Strings we pass as content of a html/xhtml macros blocks. 2a. We write most of the JavaScript in a JSX object (for example a sort of facade to some google maps APIs), and only the needed calls in the macro itself (for example the call to load a map in a div element). For the code in the macro, we use the same strategy as 1a, except that there is just one of such XML block, and it's relatively short. The JSX Strategy in 2a/2b has that clear advantage to make it much simpler on the server side, but as a counterpart, the macro needs to be distributed as a xar + jar, while in 1) it's a jar only. 2b. Same as 2a using the strategy in 1b for the part in the macro. This is the way I have my prototype working right now. I admit I don't really know what to think about the fact I'm building macros blocks (a velocity one for the jsx "use" call, and a html one for the javascript call) inside the macro itself. I hope you can tell more about this, and let me know if it's a bad practice. 3. We don't do such macro :) We consider it's not what wiki macro should be and we decide to have such macros only as velocity macros which are much simpler to write in that case. This does not change anything for the wysiwyg users, as far as I understand, but it does for the wiki users.{{map location="Paris, France"}} is much more elegant than {{velocity}}#map("Paris, France"){{/velocity}} ; and is much better too in terms of configuration (in velocity we would need to give values to all parameters, even if we want to use default value for most of them). WDYT ? Are there some variants I did not envisage ? Regards, Jerome.

16 years, 1 month

[xwiki-devs] XWikiContext cloning

by Sergiu Dumitriu

Hi devs, We all know that the old XWikiContext is a burden that must still be carried around, in order to access any non-componentized functionality. The problem is that a context object is not supposed to be used by more than one thread. Example of non-threadsafe parts of the context are: - the Hibernate session - the request and response objects, cleared by the container - the velocity context - the XClass cache - the current wiki name - and maybe others This single-thread restriction is generally acceptable, since most of the code is executed in the single-threaded request-response workflow. Yet, some plugins execute in separate threads, for example the Lucene indexer and the scheduler plugin, and they need their XContext object. The current strategy is to clone the context and remove some of the dangerous elements listed above. This is not good, since: - it has to be done in every plugin that creates threads (duplication) - adding more non-threadsafe things to the context requires that all these plugins are changed - some non-threadsafe things might not yet be identified, and they surface sometimes as unidentified bugs - some things cannot be cleared from the outside (for example the XClass cache, which is a private member of the context) There are several solutions to this problem: 1. Override the clone() method to remove non-threadsafe elements from the cloned context. Pro: removes duplication Pro: establishes a safe clone method for all the codebase Con: some unsafe things might be overlooked, surfacing from time to time in rare thread inter-weaving. 2. Override the clone() method to create a blank context and only copy what needs to be part of any context. Pro: same as above, but also eliminates all possible non-threadsafe elements. Con: We might overlook something that needs to be part of the context. The advantage over option 1 is that this is always reproducible, and a simple stack trace is enough to spot the problem, unlike multithreaded issues. Con: We might introduce a regression, this needs to be tested well. 3. Override the clone() method to just eliminate non-threadsafe things that are unaccessible from outside (the XClass cache is the only one I see). Pro: keeps the current behavior, reducing the risk of regressions. Con: Doesn't really solve the problem. I'd go with option 2. Any other opinions? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 1 month

[xwiki-devs] Compass and Hibernate Search

by Vincent Massol

I think it would be nice to look at Compass (http://www.compass-project.org/overview.html ) or Hibernate Search (http://www.hibernate.org/410.html) for the future. I think Compass is better for us since we don't want to rely on Hibernate for our storage in the future. Here are some features of Compass: " - Simple Compass provides a simple API for working with Lucene. If you know how to use an ORM, then you will feel right at home with Compass with simple operations for save, and delete & query. - Lucene Building on top of Lucene, Compass simplifies common usage patterns of Lucene such as google-style search, index updates as well as more advanced concepts such as caching and index sharding (sub indexes). Compass also uses built in optimizations for concurrent commits and merges. - Mapping Compass provides support for mapping of different data "formats" - indexing and storing (caching) them in the Search Engine: Object to Search Engine Mapping (using annotations or xml), XML to Search Engine Mapping (using simple xpath expressions), and the low level Resource to Search Engine Mappping. - Tx Compass provides a transactional API on top of the Search Engine supporting different transaction isolation levels. Externally, Compass provides a local transaction manager as well as integration with external transaction managers such as JTA (Sync and XA), Spring, and ORM ones. - ORM Compass integrates seamlessly with most popular ORM frameworks allowing automatic mirroring, to the index, of the changes in data performed via the ORM tool. Compass has generic support for JPA as well as embedded support for Hibernate, OpenJPA, TopLink Essentials, and EclipseLink allow to add Compass using three simple steps. - Spring Compass integrates seamlessly with Spring. Compass can be easily configured using Spring, integrates with Spring transaction management, has support for Spring MVC, and has Spring aspects built in for reflecting operations to the search engine. - Distributed Compass simplifies the creation of distributed Lucene index by allowing to store the Lucene index in a database, as well as storing the index simply with Data Grid products such as GigaSpaces, Coherence and Terracotta. " The last point is especially important for our distributed lucene searcg feature developed during the GSOC. Thanks -Vincent

16 years, 1 month

[xwiki-devs] Adding MS Office integration project to jira

by Florin Ciubotaru

Hi devs, We need to create a jira project for the MS Office integration. Jerome has proposed to put in "XWiki Core & Products" section, with the "*XOFFICE*" key. WDYT? The first Add-in in the suite will be the Word Add-in and is currently named *XWriter*( XWord is another option). I target the first milestone release on November 19th, and a first final version somewhere around XE 1.8 final release date. The solution also contains a project named *XWikiLib*. This is an assembly that will contain most logic for the server connection and other utilities. It might be useful for other members of the community that may want to connect to XWiki from a .NET client. Regards, Florin Ciubotaru

16 years, 1 month

[xwiki-devs] Windows Live ID Becomes an OpenID Provider

by Markus Lanthaler

Hi there, Microsoft just announced at the PDC that Windows Live ID becomes an OpenID Provider [1]. This will create millions of new OpenID users to the already existing ones of Yahoo, AOL, Blogger, Flickr, and so on. I can hardly wait to see my OpenID support to be integrated into the next XWiki release :-) Cheers, Markus [1] http://dev.live.com/blogs/devlive/archive/2008/10/27/421.aspx

16 years, 1 month

[xwiki-devs] Syntax 2.0 - one macro, several implementations

by Jerome Velociter

Dear devs, Regarding XWIKI-2784 (Create a {{map}} macro for XWiki Syntax 2.0), I'd like to discuss the way I should go to have several implementations available for the same macro. The idea is for one to be able to chose a map provider (google, MS live, yahoo, etc.). From a syntax point of view, there are 2 possibilities : 1. Using a parameter : {{map service="google" .../}} 2. Using aliases for the macro {{livemap .../}} (and 3. supporting both) For 2. we could implement one macro per supported service, all of them using the same parameters bean. There might be some redundant code though, that would need to be extracted in a common class (for example the code to generate the proper JS call according to the parameters, as I plan to have a common JS interface for all services, and load the proper one according to the service requested). For 1. (or for 3.) I guess it would mean a unique macro class entry point. Then a possibility I discussed with Thomas could be to have a component interface for generating blocks for a map (MapProvider, or something like this), and one implementation of that component per service. The macro would then lookup for the proper implementation according to the alias used or the parameters used. WDYT ? Do I miss something there ? Jerome.

16 years, 1 month

[xwiki-devs] [Proposal] WYSIWYG 1.7 Roadmap

by Marius Dumitru Florea

Hi there, Here's the roadmap I propose: * Fix current issues ** Write Selenium tests for all current features (JV). ** Provide a Range/Selection implementation for IE. (fixes XWIKI-2737, XWIKI-2738, XWIKI-2739). One option is to wrap this JavaScript code http://jorgenhorstink.nl/2006/07/05/dom-range-implementation-in-ecmascript-… . I have Jorgen's permision to use his code. This will save me from implemeting it by myself (which is the second option). The third option is to use the selection support from rocket-gwt library ( http://code.google.com/p/rocket-gwt/wiki/Selections ), which is limited right now. I'm waiting for an answer regarding their roadmap. 24 man-hours ** Reimplement list support. (fixes XWIKI-2734). The default implementation doesn't wrap nested lits in a list item element and fails to detect the presence of a list when the cursor is on a list item with a nested list inside (generated by the wiki editor). Indent/outdent for nested lists have to be reimplemented also. 16 man-hours ** Improve history mechanism (fixes XWIKI-2731). I should restore the previous selection on Undo/Redo. Right now, only the cursor position is restored. 8 man-hours ** Reimplement the heading (using id's and possibly named anchors) and improve the Format plugin (by adding Inline and Paragraph options besides Title X). 8 man-hours ** Fix horizontal rule generation. (fixes XWIKI-2729) 2 man-hours ** Fix Insert Symbol features so it won't require any special encoding. (fixes XWIKI-2669) Right now I have no idea on how fix this. 6 man-hours ** Use the same styling in edit mode as in view mode. (fixes XWIKI-2721). I have to check what CSS rules from the Toucan style sheet messes up the editor. 8 man-hours ** Fix cursor issues (navigation through empty DOM nodes using arrow keys; avoid cursor hiding when the user clicks on an empty DOM element). 8 man-hours ----- Total: 80 man-hours // 1.7M1 * Integrate (& revisit) implemented features ** Justify (left, center, right, full) 3 man-hours ** Font (family, size) 3 man-hours ** Color (background, foreground) 3 man-hours * Implement new features ** Teletype text. I have to discuss this with Vincent because there are two use cases. 16 man-hours. ** Definition lists. Currently there's no support at all. 22 man-hours ** Clear inline formatting. 2 man-hours ** Insert/Edit/Remove Link. I have to extend the built-in command "createlink" for our custom wiki link. We have to implement one big tabbed-dialog for insertion and the link inspector. We also need to implement the remote services for retrieving wiki, space, page, attachment names, as well as comments and history. 8+32 man-hours ** Insert/Edit Image. We have to implement the insert dialog and the image inspector. We also need to implement the remote services for uploading and retrieving images as/from attachments. 24 man-hours ** Insert/Edit Table. We have to implement the insert dialog and the table inspector. 24 man-hours ** Insert/Edit Macro. We have to implement the insert dialog and the macro inspector. 24 man-hours ----- Total: 161 man-hours // 1.7RC1 * Pending features (in case we finish all the above) ** Full screen editing. I have to investigate this more, so I'm not sure about the effort. 24 man-hours ** Paste/Import Office document fragments. Requires catching the paste event and some on-server clean-up. We may also need an insert dialog. 16 man-hours, provided the server part is already done. ** Find & Replace. 24 man-hours ----- Total: 64 man-hours As you can see there are plenty of things to do. We have to finish them before Javapolis. Thanks, Marius

16 years, 1 month

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2008