xwiki-devs February 2009

xwiki-devs@xwiki.org

40 participants
81 discussions

[xwiki-devs] Annotation feature progression

by Lucien PEREIRA

Hi all, I added a new alternative interface to wikimodel (IWemPositionListener) in order to pass line and column position for each begining/end of block event. Initial scanner has been modified too. Modifications donc break IWemListener clients because I added a wrapper for that. I rencently proposed a patch, http://code.google.com/p/wikimodel/issues/detail?id=112 , some test/event hasn't been written yet. Once this has been done I will workon the core, I intend to : - add a class (named Location) that wrap line/column number - add to AbstractBlock a Location reference, getters and setters for this new type - modify XDOMGeneratorListener in order to set AbstractBlock Location reference - write an XHTML renderer that also print location. Please tell if you think something is wrong. Thanks, Lucien Pereira

15 years, 6 months

[xwiki-devs] [Proposal] - Adding a "Getting Started" space in the default XWiki Enterprise XAR

by Guillaume Lerouge

Hi, Ludovic pointed out to me that many wikis include some kind of tutorial space explaining what a wiki is and how it can be used. I have checked PBWiki & Confluence and both of them include a couple pages explaining what's a wiki. On top of this, the current homepage, which included some information about what a wiki is and what it can be used for, will soon be replaced by a nicer one with way less content. Thus I'd like to contribute a XAR with 4-5 pages helping new users getting started with our wiki. Here's what I'd envision for the XAR's contents: - What's a wiki and what can it be used for - Edit a page and create a link - Change your wiki's logo and move the panels around - Protect the wiki (basic rights setup for a couple configurations: public / private wiki) Basically the first steps most XWiki users will undertake when arriving on a blank XWiki Enterprise instance. Thus I'd like your PoW on 1) the idea itself & 2) contents to include (keep in mind that this should stay short though). If it's welcomed positively, do I need to send a vote? If the idea is accepted I'll handle the technical details with JV & Ludo. Thanks, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/

15 years, 6 months

[xwiki-devs] [Proposal]Chart macro - Create new com.xpn.xwiki.plugin.charts.source.DataSource for it

by Dan Miron

Hi guys, In order to implement the chart macro (http://jira.xwiki.org/jira/browse/XWIKI-2883) , i propose the following: - Create a new TableBlockDataSource which implements the com.xpn.xwiki.plugin.charts.source.DataSource and which will take data from a table contained within a Wiki2.0 document. - Use the existing ChartPlugin for aquiring this new data source and generate the graph. This new datasource, in order to be compatible with the chartPlugin, gets its parameters via a Map<String, String>. So I'm thinking of passing the current document and the table number as strings encoded in such a Map and then, in the datasource parsing the document and getting its DOM tree and then extracting the data from it. What do you think about this approach? Tnx, Dan

15 years, 6 months

[xwiki-devs] [Rendering] {{html}} macro should only accept valid html, right?

by Vincent Massol

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

15 years, 6 months

[xwiki-devs] Translation Volunteers needed

by Ludovic Dubost

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

15 years, 6 months

[xwiki-devs] [Proposal] WYSIWYG Roadmap (updated)

by Jean-Vincent Drean

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.

15 years, 6 months

[xwiki-devs] [Proposal]Create symbol/icon/emoticon macro

by Dan Miron

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

15 years, 6 months

[xwiki-devs] [Rendering/Wysiwyg] Transformations and WYSIWYG

by Vincent Massol

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

15 years, 6 months

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

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)

15 years, 6 months

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

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]

15 years, 6 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2009