xwiki-devs October 2005

xwiki-devs@xwiki.org

13 participants
9 discussions

Groovy, Velocity, and XWiki syntax processing issues

by Stephen Schaub

When XWiki renders a document, the interactions between the Groovy, Velocity, and Wiki (Radeox?) syntax processing can lead to unexpected and undesirable behavior. There have been posts on this list in the past where this issue has been discussed. However, I'm not aware that any consensus has emerged as to how to deal with these problems. To summarize, here are a few of the issues that I'm aware of: * Getting XWiki to render a bit of text without doing any syntax processing on it can be difficult. For example, the {pre} ... {/pre} markup turns off XWiki syntax processing, but not Groovy processing. * The # symbol is used both to do numbered lists and is also used for Groovy processing. If a user wants to create a numbered list and forgets to put a space after the #, he can run into trouble. The following example will cause a stack dump: #bring coffee #include doughnuts * Code samples on a Wiki page sometimes don't render correctly, due to conflicts with Velocity syntax processing. The following C/C++ code sample results in a runtime stack dump: {code} #include <stdio.h> ... {code} * Groovy and Velocity both use $varname syntax. I think I've read some posts in the past where this was an issue -- although I can't come up with any examples at the moment. * A usability issue: Most XWiki tags ({table}, {code}, etc.) come in pairs. The closing tag has no slash. For example: {table} ... {table}. However, the {pre} tag does have a closing slash: {pre} ... {/pre}. This inconsistency is annoying and causes difficulties for new users. * A significant usability issue for Windows users: Pathnames contain backslashes (\). XWiki uses the backslash as an escape character. So attempting to put a UNC path like \\myserver\myshare\mydoc.txt in an XWiki document triggers an XWiki runtime exception. Boy, is that frustrating for new XWiki users. The solution is to wrap the path in {pre} .. {/pre}, but the error message gives the user no clue what the problem was, much less how to correct it. Here are some proposals for discussion: 1. {pre} ... {/pre} should turn off ALL syntax processing of its contents. 2. {code} ... {code} should turn off ALL syntax processing, except for syntax coloring. 3. {pre} should allow {pre} as a closing tag. 4. Consider requiring users to explicitly enable Groovy/Velocity processing for selected Wiki documents as needed. In the page editor, provide two checkboxes: "Perform Groovy Processing" and "Perform Velocity Processing". The user could separately enable either Groovy or Velocity processing, or both. People who enable them would presumably be in a better position to deal with the kinds of syntax conflicts that would occur. 5. Provide more user-friendly error messages when a Groovy or Velocity processing exception occurs. Show the Wiki source line that caused the problem. I haven't opened a JIRA issue for this yet, because I'm not sure how best to word it. But I think this is a high-priority issue that should be carefully addressed before the 1.0 release. This may be an issue that warrants a page on the xwiki.org developer site. I'll be glad to start one if the developers desire it -- perhaps here: http://www.xwiki.org/xwiki/bin/view/Dev/Discussions Stephen

19 years, 9 months

version summary

by Matthew Conway

I've noticed that the version number (correctly) gets bumped for every new comment or image upload. However, I would like a means to show a list of revisions for _just_ content changes, i.e. exlude the revisions which were created for new comments and attachments. How would I do this in some velocity code? Thanks, Matt

19 years, 10 months

Connection Pooling

by Sam Taha

Greetings, I am new to xwiki and was wondering how some of the multi-company features of xwiki work. From my readings it sounds like one must create a separate mysql db for each new company/tenant. If this is true would this not require a seperate database connection pools for each company? Are Oracle or Postgresql supported? I know with these two databases one can create database namespaces (something mysql does not have). This would allow the same jdbc driver to reference mulitple namespaced schemes and thus use the same pool. Anyway, any thoughts would be apprciated. I am looking to setup xwiki in a multi company setup and was looking for some insight. Thanks, Sam --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

19 years, 10 months

Problems with XWiki links with non-alphanumeric characters

by Stephen Schaub

Here's an issue I feel should be addressed before the 1.0 release: Create a wiki page with links like the following: [Images: Good or Bad?] [C++ Examples] XWiki renders the first link like this: <a class="wikicreatelink" href="">Images: Good or Bad??</a> It's completely broken. The second link is rendered like this: <a href="/xwiki/bin/view/Sandbox/C+++Examples">C++ Examples</a> XWiki should be able to gracefully handle Wiki links with non alpha-numeric characters. Here are my thoughts on a solution to the problem: 1. When rendering a Wiki link, XWiki could strip out all non-alphanumeric characters. Thus, a link like [Images: Good or Bad?] would render as <a href="/.../ImagesGoodorBad">Images: Good or Bad?</a>. Benefits: Straightforward to implement. Yields nice clean document names. Drawbacks: Presents backwards compatibility problems; several different Wiki links could map to the same document name. 2. XWiki could perform URL encoding on the Wiki links. Benefits: Better backwards compatibility (I think). Drawbacks: Yucky document names. Perhaps there are other solutions somewhere in between. My personal preference is #1. Backwards compatibility could perhaps be addressed with a configuration option switch. I created a Jira issue for this: http://jira.xwiki.org/jira/browse/XWIKI-188 Thoughts? Stephen

19 years, 10 months

XWiki Developers Release

by Ludovic Dubost

Here is a status on the development towards the next release, which should be the one of the very last release before 1.0. The following major feature have been added to the current SVN version Thanks to the Summer of Code we have now - a WYSIWYG Editor - a Chart Wizard - a new Query Language Additionnally we have: - a new title field and different rendering of document names in links and in the header - a backlinks feature (activated using xwiki.backlinks=1 in xwiki.cfg) - a custom mapping feature allowing to store XWiki Objects in flat tables for advanced developments - new storage of XWiki classes definition in the xwikidoc table instead of multiple tables - the XWiki Preferences now use a custom mapping for better performance - lot's of bug fixes, incl. access through proxies, issues with the multilingual feature - an import/export API (for backups and for XWiki applications) which is needed for the Import/Export XWiki page - improvements to the URL scheme which will allow to reduce the number of elements in the xwiki URLs (currently some XWiki features still need xwiki to run on the /xwiki/ path) These are a lot of new features which needs to be well tested before become fully usable. Most of the features can be deactivated or are backwards compatible. We would need some help from the XWiki community to test this new version and report any issues in JIRA ( http://jira.xwiki.org ). Except for the preferences storage and the xwiki classes definition storage, it is possible to revert to an older version even if running the new version. Now it is highly recommended to backup your database and test with care on production data. I'm planning to provide a test build for developers, but if you want to test right away, you will need to build XWiki from the SVN code. The plan for getting XWiki to 1.0 is: - bug fixing - bug fixing - documentation - very small missing features - bug fixing - documentation - revamp of the XWiki interface according to the Usability report done during the summer - bug fixing - documentation Any help or comments is welcome. For now it would be usefull to identify bugs that would absolutely need to be fixed before releasing this version to replace 0.9.840. The objective is to provide an improvement versus 0.9.840 and allow working with the new features, not necessarily to provide a perfect version. Thanks and happy testing Ludovic -- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic

19 years, 10 months

Bounties

by Stéphane Laurière

What about adding a permanent XWiki bounties section, to somehow perpetuate the idea of the Google Summer of Code in the fall? This page pointed out by Marc gives a structured bounty process: http://www.ubuntulinux.org/community/bounties/document_view I'd be happy to sponsor a few ones if this makes sense to you too. By the way, since the move from SourceForge to ObjectWeb, is there still a way to make donations to the project? Stéphane

19 years, 11 months

Excel on the web...

by Vincent Massol

Hi there, Check this: http://numsum.com/ Idea: Create a xwiki plugin so that xwiki users can share a spreadsheet in the form of a xwiki page. -Vincent

19 years, 11 months

FIX: XWiki-169 Error: missing exoplatform environment class

by Jim Stuttard

build.xml builds the exo fileset with the xwiki-normal.cfg into the xwiki-N.N.N.war and xwiki.war targets and vice versa into xwiki-exo-N.N.N.war. Jim -- Jim Stuttard

19 years, 11 months

xwiki build.139 Build Fixed

by ludovic＠xwiki.org

View results here -> http://build.xpertnet.biz/cc/buildresults/xwiki?log=log20051001194251Lbuild…

19 years, 11 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2005