November 2013 - xwiki-devs@xwiki.org

[xwiki-devs] Cannot get email value for XWikiUsers BaseObject
by Valdis Vītoliņš 21 Nov '13

21 Nov '13

I got stuck with customized validation for XWikiUsers class using XWiki 5.2. I have custom sheet with validation with following code excerpt: public class PersonValidation implements XWikiValidationInterface { public boolean validateDocument(XWikiDocument doc, XWikiContext context) { // Validation result def res = true; // User settings from the session context def session=context.getRequest().getSession(); def user = context.getUser(); def userObj=context.getWiki().getDocument(user, context).getObject('XWiki.XWikiUsers'); if(true) { XWikiValidationStatus.addErrorToContext('NMPDtools.UserClass', '', '', 'E-mail is '+userObj.getStringValue('email'), context); res = false; } return res; } public boolean validateObject(BaseObject object, XWikiContext context) { return true; } } In difference with first_name, last_name, phone, etc. This method doesn't return property value. I noted, that using passed XWiki context, BaseObject is retured in difference with Object for inline scripts, where get... methods works properly. If nothing else, is there is way to get Object from BaseObject? Any suggestions ar welcome! Valdis

2 2

[xwiki-devs] [Proposal] Delaying the XWiki 5.3 release
by vincent＠massol.net 21 Nov '13

21 Nov '13

Hi devs, 5.3 was initially planned to be released on the 25th. However as you can see on http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome some important issues that were planned for 5.3 are still not done. Normally we'd do timeboxing (ie release and implement the rest in the next version) but since we’re getting close to the end of the cycle and since some important issues remain I’d like to propose to delay the release by 1 week in order to finish the maximum number of issues for 5.3 (those related to SOLR, Wiki creation and Confluence/Scalable import/export). That will also give more time to Sorin/Manuel for testing 5.3 before the release. This would mean: 5.3 RC1: 27th of November 5.3 Final: 4th of December WDYT? Thanks -Vincent

5 4

[xwiki-devs] Improvement of XWiki search results to include keyword matches (Fine tuning!)
by Stuart Stephen 21 Nov '13

21 Nov '13

Hi, I spent some time making my XWiki instance show a more useful list of results from the search results, but there is a problem here as the freemarker code is unable to catch a rendering exception (by design of freemarker) on certain searches. If there is an exception, the user is greeted with a long wait, then no results show up at all. This isn't really good enough for my means. My happier solution, would be for the exception to happen and for nothing to be rendered in the preview for this search result. I wondered if there was a better way to achieve my goal than using the rendering mechanisms in the code below. If I can avoid or catch the exception and keep the same functionality that I have now, then I would be in a better position. Code below or on StackOverflow (http://stackoverflow.com/q/17038968/1247302) I'm using XWIKI ENTERPRISE 5.0-MILESTONE-1. I edited the page http://[servername:port]/xwiki/bin/edit/XWiki/Results and then added the code <div class="itemOthers"> #set($outputSyntax = $xwiki.getAvailableRendererSyntax('plain', '1.0')) #if ($outputSyntax) #set ($preview = $xwiki.getDocument($itemfullname).getRenderedContent($outputSyntax)) #set ($regex = $regextool.quote($request.text)) #set ($regex_summarize = "(?i)(?:((\w+)\W+){0,20})\b\w*$regex\w*\b(((\W+)\w+){0,20})") #set ($regex_highlight = "(?i)($regex)") #set ($pattern_summarize = $regextool.compile($regex_summarize)) #set ($matcher_summarize = $pattern_summarize.matcher($preview)) #foreach ( $match_loop in [0,1,2,3,4,5,6,7,8,9] ) #if ($matcher_summarize.find()) #if ($match_loop > 0) <strong> | </strong> #end $escapetool.html($matcher_summarize.group(0)).replaceAll($regex_highlight,'<span style="background-color:yellow;">$1</span>') #end #end #end </div> Thanks, Stuart Disclaimer: The contents of this E-mail plus any attachment is intended for the use of the addressee only and is confidential, proprietary and may be privileged. It will not be binding upon Trace Group or any group company (Trace). Opinions, conclusions, contractual obligations and other information in this message in so far as they relate to the official business of Trace must be specifically confirmed in writing by Trace. If you are not the intended recipient you must not copy this message or attachment, use or disclose the contents to any other person, but are requested to telephone or E-mail the sender and delete the message and any attachment from your system. Trace takes all reasonable precautions to ensure that no virus or defect is transmitted via this e mail, however Trace accepts no responsibility for any virus or defect that might arise from opening this E-mail or attachments.

2 2

[xwiki-devs] [ANN] XWiki 5.3 Milestone 2 Released
by Marius Dumitru Florea 21 Nov '13

21 Nov '13

The XWiki development team is proud to announce the availability of XWiki 5.3 Milestone 2. This release comes with a new syntax quide, an improved faceted search and the ability to import content from Confluence wiki. Also, the wiki creation wizard has now support for creating wiki templates and for choosing the user scope (local, global or both). This release also includes a lot of bug fixes (33) and a few improvements (19) so you should definitely check it out. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki53M2 Thanks -The XWiki dev team

1 0

[xwiki-devs] Set Mandatory field with AbstractMandatoryDocumentInitializer
by Matthias Wegner 20 Nov '13

20 Nov '13

Hello, i use AbstractMandatoryDocumentInitializer for creation of some classes and i want to set some fields mandatory. Is that possible? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Set-Mandatory-field-with-AbstractMandator… Sent from the XWiki- Dev mailing list archive at Nabble.com.

3 2

[xwiki-devs] Request commit rights for Holiday Request Application
by Andreea Popescu 19 Nov '13

19 Nov '13

Hello, I'd like to fix some issues and release a new version for Holiday Request Application. The github repos is https://github.com/xwiki-contrib/xwiki-application-holidayrequest and my username is PopescuAndreea (https://github.com/PopescuAndreea) Thank you, Andreea

2 2

[xwiki-devs] Introducing Andreea Popescu
by Andreea Popescu 19 Nov '13

19 Nov '13

Hello all! My name is Andreea Popescu, I'm an intern at XWiki SAS since the begging of November. I want to help with improving existing apps and implementing new ones, testing them and writing documentation etc. Thank you!

2 1

[xwiki-devs] [Vote] Creation of a design wiki and it's purpose
by Ecaterina Moraru (Valica) 18 Nov '13

18 Nov '13

Hi, *Short version* for voting: *A*. Creation of a new wiki on xwiki.org farm that will hold development process details about a specific feature. This wiki will deprecate dev.xwiki.org:Design and incubator.myxwiki.org *B*. Vote on naming alternatives for this new wiki: design.xwiki.org incubator.xwiki.org *C*. UI on how a Proposal will be displayed in this new wiki (example AppWithinMinutes): http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki ------------------------------------------------ *Long version: * Right now development process activities are located in multiple places: - Analysis + Architecture: http://dev.xwiki.org/xwiki/bin/view/Design/ - Analysis + User Interface: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ - Other: http://xwiki.markmail.org/, http://jira.xwiki.org, chats, git comments, etc. This process can be hard to optimize and information is hard to track if you are looking for specific information. And the worst part of it is that is hard to automatize and lots of the items need manual gathering or search. *Part A. * This mail is about combining http://dev.xwiki.org/xwiki/bin/view/Design/and http://incubator.myxwiki.org/ work in a single place. This has already been discussed several times before ( http://xwiki.markmail.org/thread/kc32dufsf7nyyt6s and http://xwiki.markmail.org/thread/izj6aiyodwqia4vl) and the vote was favorable in this direction. The proposal was to create a new wiki called design.xwiki.org that will contain the combined information and that will target developers. The new wiki will be used to gather only proposal's development process information: requirements, architecture, solutions alternatives, user interface variants, planning, etc. for a specific feature/idea/improvement. After the proposal is implemented it will be properly documented in the right location for users (ex platform.xwiki.org) It is acceptable to have CSS + JS code on this wiki in order to demonstrate the functionality of the proposals, but we should not add experimental/dangerous code (groovy scripts, jars, etc.). For this case it is advisable to use a test machine, share your own instance or use the contrib.xwiki.org repository for hosting. The version upgrades will be handle by a community admin and the wiki gardening by me. The data from incubator.myxwiki.org and dev.xwiki.org:Design will be moved gradually after the new wiki is created. *Part B. * You should state your opinion regarding which name is better for the new wiki: - design.xwiki.org - incubator.xwiki.org - we accept other proposals. *Part C.* I've made a proposal on how a proposal page would look like: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki The proposal page will gather all the information related to it, making it easier to track it's progress. The entries will be separated depending on 4 categories: Analysis, Architecture, User Interface and Implementation, each category having it's own status, participants, jiras and timeframe. Categories are not mandatory for all proposals, smaller proposals will have just the related pages for certain areas. Each proposal will store it's data in a dedicated space. The implementation of the proposal will be handled by me. Let me know what you think. Thanks, Caty

9 23

[xwiki-devs] Programmed Macro with Velocity Inside
by Matthias Wegner 17 Nov '13

17 Nov '13

Hello All, i use a XWiki.WikiMacroClass with a big Velocity-Script in the "Macro Code"-Section. Now i want to transfer it to a Java-Macro as described in http://rendering.xwiki.org/xwiki/bin/view/Main/ExtendingMacro. I am not sure where i have to place the code inside the Java-Macro. I tried @Inject private MacroContentParser contentParser; and in the method public List<Block> execute(...) { Strong code = "{{velocity}}\n" + "$doc\n"+"{{/velocity}}"; List<Block> result = this.contentParser.parse(code, context, true, context.isInline()).getChildren(); return result; } But this give no code-result back in The Page when i use the macro. Is that the right way? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Programmed-Macro-with-Velocity-Inside-tp7… Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 2

[xwiki-devs] [Proposal] Stop tracking sessions in URL (when cookies are off)
by Vincent Massol 15 Nov '13

15 Nov '13

Hi devs, Right now we're trying to support clients (browsers namely) that have cookies turned off. I've recently updated code to try to support that but I've found that: 1) It's very hard and we still have lot of places in our code that doesn't work without cookies 2) It adds ;jsessionid in the URL and this is causing havoc in tons of unsuspecting place such as RSS feed generation (RSS readers get different URLs every time thus thinking it's a different article, exports, watchlist, tests, etc). 3) It's a security risk to expse the sessionid in the URL 4) It's bad for SEO since search bots may index several times the same resource with different sessionid (it's a new one every time) 5) There are lots of cases where we don't need to track sessions (like for RSS feed generation or HTML exports) I started fixing all failing places because of the ;jsessionid in the URL but more keep coming and it feels strange to have to remove it a bit everywhere when we're adding it in our URL factory. Thus I'd like to propose that we officially don't support tracking sessions in URLs (i.e. when browsers have cookies turned off). The idea is that I'd still call encodeURL in our XWikiURLFactory implementations (we need this if we want to support URL rewriting for short URLs for example) but XWikiURLFactory would strip any jsessionid from the URL. WDYT? Here's my +1 Thanks -Vincent

7 8