- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Rendering] {{html}} macro should only accept valid html, right?
by Vincent Massol 23 Feb '09

23 Feb '09

Hi, Here's what a user was expecting to work (see http://jira.xwiki.org/jira/browse/XWIKI-3258) : {{html}} <table> {{velocity}} #set ($serverDocuments = [$xwiki.getDocument("Main.WebHome"), $xwiki.getDocument("Sandbox.WebHome")]) #set ($serverClass = "XWiki.MyClass") #foreach ($serverDocument in $serverDocuments) <tr> <td>$serverDocument.space</td> <td>$serverDocument.name</td> <td> #foreach($serverObject in $serverDocument.getObjects($serverClass)) * whatever #end </td> <td>[[$serverDocument]]</td> </tr> #end {{/velocity}} </table> {{/html}} This is not correct since the HTML macro must contain valid HTML and this is clearly not the case (the content is parsed by an XML parser and element content are then parsed using the wiki syntax parser). So I'm +1 to close this issue as won't fix. I see lots of users making the mistake but I don't see a solution right now. WDYT? Thanks -Vincent

3 5

[xwiki-devs] Translation Volunteers needed
by Ludovic Dubost 23 Feb '09

23 Feb '09

Hi, Guillaume (Lerouge) has done incredible work to transform all hardcoded strings in XWiki Enterprise to translations strings. We now have 620 translations strings more !!!! So we need all the help we can to get these translated before 1.8 final. I think we can achieve the following languages: French: 622 translations to do German: 629 translations to do Romanian: 1516 translations to do French and German were complete before we added the 620 more translations, and Romanian we HAVE to be able to do it with the number of romanians in the team ! Guillaume will coordinate the French translation. We need a volunteer from the Romanian team to coordinate the Ro translation. Let me know if there are volunteers to coordinate the translations effort in Geman or other languages before the final 1.8 release. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

3 2

[xwiki-devs] [Proposal] WYSIWYG Roadmap (updated)
by Jean-Vincent Drean 20 Feb '09

20 Feb '09

Hi devs, Here's an updated version of the WYSIWYG roadmap. January 29: * Major bugs fixed (Marius). February 6: * Native list support overloaded (Anca). * New wysiwyg/wiki tabs and rewamp of the edit panel (JV). * First version of the "wiki explorer" based on smartGWT, allow to browse wikis, spaces and pages (JV). * Displaying macros -- read only + placeholder (Marius). * Continue fixing bugs (Marius). February 13: * Link editing (Anca). * Link and Image menus (Anca). * Wiki explorer 1.0. Allow to add spaces and pages, to browse pages attachments (JV). * API to handle macro parameters (Marius). * Continue fixing bugs (Marius). * Macro menu (Marius). February 20: * GWT wizard, allow to chain dialogs and to navigate between them. Use of this wizard in the image plugin with 4 dialogs : current image browser, upload file dialog, upload in progress dialog, options dialog (Anca). * Table menus + final dialog (JV). * Generic way to insert/edit macros (Marius). February 27: * Final version of the Image UI (Anca). * Final version of the Link UI (Anca). * Final version of the Macro UI including a way to refresh macro content (Marius). Postponed: * Verbatim, definition list and quote features implemented. * Custom parameters feature. WDYT? Thanks, JV.

3 6

[xwiki-devs] [Proposal]Create symbol/icon/emoticon macro
by Dan Miron 20 Feb '09

20 Feb '09

Hi, Regarding the http://jira.xwiki.org/jira/browse/XWIKI-2964 issue, this is how I see it: - Grabbing the icons from the silk iconset - Creating a macro called 'icon' with the following parameters: - fileName (required) the name of the file which holds the icon; here I see two possible approaches: - with (optional) - height (optional) An example of usage would be the following: {{icon fileName="arrow_out.gif" with="20" height="20" /}} WDYT? Tnx, Dan

5 18

[xwiki-devs] [Rendering/Wysiwyg] Transformations and WYSIWYG
by Vincent Massol 20 Feb '09

20 Feb '09

Hi, One issue to discuss/brainstorm. Transformations are meant to modify the XDOM into a new XDOM. This is for ex the mechanism used for handling macros (MacroTransformation). Now there are other use cases for Transformations. Examples: * auto-transforming words into wiki links when they're using camel case * automatically creating links on word that have an entry in wikipedia * transform special symbols such as smileys :) into images We don't want these changes to be persistent in the saved document. They are *temporary* modifications. However when the wysiwyg runs right now it'll offer the generated XHTML for editing (that generated XHTML contains the transformed XDOM) and thus when we save in the wysiwyg editor the transformations will also be saved, which is a problem. We've solved it by "cheating" a bit for macros by introducing HTML comments and special handling in the wysiwyg editor. Now I think we need to rethink this and make it more generic for any transformation. Any idea? I'll try to propose some ideas too... Thanks -Vincent

2 3

Re: [xwiki-devs] [xwiki-notifications] r16956 - in platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main: java/org/xwiki/xml/html java/org/xwiki/xml/html/filter java/org/xwiki/xml/internal/html java/org/xwiki/xml/internal/html/filter resources/META-INF/plexus
by Vincent Massol 20 Feb '09

20 Feb '09

Hi Asiri, This is missing a JIRA issue number. Please always use jira issue number and description since otherwise it won't appear in the fisheye tab in jira (a tab that we use quite often to see what was committed relative to an issue). Thanks -Vincent On Feb 20, 2009, at 8:00 AM, asiri (SVN) wrote: > Author: asiri > Date: 2009-02-20 08:00:56 +0100 (Fri, 20 Feb 2009) > New Revision: 16956 > > Added: > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/html/HTMLConstants.java > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/html/filter/AbstractHTMLFilter.java > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/html/filter/ElementFilterCriterion.java > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/html/filter/HTMLFilter.java > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/internal/html/filter/FontFilter.java > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/internal/html/filter/ListFilter.java > Removed: > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/html/filter/CleaningFilter.java > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/internal/html/HTMLConstants.java > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/internal/html/filter/DocTypeCleaningFilter.java > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/internal/html/filter/ListCleaningFilter.java > Modified: > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/ > xwiki/xml/internal/html/DefaultHTMLCleaner.java > platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/resources/ > META-INF/plexus/components.xml > Log: > Merged from trunk (rev. 16937)

1 0

Re: [xwiki-devs] [xwiki-notifications] r16937 - in platform/core/trunk/xwiki-xml/src/main: java/org/xwiki/xml/html java/org/xwiki/xml/html/filter java/org/xwiki/xml/internal/html java/org/xwiki/xml/internal/html/filter resources/META-INF/plexus
by Vincent Massol 20 Feb '09

20 Feb '09

Hi Asiri, see below On Feb 19, 2009, at 1:21 PM, asiri (SVN) wrote: > Author: asiri > Date: 2009-02-19 13:21:06 +0100 (Thu, 19 Feb 2009) > New Revision: 16937 > > Added: > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > HTMLConstants.java > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > filter/AbstractHTMLFilter.java > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > filter/ElementFilterCriterion.java > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > filter/HTMLFilter.java > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/ > html/filter/FontFilter.java > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/ > html/filter/ListFilter.java > Removed: > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > filter/CleaningFilter.java > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/ > html/HTMLConstants.java > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/ > html/filter/DocTypeCleaningFilter.java > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/ > html/filter/ListCleaningFilter.java > Modified: > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/ > html/DefaultHTMLCleaner.java > platform/core/trunk/xwiki-xml/src/main/resources/META-INF/plexus/ > components.xml > Log: > XWIKI-3240: 'style' attribute of <font> tag discarded when cleaning > html > > * Fixed the issue. > * Changed all cleaning filters to use w3c dom document instead of > jdom. > > > Copied: platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/ > html/HTMLConstants.java (from rev 16930, platform/core/trunk/xwiki- > xml/src/main/java/org/xwiki/xml/internal/html/HTMLConstants.java) > =================================================================== > --- platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > HTMLConstants.java (rev 0) > +++ platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > HTMLConstants.java 2009-02-19 12:21:06 UTC (rev 16937) > @@ -0,0 +1,190 @@ > +/* > + * See the NOTICE file distributed with this work for additional > + * information regarding copyright ownership. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This software is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this software; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > + * > + */ > +package org.xwiki.xml.html; > + > +/** > + * HTML Constants used by the HTML Cleaner. > + * > + * @version $Id: $ > + * @since 1.6M2 > + */ > +public interface HTMLConstants Can we use an Enum type instead? I'm not sure why you changed CleaningFilter to HTMLFilter. They are HTML filters for sure but not any type of HTML filters they are HTML Cleaning Filters. It's not very important but I had chosen CleaningFilter name voluntarily so I wanted to know what's your rationale for changing the name. Why have you removed the doc type cleaning filter and instead "hardcoded" it in the default cleaner implementation? Note: Haven't checked the criterion stuff yet, so I'm not sure what this is about. Question: have you been careful about performance? HTML cleaning is the most costly thing in our rendering system so we have to be very careful. Have you measured the rendering test speed before and after as an indication? Thanks -Vincent [snip]

2 2

[xwiki-devs] Regarding redirection
by Colin Tay 19 Feb '09

19 Feb '09

Hi, I will like to know how can i redirect a page if i press the cancel button on the new document. Instead of the default behavior of showing "The requested document cannot be found.", i will like to redirect to the document space webhome page. Secondly, i will like to make the users radio button in the document rights editor to be hidden, and thus showing the group radio button only. What are the changes needed? Urgent, Colin Importing contacts has never been easier..Bring your friends over to Yahoo! Mail today! http://www.trueswitch.com/yahoo-sg

2 1

[xwiki-devs] Does JDK6u14 "Garbage-First garbage collector (G1)" work and/or improve Xwiki performance/size/mem-locality?
by Niels Mayer 19 Feb '09

19 Feb '09

I usually have found that the garbage collector is the hardest-working thing in a java-web app (unfortunately) so when I noticed this new GC option in *Java HotSpot 14*, I figured it might help (potentially a lot w/ high-volume sites, which are the real GC churners). Has anybody tried the "Garbage-First garbage collector (G1)" with Xwiki? http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances suggests > > CATALINA_OPTS="-server -Xms128m -Xmx1024m -XX:MaxPermSize=128m -Dfile.encoding=utf-8 -Djava.awt.headless=true -XX:+UseParallelGC -XX:MaxGCPauseMillis=100" > > However these instructions don't work, as-is, since UseParallelGC is the default nowadays: https://jdk6.dev.java.net/6uNea.html says: The parallel collector is still the default GC and is the most efficient GC > for common household usage. G1 is meant to be an alternative for the > concurrent collector. It is designed to be more predictable and enable fast > allocation with memory regions design. Having actually worked on a variety of strange garbage collectors (for Lisp) where all of java's problems had already been solved decades ago ...this feels like a 1985-1990 flashback. :-) Here's more info Java SE 6 Update 14 Milestone Schedule b01 (1st available build) 02/11/09 FCS > Q2, 2009 *Feature List:* > > - *Service Tag creation for Windows JRE (CR 6676849<http://bugs.sun.com/view_bug.do?bug_id=6676840> > )*: For more information about Service Tag, check out this technical > article > <http://java.sun.com/developer/technicalArticles/productregistration/>. > > - *Java HotSpot 14*: including the new garbage collector, G1, Big > Decimal enhancements, TreeMap and HashMap enhancements, optimized compressed > OOP code generation. > > The Garbage-First garbage collector (G1) is currently in beta. It is not > enabled by default. The parallel collector is still the default GC and is > the most efficient GC for common household usage. G1 is meant to be an > alternative for the concurrent collector. It is designed to be more > predictable and enable fast allocation with memory regions design. > > To use it: -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC > > For more information about GC & G1, please see: > > - G1 Technical Session in JavaOne 2008<http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&…> > - Java SE 6 GC tunning<http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html> > - Analysis of the Garbage-First Garbage Collection<http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf> > > Niels http://nielsmayer.com PS: and will a different GC prevent sequences like this from happening?? see http://nielsmayer.com/happy-happy-joy-joy.txt PPS: some things that cause big-growth, like importing and exporting, might not grow as large with a "generation scavenging" style GC as provided by "Garbage-First Collection." Sometimes, just GCing a large structure being iterated-over uses a lot more memory than it needs to; because the gc is letting objects that should get collected early, like the incremental results of an iteration, "build up" and increase overall memory size while decreasing locality and cache-hits. This seems to cause a nearly exponential performance dropoff when very little memory churn might occur if only things got collected "at the right time." http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf suggests this new GC will help: 2.4 Generational GarbageFirst > > Generational garbage collection [34, 26] has several advantages, which a > collection strategy ignores at its peril. Newly allocated objects are > usually more likely to become garbage than older objects, and newly > allocated objects are also more likely to be the target of pointer > modications, if only because of initialization. We can take advantage of > both of these properties in Garbage-First in a flexible way. We can > heuristically designate a region as young when it is chosen as a mutator > allocation region. This commits the region to be a member of the next > collection set. In return for this loss of heuristic flexibility, we gain an > important benefit: remembered set processing is not required to consider > modifications in young regions. Reachable young objects will be scanned > after they are evacuated as a normal part of the next evacuation pause. > > Note that a collection set can contain a mix of young and non-young > regions. Other than the special treatment for remembered sets described > above, both kinds of regions are treated uniformly. > > ... > > 2.5 Concurrent Marking > > Concurrent marking is an important component of the system. It provides > collector completeness without imposing any order on region choice for > collection sets (as, for example, the Train algorithm of Hudson and Moss > [22] does). Further, it provides the live data information that allows > regions to be collected in \garbage-first" order. This section describes our > concurrent marking algorithm. > >

2 2

[xwiki-devs] [Warning] Trunk is now 1.9-SNAPSHOT
by Jean-Vincent Drean 18 Feb '09

18 Feb '09

Hi devs, Now that XE 1.8 RC1 has been released the 1.8 version of XE has its own branches (for core, web and enterprise). Trunk is now holding XE 1.9 version. To everyone: we _must_ commit in both trunk and 1.8 branches for everything except post XE 2.0 features (note that there's no such feature planned for the moment). JV.

3 2