xwiki-devs November 2011

xwiki-devs@xwiki.org

32 participants
69 discussions

by Ludovic Dubost

Hi, I will be in London tomorrow until thursday. We will be (with Guillaume Lerouge) at the Online Information Show at the National Hall, Olympia ( http://www.online-information.co.uk/) If there are some XWiki users that would like to meetup in London either Tuesday or Wednesday night, please give ring us. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years

[xwiki-devs] Java Panel Macro Contribution

by Guillaume Sauthier (Objectweb)

Hi all Some weeks ago, I've been discussing in IRC with Thomas and Vincent about contributing a {{panel}} macro that could be used to replace the old velocity #panelHeader()/#panelFooter() macro... I've pushed that code into github : https://github.com/sauthieg/xwiki-panel-macro ATM, it probably has less features than the old velocity stuff, but I'm sure it is a good starting point if you want to move to a Java-based panel macro. The code is tested using the XWiki Test Runner. So if you're interested in that code, I'll be happy to re-contribute it to XWiki. Any thoughts ? --Guillaume

13 years

[xwiki-devs] [idea] Need link to sheet when editing a page which is displayed by a sheet

by Vincent Massol

Hi (Marius), With the new powerful sheet system it's now very hard to know where is located the sheet used to display the page (it's magical now ;)). Thus I think that when editing a page in wiki/wysiwyg edit modes we need to display a link to edit the sheet used to display the page, in the Document Information panel. WDYT? Thanks -Vincent

13 years

[xwiki-devs] Call for review thread safety new Component Manager

by Thomas Mortagne

Hi guys, I'm trying to reduce the enormous number of lock done by the current implementation of Embedded Component Manager and I could use some more brains to check what I did. You can find the new version on https://github.com/xwiki/xwiki-commons/blob/feature-improvecm/xwiki-commons… Quick comparison with the current one: * removed all "synchronized (this)" that was in pretty much all the methods and which made the CM block everything whenever anyone was using it * used ConcurrentHashMap to securize the insertion/search of components * basically the only remaining explicit lock is on singleton component initialization mostly to make sure we don't initialize the same component at the same time If you find some small modification to improve a bit the speed don't hesitate too. There is possible improvements to speed up lookuplist and lookupmap (not going though the whole map basically) but it require important refactoring and I would prefer not doing too much things at once since it's a pretty critical peace of code and locking is the main issue right now. Thanks, -- Thomas Mortagne

13 years

Re: [xwiki-devs] [xwiki-users] [Announcement] XWiki Enterprise and XWiki Enterprise Manager 3.3 Milestone 2 Released

by Denis Gervalle

Hi Eugen, The file you are looking for is http://download.forge.objectweb.org/xwiki/xwiki-enterprise-ui-all-3.3-miles… There is an issue on our download page, Sergiu could you have a look at this, the naming as changed and the page is automated. Denis On Fri, Nov 25, 2011 at 19:01, Eugen Colesnicov <ecolesnicov(a)gmail.com>wrote: > Broken link for xar-file. > > http://download.forge.objectweb.org/xwiki/xwiki-enterprise-wiki-3.3-milesto… > - give: "Not Found. > The requested URL /xwiki/xwiki-enterprise-wiki-3.3-milestone-2.xar was not > found on this server." > > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/Announcement-XWiki-Enterprise-and-XWiki-E… > Sent from the XWiki- Users mailing list archive at Nabble.com. > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years

[xwiki-devs] [Proposal] Adding the notion of Priority to Event Listeners

by Vincent Massol

Hi devs, Summary: ======== I'd like to add the notion of Priority to Event Listeners. The reason is that in some cases it's important that some listeners execute before others. The problem at hand: ================= Here's a typical use case: When receiving the ApplicationStartedEvent, we have lot of code that needs to initialize. Initialization order is important (you can compare it to run levels in OS): for example some init must happen after the Database initialization has happened. Note that another solution exists for this use case: some initializations could introduce their own events (such as a DatabaseStartedEvent) and other init could listen on those events instead of the generic ApplicationStartedEvent. However I can see several drawbacks to this: * it's less generic than the priority solution * it means creating more events * but more importantly it means that modules will have strong dependencies (at maven level) on each other whereas it's not necessary and shouldn't be the case. In our example use case: it means that inits that must happen after database is started will need to depend on oldcore (which is where DB is started ATM) Proposal: ======== * Don't break backward compat in Observation module * Introduce a PrioritizedEventListener interface that adds a getPriority() method * Modify ObservationManager implementation to take into account priorities * In order to make it simple I propose to have only a single priority per Listener and not a priority per event supported by a given listener General Context ============= To give some context here's what I'd like to do on the medium term: * Step 1: Introduce notion of priority in EventListeners * Step 2: Refactor XWiki init to use an EventListener on AppStarted with low priority * Step 3: Refactor wiki macros to use an EventListener on AppStarted with priority value lower than at step2 * Step 4: Write an EventListener for the new UI Extensions with a priority value higher than the one of step2 <-- this is the initial goal that led me to make this proposal ;) WDYT? Thanks -Vincent

13 years

[xwiki-devs] How to load GWT application on Xwiki pages?

by Leon Wang

Hi Everyone! I have read this document "Writing GWT applications in XWiki" ( http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingGWTApplicationsInXWiki) And I know how to develop GWT module for xwiki now. I also have read the document "WYSIWYG Editor Module" ( http://code.xwiki.org/xwiki/bin/view/Modules/WysiwygEditorModule). I followed the instruction which tried to integrate the WYSIWYG editor(GWT application) in wiki pages, and I put the following code in my wiki editor: "{{html}} <script type="text/javascript" src="XWikiWysiwyg.js"> alert('WYSIWYG code is loaded!'); </script> <textarea id="demo"></textarea> <script type="text/javascript"> Wysiwyg.onModuleLoad(function() { new WysiwygEditor({hookId:'demo'}); alert('WYSIWYG code is loaded!'); }); Wysiwyg.onModuleLoad(function() { editor = new WysiwygEditor({hookId: 'demo'}); }); }); </script> {{/html}}" After saved, it only display a blank text area without any sign of WYSIWYG editor, also there is no alart 'WYSIWYG code is loaded!' popup. Can you help me figure it out what is wrong with it? I am planing to develop a tree view using GWT to display Design Rationale Element. Could you give me some ideas of after my development, how can I embeded the GWT application into Xwiki pages and interact with the GWT application? Thank you very much! Leon

13 years

[xwiki-devs] [VOTE] Modify XEM distribution to become a Workspace distribution

by Vincent Massol

Hi devs, Since Eduard has developed the workspaces module (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application) I'd like to push for using it in our XEM distribution. However there are 2 valid uses cases that exist: 1) Using XE + workspaces, for creating workspaces (technically each workspace being a wiki) 2) Using XE as a wiki farm I think that use case 1) is the main use case for most people and this vote is about keeping the XEM packaging/branding but repurposing so that XEM implements use case 1). Use case 2) exists but it's less frequent and for more technically advanced users. So here's my proposal (and what you should vote on): A) XEM = app manager module + wiki manager module + workspaces module(s). XEM home page becomes the workspaces app home page. We update manager.xwiki.org to align it with the fact that it now boasts the workspaces features. B) On http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Virtualization we keep documenting how to transform XE into a wiki farm C) We create an application in xwiki-platform-core/ that contains the current pages located in XEM (home page + the other pages). We could call it xwiki-platform-multiwiki D) Users who want to install xwiki-platform-multiwiki easily will use the Extension Manager UI when it's ready for general consumption E) Users who want to install xwiki-platform-workspace easily will use the Extension Manager UI when it's ready for general consumption. At this point we'll decide if we want to drop the XEM distribution or keep both ways of installing it. Here'd my +1 Thanks -Vincent

13 years

[xwiki-devs] Update: Release dates for XE 3.3

by Vincent Massol

Hi devs, Since we've slipped here are the dates I'm proposing to follow (I've updated http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap): * XE 3.3RC1 - 30 November * XE 3.3 Final - 5 December ok? Thanks -Vincent

13 years

[xwiki-devs] [Announcement] XWiki Enterprise and XWiki Enterprise Manager 3.3 Milestone 2 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.3 Milestone 2. The highlights of this release are: * a new user interface for the extension manager * new features for the Application Within Minutes aspect * a new and improved FAQ application has been committed in the platform, although it's not bundled by default in XE * support for exporting PDF documents for CJK languages * a new rendering transformation that can be used to check the status of any link encountered in the wiki And on the developers' front: * support for dependency Providers, as defined in JSR330 * a Disposable interface for singleton components which can be used to release resources when a component is being unregistered See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise33M2 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2011