xwiki-devs February 2014

xwiki-devs@xwiki.org

26 participants
67 discussions

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 5.4. This is an improvement and stability release for things started during the 5.x cycle and will be the last major version of this cycle. The highlights of this release are Solr, WikiStream, Distribution Wizard and Activity Stream improvements. In numbers its 96 bug fixed, 49 improvements and 6 new features. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download (please allow a few hours for the binaries to propagate to the download servers if the download doesn't work yet) Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki54 Thanks -The XWiki dev team

10 years, 7 months

[xwiki-devs] [Proposal] Resource module API change

by vincent＠massol.net

Hi devs, I’d like to make 2 changes to the Resource module that are breaking (but this module has @Unstable annotations so it should be ok): * Change 1: Move getAction() to Resource. Right now it’s only in EntityResource but I’d like that each Resource has an action associated to it. I also propose that we use a GET action for the single action that currently exist for non Entity Resources (for example for skin resources). * Change 2: I’d like to type more the Resource action and introduce a ResourceAction class (exactly similar to the Syntax class in the Rendering). The idea is to have a list of well-known resource actions and at the same time be able to create new actions. This is better than constantly comparing and using strings. So for example this means that instead of the following in Resource (currently in EntityResource but see change 1): /** * @see #getAction() */ private String action; we would have: /** * @see #getAction() */ private ResourceAction action; WDYT? Barring any negative comments, I’ll implement this in the coming days. Thanks -Vincent

10 years, 7 months

[xwiki-devs] Possible important issues with PR when upgrading a farm-mode subwiki

by vincent＠massol.net

Hi guys, I’ve just realized that on farm wiki like myxwiki.org we have an important issue when we upgrade the WAR. When local admins log on their wiki they get the DW, they follow it and then they find their wiki is broken in several places: - search/search suggest not working - activity stream stays empty - reset password feature doesn’t work - etc The problem is that the local admin users do not have PR on subwikis and since we have several pages requiring them, this breaks their upgrades. This is a pretty serious problem since they have no way of doing a proper upgrade and this doesn’t do good advertising for xwiki... What can we do in the short term (for 5.4.1 for example since I believe this is something really urgent to fix)? Only solution I can think of (which should be pretty quick) would be to look at all pages requiring PR in our default XE XAR package and replace those with specific API calls. WDYT? Thanks -Vincent

10 years, 7 months

[xwiki-devs] [VOTE] Remove feature of extracting the title from the content

by vincent＠massol.net

Hi devs, I’d like to propose removing the feature of extracting the title from the content in 6.x. The rationale is: * This is costing more than it should. It needs parsing the document content to get its XDOM and then to traverse it to find Heading blocks. When we display doc titles in lists (in livetables for example or in the activity stream) it costs a lot to do so. * Our implementation is broken since if you use an include macro that generates a heading for ex, it won’t be taken into account since we don’t apply transformations ATM when computing the title since it would be even more expensive. Since 6.x is about performance I believe this would be a good step forward. Now in order to handle backward compatibility. I propose that we: * Add a legacy configuration parameter to keep the behavior (but off by default). This would be in order to let users using this feature convert their wiki * Move the code to a legacy module (I hope it’s possible) Here’s my +1 Thanks -Vincent

10 years, 7 months

[xwiki-devs] [VOTE] Stop supporting export to RTF without an open office server

by vincent＠massol.net

Hi, Our RTF export has never been very good and is even crashing depending on the reader you use (see for example http://jira.xwiki.org/browse/XWIKI-5251 ). I propose to drop the RTF support without OO Rationale: * If a user really needs it he can make it work with an OO server connected to xwiki * RTF is not really a mainstream format * I don’t think we want to invest in fixing our RTF export Here’s my +1 Thanks -Vincent

10 years, 7 months

[xwiki-devs] [Proposal] Getting ready to release XWiki 5.4 - Stop the commits!

by vincent＠massol.net

Hi devs, Today is the day we’re supposed to release 5.4 final. I’ve checked with a few committers on IRC and it seems they’re good to go. They still have issues but they plan to fix them in 5.4.1. Thus I’m proposing: * to stop committing on the 5.4 branch today * work on fixing failing builds on the CI * release either this afternoon if all is ok or do it tomorrow morning * then once 5.4 final is released resuming committing on the 5.4 branch for the 5.4.1 release WDYT? Thanks -Vincent

10 years, 7 months

[xwiki-devs] Experiment using emberJS

by Ludovic Dubost

Since we will be working on investigating Javascript Frameworks the following might be useful to help compare how the frameworks can be integrated. After last year's experimentation with AngularJS available at http://extensions.xwiki.org/xwiki/bin/view/Extension/AngularJSDemo I've done an experimentation with emberjs which is a similar framework. The result is available here: http://extensions.xwiki.org/xwiki/bin/view/Extension/TodoList%20Application… Some feedback on the process: 1/ The templates (handlebars) can be put directly in the wiki pages which is good. In this case I put them in the todolist macro which I created. You can see the code in the WikiMacro TodoListMacro 2/ The JS and CSS could be put in JS and CSS extension 3/ The storage could be integrated by implementing an Adapter. In this case I did some special server code in order to store the content in the content field of my todolist macro. However in most case we will probably want to map the emberjs model to the XWiki Object model. For this we can either improve our REST api to provide an API that emberjs would natively understand (this is from what I saw very possible), but we can also write an adapter that maps the emberjs store api to our REST API. This is also very possible, however we might still need some improvements in the XWiki rest api (some improvements have already been commited as part of the mobile app development). emberjs has a chrome extension to help see the results. I did not have too many bugs because I use the tutorial so I cannot say how easy or not it is to debug issues in emberjs. I remember it was a bit painful with Angular. This is something important to look at. In general it was not too difficult to adapt the emberjs todo demo to XWiki and wire it to an XWiki storage. This type of framework can be very productive if we have already some generic wiring to XWiki storage. Now to be fully productive we also need to improve a it the way we develop in Javascript in XWiki. When you do a complex applications with multiple JS/CSS/Template then you need a better way to navigate between the different content with some nice syntax coloring. So we need to improve the way we can edit this type of files. This will revive the XEclipse/WebIDE and file system view of XWiki code debate. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

10 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2014