Guillaume Lerouge wrote: The table training page was supposed to be helpful as a place to try out the table syntax, and the old WYSIWYG table operations, which was really bad (non-working features, hard to control, unexpected output...). So, the real question is: Do people still need to practice their table handling skills? Is the new WYSIWYG good and intuitive enough? If not, then we need to keep it there, even if we remove the computation examples from the old page. Converting pages to the new syntax doesn't imply a 100% equivalence, which is not always possible to achieve and most of the times limits the features we can use or expose. Instead of removing the whole table training document, we can remove just the computation cells and add instead new features, like table headers in any place, document blocks inside tables, table row and table cell formatting, etc. -- Sergiu Dumitriu http://purl.org/net/sergiu/

How about having Sandbox.WebHome *only* be an index into viewing and editing a bunch of separate "canned" docs which pre-populate the Sandbox space and are included with the XE XAR. The sandbox space would contain small, stand-alone examples of 2.0 wiki-code, 2.0 velocity-code, and 2.0 groovy-code. These could be selected from "best demonstration of a xwiki concept/feature" snippets on xwiki.org website, and/or solicited from the community in a "competition" with a deadline prior to the 2.0 final release. Sandbox.WebHome would only contain an index into these "snippets", with special links to help novices go to the correct editor: (1) doc view link -- /xwiki/bin/view/Sandbox/<snippetname> (*) (2) for wysiwyg demos (edit table, edit list, fonting, etc), a link to wysywig edit -- /xwiki/bin/edit/Sandbox/<snippetname>?editor=wysiwyg (3) for programing demos, a link to wiki edit -- /xwiki/bin/edit/Sandbox/<snippetname>?editor=wiki (4) for wiki-macro bridge or JSX/SSX demos, link to object edit -- /xwiki/bin/edit/Sandbox/<snippetname>?editor=object (5) for Class demos, link to class edit -- /xwiki/bin/edit/Sandbox/<snippetname>?editor=class (*): view link should also contain a link back to the original doc as well as viewing original source-code, although this will be problematic for edited objects, which don't track reverts or revision references of main doc. Niels http://nielsmayer.com PS: For example, http://lists.xwiki.org/pipermail/devs/2009-August/013940.html is a good basis for two of these mini-examples-demonstrating-a-concept: (1) wiki-macro bridge with groovy, (2) 2.0 groovy example. (1) from "XWiki.WikiMacroClass WikiMacroClass 0: weather_by_zip : {{script language=groovy}} def rss = new XmlSlurper().parseText((" http://weather.yahooapis.com/forecastrss?p=" + xcontext.macro.params.zip).toURL().text) println rss.channel.title println "Sunrise: ${rss.channel.astronomy.@sunrise}" println "Sunset: ${rss.channel.astronomy.@sunset}" println "Currently:" println "\t" + rss.channel.item.condition.@date println "\t" + rss.channel.item.condition.@temp println "\t" + rss.channel.item.condition.@text {{/script}} (2) 2.0 document demonstrating groovy scripting and parametrization w/o macro-bridge: == Groovy Example From [[IBM DeveloperWorks>> http://www.ibm.com/developerworks/java/library/j-pg05199/index.html]]== Note: correct usage requres {{code}}request.zip{{/code}} parameter, e.g [[92625>>Main.GroovyTest3?zip=92625]] [[92660>>Main.GroovyTest3?zip=92660]] [[10001>>Main.GroovyTest3?zip=10001]]... {{groovy}} def rss = new XmlSlurper().parseText((" http://weather.yahooapis.com/forecastrss?p=" + request.zip).toURL().text) println rss.channel.title println "Sunrise: ${rss.channel.astronomy.@sunrise}" println "Sunset: ${rss.channel.astronomy.@sunset}" println "Currently:" println "\t" + rss.channel.item.condition.@date println "\t" + rss.channel.item.condition.@temp println "\t" + rss.channel.item.condition.@text {{/groovy}}