xwiki-devs September 2009

xwiki-devs@xwiki.org

44 participants
135 discussions

[xwiki-devs] Testing exceptions in JUnit 4.7

by Vincent Massol

Hi, I've been wondering how to test exceptions in JUnit 4.x when you want to assert the exception message. Just found an answer: http://www.wakaleo.com/blog/225-testing-exceptions-in-junit-47 It looks to me slightly better than using the try/fail/catch strategy. WDYT? Thanks -Vincent

15 years, 2 months

[xwiki-devs] [Proposal] Change Panel usage of ID attribute in favor of CLASS attribute + naming strategy

by Vincent Massol

Hi, We have a pb if we display several times the same panel on a page (for ex for the search panel) since if the panel defines an ID this ID will not be unique in the page and thus will produce invalid XHTML. This happens for ex when you're on the panel page itself and that panel is displayed in the right or left columns. I'm proposing that we change the use of ID in favor of CLASSNAME for panels. For example for the search panel right now we have: #panelhiddenheader($msg.get("panels.search.title")) <form action="$xwiki.getURL('Main.WebSearch')"> <div id="globalsearch"> <input id="globalsearchinput" type="text" name="text" ... It'll become: #panelhiddenheader($msg.get("panels.search.title")) <form action="$xwiki.getURL('Main.WebSearch')"> <div class="globalsearch"> <input id="globalsearchinput" type="text" name="text" I think it would also be best to define a naming strategy. What about "panel-<short name of the panel page in lowercase and without any panel suffix>" So for Panels.Search it would be "panel-search" and for Panels.QuickLinks it would be "panel-quicklinks" Note: Changing id="globalsearch" to class="globalsearch" (or class="panel-search") means changing lots of places in the skins (albatross, finch, toucan, colibri). But I don't see any better way anyway. Thanks -Vincent

15 years, 2 months

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.0 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.0. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download More than 400 issues were fixed from XWiki Enterprise 1.9.3 to XWiki Enterprise 2.0. Many thanks to the very active community for all the reports and the contributions ! Main changes from 1.9.3: * new Colibri skin and easy color modifications * many new 2.0 macro and improvements on existing macros * new wiki based 2.0 macros * new event distribution and clustering support * many WYSIWYG improvements * many rendering improvements * many general UI improvements * new Swedish and Korean translation and updated translations for lots of other languages For more informations see the releases notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM20 Thanks -The XWiki dev team

15 years, 2 months

[xwiki-devs] [VOTE] Hide Office Importer Features when the OOo server isn't running

by Guillaume Lerouge

Hi Devs, right now an user can go to the Office Importer page and try uploading a file even when the backend OOo server isn't running. This leads to usability issues. Thus I'd like to send a vote on the following 2 items: - On the Office Importer page, add the following message: - "You cannot import an Office document since the conversion server has not been started. Please ask an administrator to get it started for you." - If the current user is an admin, the message should read: "You cannot import an Office document since the OpenOffice server has not been started yet. You can start the OpenOffice server and manage it from this page (link to the OOo server administration page)." - In the action bar: add a check to see whether the OOo server is running and don't display the link if the OOo server is not. Here's my +1 to both. Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

15 years, 2 months

[xwiki-devs] Remove the notification message in OpenOffice Server Administration UI

by Asiri Rathnayake

Hi All, This is very trivial, I have put the message: "You can change these configuration options via *WEB-INF/xwiki.properties*file." In OpenOffice server administration UI which is actually not required (since this UI is meant to be used by admins who knows about xwiki.properties). I'm not sure this is worth a vote but just in case, here is my +1. Thanks. - Asiri

15 years, 2 months

[xwiki-devs] [Discussion] Programming rights grant policy

by Asiri Rathnayake

Hi all, Currently XWikiRightService has two methods for evaluating programming rights: XWikiRightService#hasProgrammingRights(XWikiContext context); & XWikiRightService#hasProgrammingRights(XWikiDocument doc, XWikiContext context); Since newer components are using DAB (Document Access Bridge) than directly accessing XWikiRightService, only one form of programming rights evaluation is available: <code> public boolean hasProgrammingRights() { XWikiContext xcontext = getContext(); return xcontext.getWiki().getRightService().hasProgrammingRights(xcontext.getDoc(), xcontext); } </code> So the procedure carried out in evaluating programming rights is: - If the context document is null, check whether the current user has programming rights or if he is the superadmin - If the context document is not null, check if the author of the context document has programming rights on the context document itself. Recently we came across a requirement where we need to grant programming rights to some scripts programmatically. See http://jira.xwiki.org/jira/browse/XWIKI-4262 With the current policy for programming rights evaluation, this is not possible (not without side effects). So we need to decide a new method for granting programming rights. One approach proposed by Thomas Mortagne is to change the programming rights evaluation as below: - Check if a particular flag is set in context (like "hasProgrammingRights"), if so current execution is considered to have programming rights - Else do the earlier evaluation process. This way we can grant programming rights in a programmatical fashion and since XWikiContext is mostly read-only for normal users, they won't be allowed to hijack programming rights by tampering with XWikiContext. Please let us know your opinions regarding this issue. Thanks. - Asiri

15 years, 2 months

[xwiki-devs] [Proposal] Operation Stabilisation till 1st of November + 2.0.x releases

by Vincent Massol

Hi devs, I'd like to propose a stabilisation operation starting now and for 1 month (ie from now to the 1st of November) The idea would be that **no new feature** is allowed to be committed in SVN. We have several domains to stabilize quickly after the 2.0 release: - Colibri skin - WYSIWYG editor - Rendering - XAR 2.0 - conversion to 2.0 syntax. - internationalization texts - Various (office importer page shouldn't be displayed when the office server is not running, wiki macro textarea should be larger, etc) These should go in both the trunk (2.1) and for 2.0.x I also propose to release a 2.0.1 in 2 weeks time (i.e. for the 12th of October) and to continue 2.0.x release every 2 weeks till we reach that month's end. WDYT? Thanks -Vincent

15 years, 2 months

[xwiki-devs] Features Survey Results

by Guillaume Lerouge

Hi XWikiers, as promised I posted a blog article listing the results of the XWiki Features Survey. You can read it here: http://www.xwiki.org/xwiki/bin/view/Blog/Features+Survey+Results We'll use the results during the discussion about the XE 2.1 roadmap. I've also included the original result files for the data crunchers among you to play with ;-) Thanks a lot to all of you who took part to the survey! Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

15 years, 2 months

[xwiki-devs] [PROPOSAL] {{doclist}} macro syntax - [Take 1]

by Asiri Rathnayake

Hi Devs, I've been thinking about the new {{doclist}} macro syntax which is going to be the successor of old livetable macro. Following is the syntax I have in mind: {{doclist <macro_parameters>}} |=(% <column_spec> %) column_name |=(% <column_spec> %) column_name |=(% <column_spec> %) column_name ... {{/doclist}} [macro_parameters] class="" ## bounds the table to a class. source="" ## can be a document name or a url. (will be ignored if class parameter is set) rowCount="" ## number of rows per page. tagCloud="" ## whether to display the tag cloud or not. (On/Off) callback="" ## name of a js function to be used for handling server (JSON) response manually. [column_spec] mapping="" ## name of the json attribute to which this column should be bound to. [1] (see below) selected="" ## if this column should be selected by default. order="" ## Default sort order for this column (applies only if this is the default selected column). isHtml="" ## if the result JSON string should be treated as html and directly injected into cell content. filterable="" ## whether this column should present a filter or not. sortable="" ## whether this columnd should be sortable or not. filterType="" ## what type of a filter to be used (only for filterable columns). linkType="" ## type of link to be used if a cell value should link to the original document. [2] (see below) [1] - mapping: This is a mandatory parameter. I'm not sure if this is the correct name for the parameter. For the default implementation (XWiki.DocListMacroResults) we have to decide the names of the JSON properties that will be returned, we could use: "doc.<fieldName>" ## for document metadata. "obj.<propertyName>" ## for object properties when the table is bound to a class. "actions" ## special column for listing all the actions available for the current user. * We could have an special "function_name(field1, field2, ....)" mapping parameter which will deligate the mapping function to a local js function. This can be useful if someone wants to calculate a column value based on the returned results. * Question: Do we need to have attachment / image columns? [2] - linkType: We can have "none", "view", "edit" & "inline" type of links. Any other type of link? You can compare this doclist macro specification with the old livetable macro spec here: http://code.xwiki.org/xwiki/bin/view/Macros/LiveTableMacro. WDYT? Thanks. - Asiri

15 years, 2 months

[xwiki-devs] Groovy Blog Application: 1st Draft

by Andreas Schaefer

Hi Geeks I just uploaded the first draft of the Blog Application in Grooyv: http://jira.xwiki.org/jira/browse/XABLOG-81 You need to install the Blog Plugin (also attached there) and then import the XAR file. It uses its own space called "GBlog" and so you don't need to worry that Blog is gone because of it. The current state is that most of the staff works (sort of) including the panels but: 1. The application is not up to date with the latest code 2. Some stuff might look ugly or does not work properly. If so please let me know. 3. I need to redesign the Groovy structure to take better care of the code. I postponed that so far because I wanted to make sure I had a good picture of all the problems with the rewrite. Let me know what you think. Cheers - Andy

15 years, 2 months

← Newer
1
2
3
4
5
6
7
...
14
Older →

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 September 2009