xwiki-devs September 2011

xwiki-devs@xwiki.org

23 participants
65 discussions

[xwiki-devs] [VOTE] Sheet resolution algorithm

by Marius Dumitru Florea

Hi devs, Here's the sheet resolution algorithm I have implemented in https://github.com/xwiki/xwiki-platform/blob/cbad868094b9cc9d811621670e3205… . getSheets(document, action) : List<DocumentReference> (1) If there is a "sheet" request parameter that points to a sheet that supports the passed action, return a reference to that sheet. (2) For each object of type XWiki.DocumentSheetBinding attached to the passed document check if the "sheet" property points to a sheet that supports the passed action. Return the computed list, if not empty. (3) For each type of object attached to the passed document: (3.1) For each object of type XWiki.ClassSheetBinding attached to the document defining the class check if the "sheet" property points to a sheet that supports the passed action. (3.2) If the class doesn't have any XWiki.ClassSheetBinding object then check if <ClassName><ActionName>Sheet exists (3.3) If not, then check if <ClassName>Sheet exists and supports the passed action (3.4) If not, then check if "sheet.defaultClassSheetBinding" configuration property specifies a sheet for the class we're looking at Return the computed list if not empty. (4) If the passed document is a class (holds a class definition) then return a reference to the default class sheet (XWiki.ClassSheet) if it supports the passed action. Otherwise return an empty list. I'd like you to vote on each of the steps of the algorithm. Are there steps you think I should drop? I'm obviously +1 for each of the steps. Thanks, Marius

12 years, 11 months

[xwiki-devs] New sheet system and backward compatibility

by Marius Dumitru Florea

Hi devs, One of the features of the new sheet system is that it can automatically detect and apply sheets. For instance, if you have: Space.YourClass (no objects) Space.YourClassSheet (no objects) Space.YourDocument (with an object of type YourClass and no include macro call to YourSheet in the content) YourDocument will be automatically displayed with YourSheet. This introduces a backward compatibility problem because the new sheet system will be triggered for existing XWiki applications that haven't been updated to use the new system. One way to prevent this is to trigger the new system only if XWikDocumenti#getDefaultEditMode() returns "edit" (it should return "inline" for current XWiki applications). XWikiDocument#getDefaultEditMode() uses two classes, EditModeClass and SheetClass, to determine the default edit mode. EditModeClass was recently introduced so most of the current XWiki applications are still using the deprecated SheetClass. In the new sheet system I needed a class to describe a sheet and I opted for reusing the name of an existing class, SheetClass, because IMO it is the best name for a class describing a sheet. As a consequence the current implementation of XWikiDocument#getDefaultEditMode() will return "inline" if you try to include a sheet in the content of a document. This limits the new sheet system because you should be able to do anything with the document content, even including another sheet. I talked with Vincent about this and we found three solutions: (1) Change XWikiDocument#getDefaultEditMode() to use only the EditModeClass. The breaks backward compatibility because current applications have to update their sheets to use EditModeClass instead of SheetClass (if they want to keep the old behavior) (2) Use XWikiDocument#getDefaultEditMode() only if a backward compatibility configuration flag is set. This means that the limitation I mentioned above (can't include a sheet in the document content) will be true only if you want backward compatibility. (3) Use a different name for the class describing the sheet, e.g. SheetDescriptorClass. This way XWikiDocument#getDefaultEditMode() will keep returning "inline" for applications that are still using the deprecated SheetClass. I'm going to implement (3) if no one is against it. Thanks, Marius

12 years, 11 months

[xwiki-devs] [VOTE] New committer Eduard Moraru (summary)

by Thomas Mortagne

10 +1 and nobody against it, vote pass. Welcome aboard Eduard ! On Wed, Sep 14, 2011 at 4:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > Hi committers, > > I would like to propose a new committer on https://github.com/xwiki/ > > Eduard first officially contacted the XWiki community trough GSoC in > 2008 on an XEclipse (https://github.com/xwiki/xwiki-eclipse) project. > After having done a great job on XEClipse he became an employee while > he was doing his 1st year master studies. > > He is an SAS employee for almost 3 years now and worked in the > Research Team developing 3 open source research projects focused on > XWiki: Concerto (https://github.com/xwiki-contrib/concerto), Scribo > (https://bitbucket.org/scribo/scribo) and now Wiki3.0 > (https://github.com/xwiki-contrib/wiki30). > > He was a GSoC co-mentor in 2010 and 2011 for XEclipse and Android > client projects. > > - Eduard is very active on the mailing list and answer efficiently > - Eduard worked and will work a lot on wiki manager and XEM which > really need some love > - Eduard sent a lot of good pull requests theses days and I'm tired of > applying them ;) > > Some stats: > > - Mails sent by Eduard (121): > http://xwiki.markmail.org/search/?q=from%3AEduard%20Moraru > > - Eduard's github profile > https://github.com/Enygma2002 > > - Eduard's Masterbranch profile > https://www.masterbranch.com/developer/Enygma > > - Eduard's ohloh profile > https://www.ohloh.net/accounts/Enygma > > I will add that it's very pleasent to work with Edy. > > I'm +1 to make Edy a committer. > > -- > Thomas Mortagne > -- Thomas Mortagne

12 years, 11 months

[xwiki-devs] [VOTE] ScriptServiceManager#get should never throw exception (summary)

by Thomas Mortagne

5 +1 and no other votes, done. On Fri, Sep 16, 2011 at 5:47 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > Hi devs, > > Right now it's pretty dangerous to manipulate script services from Velocity. > > If even you try to get a service that does not exist that will produce > an exception which will kill your script for good. It's a pain to have > use case like using a service only if it's here and fallback on > something else otherwise. > > For example even if you disabled CSRF XWiki will fill in many places > if you even think or removing the csrf jar. That seems pretty bad to > me. > > The exception does not bring much value to scripts here (even for > scripts supporting it) so I proposed to return null instead of > throwing an exception. > > WDYT ? > > Here is my +1. > > -- > Thomas Mortagne > -- Thomas Mortagne

12 years, 11 months

[xwiki-devs] [Community] XWiki.org Redesign Planning and call for participation

by Ecaterina Moraru (Valica)

Hi all, Some time ago we discussed [1] a proposal http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2 about changing the way our community website (www.xwiki.org) looks like (improved homepage, improved navigation, new logo [2], new skin, community wiki [3], etc.). Since then there have been some small collaborative efforts to make this new site come true and I want to thank for their help to Sergiu Dumitriu, Marta Girdea, Jean-Vincent Drean, Raluca Stavro, Vincent Massol, Silvia Rusu, Raluca Moisa, Stefan Orzu and all the people that gave feedback. In order to speed up the process we also created a development wiki http://newxwiki.xwiki.org/ where you can log in with your xwiki.org credentials and work on the improvements you want to make. After the work is finished it will be ported to xwiki.org. This way you can experiment the way your code looks like and behaves without interfering with the live site. Also me and Silvia created a planning for the development of the new site http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgPlanning and we have split it into 4 stages. We are currently in Stage 1 of the development. Each entry has it own link with more information/mockups/code about the feature. Also features that have been started have also a JIRA issue attached to them. We would be very happy if the community could get involved in helping us making this happen. We still need work on deciding the content for some sections, we need better design proposals for some elements and we need lots of implementation work to make everything a reality. If you want to participate you should pick something from the planning and announce it on this thread so that we know what feature is taking care of. Thank you, Caty References: [1] [Proposal] XWiki.org horizontal navigation + home page http://markmail.org/thread/tfmrludhw2yh5tcn [2] [Proposal] XWiki.org Logo Challenge - Round 2 http://xwiki.markmail.org/thread/pkdd5kijpt2yqeph [3] [Proposal] XWiki.org Community Page http://markmail.org/thread/b3pctp2kepcprfaf

12 years, 11 months

[xwiki-devs] [VOTE] ScriptServiceManager#get should never throw exception

by Thomas Mortagne

Hi devs, Right now it's pretty dangerous to manipulate script services from Velocity. If even you try to get a service that does not exist that will produce an exception which will kill your script for good. It's a pain to have use case like using a service only if it's here and fallback on something else otherwise. For example even if you disabled CSRF XWiki will fill in many places if you even think or removing the csrf jar. That seems pretty bad to me. The exception does not bring much value to scripts here (even for scripts supporting it) so I proposed to return null instead of throwing an exception. WDYT ? Here is my +1. -- Thomas Mortagne

12 years, 11 months

[xwiki-devs] [VOTE] New database version numbering

by Denis Gervalle

Hi Devs, Last database migrator is very old now, it was on revision 15428 of our SVN repository. The rules at that time was to use the revision number of the SVN commit for the database version. So our database is currently in version 15428. Since we have no more revision number in Git, and that the database version should be an integer, we need to vote a new convention: A) continue from where we are, incrementing by one, so next version will be 15428 B) use 16000, or another round number for next revision and increments by one for next version C) use a mix with the current XWiki version, so next will be 32000, and we have room for 1000 versions during the 3.2 releases. Personally, since database changes are really rare, since we were already jumping, and since there is plenty of room for number, I prefer meaning full number and I prefer C. The major advantage is that the number is in the database, so if you have a db dump, you may quickly know what is the oldest version this dump is compatible with without needing some reference list. So my +1 for C. -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

12 years, 11 months

[xwiki-devs] [VOTE] Create xwiki-contrib organization on GitHub + move retired platform modules to it

by Vincent Massol

Hi, I'm proposing to move the following modules from xwiki-platform-core to separate git repos in a xwiki-contrib organization on GitHub: xwiki-platform-calendar xwiki-platform-exo xwiki-platform-adwords xwiki-platform-alexa xwiki-platform-photoalbum xwiki-platform-s5 xwiki-platform-workstream Rationale: * They're no longer working or supported * We can move them back if the xwiki dev team wants to support them again in the future * It's cleaner than having a retired module in the xwiki organization since a) it's not "polluting" the list of repos supported by the xwiki dev team and b) it allows them to be separated in repos Future: * Also move modules currently in svn contrib to xwiki-contrib org. Note that we need to verify if the svn app works with the GitHub svn integration too since several users of svn contrib are using it. Here's my +1 Thanks -Vincent

12 years, 11 months

[xwiki-devs] Ready to move the Albatross skin to contrib/retired?

by Vincent Massol

Hi (especially Sergiu), I think you worked on removing the dependency on Albatross, right? Is it finished? Can can we move the Albatross skin to contrib/retried? See http://xwiki.markmail.org/thread/jx5vyqtrwwaidfka Thanks -Vincent

12 years, 11 months

[xwiki-devs] [VOTE] Introduce api.Context.getUserReference()

by Eduard Moraru

Hi devs, I propose to expose XWikiContext.getUserReference() to the web API (api.Context), specifically: /** * Returns the document reference for the profile page of the current user which made the request. If there's no * currently logged in user in XWiki then the returned reference is for <i>XWiki.XWikiGuest</i> which represents any * anonymous user. The returned reference can always be considered an absolute document reference, meaning that * <code>getUserReference().getWikiReference().getName()</code> will always return the name of the user's wiki. * * @return The document reference for the current user which made the request. */ public DocumentReference getUserReference() { return getXWikiContext().getUserReference(); } Some more details are available at http://jira.xwiki.org/browse/XWIKI-6964 A pull request is available at https://github.com/xwiki/xwiki-platform/pull/23 Here's my +1 Thanks, Eduard

12 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2011