xwiki-devs July 2016

xwiki-devs@xwiki.org

17 participants
39 discussions

by Julio Brum

Hi, I need to list events that were inserted through the MoccaCalendar application. I need to get the title, the way, the start date and the end date of the event. I need to get only the future events (> = today) and a maximum of 10 events. Unfortunately I could not do, so I ask your help. I could only do just that: #set($results = $xwiki.search("select doc.title, doc.web, doc.fullName from XWikiDocument doc where doc.space = 'MoccaCalendar. Mycalendar' and doc.fullName != 'MoccaCalendar. Mycalendar.WebHome' ")) #foreach ($item in $results) [[$item.get(0)>>doc:$item.get(2)]] #end Thank you in advance, Best Regards, Julio

8 years, 5 months

[xwiki-devs] [NOTICE] Tomcat versions that are not working anymore with XWiki

by Vincent Massol

Hi everyone, The Tomcat project has brought a change in the way they handle RequestDispatcher (see https://bz.apache.org/bugzilla/show_bug.cgi?id=59317) which is causing regressions. Thus for the moment you should **not** use the following Tomcat versions: • 9.0.x for 9.0.0.M5 onwards • 8.5.x for 8.5.1 onwards • 8.0.x for 8.0.34 onwards • 7.0.x for 7.0.70 onwards (See also http://jira.xwiki.org/browse/XWIKI-13556 for more details) I’ve also added a warning on: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationTomcat Thanks -Vincent

8 years, 5 months

[xwiki-devs] [Brainstorming] Alternative to Rendering Transformations

by Vincent Massol

Hi devs, Rendering Tx are great to modify an XDOM into another XDOM. However they have a limitation: they’re slow (since you have to traverse the whole AST). So if you have 10 Tx, you traverse the AST 10 times… I’d like to brainstorm about an alternative: the ability to register some Listener that will get executed at render time and that will transform the events. Use cases ======== Here are some example of Tx that would benefit being rewritten using this mechanism: * Icon Tx * Auto linking of JIRA id to jira issues * WikiWord Tx Implementation ============= It could be something like: * Introduce a ConfigurableBlockRenderer interface with a addListener() method * Modify AbstractBlockRenderer to execute those Listeners before it calls its PrintRenderer. This can be achieved with a composite listener that wraps the listeners added and the PrintRenderer. * Have a way to register some Listeners in the configuration, that should be executed when a page is rendered * Modify XWikiDocument so that those configured listeners are executed when rendering a page Differences between Tx and Listeners ============================== * Tx are slow but easy to write since you have access to the whole AST * Listeners are harder to write since you need to store the events if you need to remember them (but we have developed some tools already over the years such as the LookaheadListener) * Listeners depend on their order and they should be written carefully to minimize their interdependencies * Listener will get executed only at render time so you need to render to get the modifications to the tree, while Tx are independent of rendering. WDYT? Do you see a better way to achieve the same goal (ie removing the Tx performance limitation)? Thanks -Vincent

8 years, 5 months

[xwiki-devs] [XWiki Day] BFD#110

by Alexandru Cotiuga

Hi devs, Today is BFD#110: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 109 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#110 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13622 Happy Bug Fixing Day! Thanks, Alex

8 years, 5 months

[xwiki-devs] [Contrib] Request repository for "application-script-runner"

by Paul Pantiru

Hello devs, I would like a repository on xwiki-contrib for an application I'd like to call "Derzelas Script Runner". Name: application-script-runner Description: An application that simplifies running scripts on large number of documents from one or more wikis. State: It has not yet been released on e.x.o. but will be done asap. Tools needed: Github repository and Jira project. Username: ppantiru Thanks, Paul Pantiru

8 years, 5 months

[xwiki-devs] [Brainstorming] Changing the Mail configuration algorithm?

by Vincent Massol

Hi devs, I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki. Actually the current algorithm is the following when looking up a mail configuration property: * <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in the xwiki properties file</li> * </ul> We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): “ Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. " So I can see 2 options. Option 1: Drop support for looking for configuration in subwikis ======== * Rationale: there are few use cases that require overriding the mail config in a subwiki * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes. Option 2: Continue supporting overriding in subwikis ======== * Stop bundling Mail.Config for subwikis and modify the config algorithm to be: * <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in Mail.MailConfig in the main wiki</li> * <li>Look in the xwiki properties file</li> * </ul> I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin). Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it. WDYT? Thanks -Vincent

8 years, 5 months

[xwiki-devs] [xwiki-users] [ANN] Tour Application v1.0.2 Released

by Alexandru Cotiuga

Hello all, A new version of the Tour Application extension is available. This is a bugfix version. See http://extensions.xwiki.org/xwiki/bin/view/Extension/Tour+Application#Hv1.0…. You can install or upgrade with the Extension Manager. Thanks, Alex

8 years, 5 months

[xwiki-devs] [Proposal] Make it simpler for users to install extensions offline

by Vincent Massol

Hi, I’d like to propose that we add a new extension repo location by default in xwiki.properties that points to a predefined location in the permanent directory. For example: PERMDIR/extension/custom or PERMDIR/repository We’d have a README file in there that could explain what this directory is for with a small command line example: mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:get \ -DrepoUrl=url \ -Dartifact=groupId:artifactId:version \ -Dmaven.repo.local=/location/to/custom/repo This new repo would be the last one in the list of repos in xwiki.properties. WDYT? Thanks -Vincent

8 years, 5 months

[xwiki-devs] [XWiki Day] BFD#109

by Alexandru Cotiuga

Hi devs, Today is BFD#109: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 107 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#109 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13620 Happy Bug Fixing Day! Thanks, Alex

8 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs July 2016