xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

by Vincent Massol

Just wanted to let you know I have started a new personal blog at http://massol.net which will talk a lot about XWiki (amongst other things). Hope you'll enjoy it. Thanks -Vincent http://xwiki.com http://massol.net http://xwiki.org

16 years, 1 month

[xwiki-devs] [Ideas] Some goals for 2009

by Vincent Massol

Here are some 5 ideas from what I'd like us to do in 2009... 1) Get more known * Reach 20K downloads per month (we're at 10K+ right now) * Double our mailing lists subcribers (we're at 509 on the users list and 264 on the devs list) * Double our email flow on the lists (that is probably related to the point above) (we're at 2500 mails per month roughly) * More talks about XWiki at conferences * More articles on the web about xwiki 2) Finish moving to an all-component architecture 3) Reorganize xwiki.org and establish XWiki as a place where to find components for writing content-based web applications 4) Start a bounty system and create a thriving community of XWiki extensions (apps, macros, extensions, etc) for code.xwiki.org 5) Work on better polishing what we have already and stabilize everything Note: This is not a roadmap! It's just some ideas thrown out for fun and to see what everyone's wishes are for 2009 :) What are your wishes for 2009? Thanks -Vincent http://xwiki.com http://massol.net http://xwiki.org

16 years, 1 month

Re: [xwiki-devs] [xwiki-notifications] r14997 - in sandbox/xwiki-officeimporter: . src/main/java/org/xwiki/officeimporter/html/cleaner src/main/java/org/xwiki/officeimporter/transformer src/main/java/org/xwiki/officeimporter/utils

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2009-01-01 11:43:23 +0100 (Thu, 01 Jan 2009) > New Revision: 14997 > > Modified: > sandbox/xwiki-officeimporter/pom.xml > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/html/cleaner/OfficeImporterHTMLCleaner.java > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/transformer/HtmlToXWikiPresentationTransformer.java > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/transformer/HtmlToXWikiTransformer.java > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/transformer/HtmlToXWikiTwoZeroTransformer.java > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/transformer/OfficeToHtmlTransformer.java > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/utils/ImporterContext.java > Log: > * Fixed compile errors > * Fixed failing test cases > > However I couldn't get rid of following two test scoped dependencies despite all my efforts : > > 2. > > <dependency> > <groupId>com.xpn.xwiki.platform</groupId> > <artifactId>xwiki-core</artifactId> > <version>${pom.version}</version> > <scope>test</scope> > </dependency> > > This is something I don't have any clue about. Removing this dependency breaks the tests with following trace : http://tinypaste.com/pre.php?id=10b99 > > I initially thought this is because DefaultDocumentAccessBridge is defined inside xwiki-core (by looking at the trace). But xwiki-redering faces the same situation but avoids this xwiki-core dependency. I wonder if the dependency on xwiki-velocity module has to do something with this. For testing, xwiki-rendering defines its own mock implementation of the document access bridge. You should look in the src/test directory of xwiki-rendering to see what it does there. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 1 month

[xwiki-devs] Listing requirements for the new XWiki Model 2.0 module

by Vincent Massol

Hi everyone, In order to design the new model module we need to list the requirements for it. Here are some I have found by reviewing existing mailing on our list: * Notions of: ** multi wiki ** wiki ** space ** document ** document metadata (language, syntax id, etc) ** document objects ** document classes ** attachment * UUIDs for Documents, Spaces, Wikis, Farms ** Ability to have multiple URIs for model objects * Nested spaces * Ability to version model objects * Ability to add metadata to model objects * Easy to use API (typed API) * Simple API to get other sub elements in model objects (for ex: ability to get documents in a given space). More complex retrieval API in the Query Manager * Authentication/Authorization relationship with model to be defined ** Should checks be done outside of the model module? ** Should we use JAAS and if so what's the relationship * Allow inheritance for document objects/classes ** objects with more than 1 class? (sergiu) * Observation: Ability to get callbacks when objects are modified/ created/removed * Ability to lock model objects to prevent modifications in some cases (when someone is already modifying them or if the wiki is in readonly mode for example) Are there any requirements I've missed? Thanks -Vincent http://xwiki.com http://massol.net http://xwiki.org

16 years, 1 month

Re: [xwiki-devs] [xwiki-notifications] r14999 - platform/web/trunk/standard/src/main/webapp/templates

by Sergiu Dumitriu

Any reason why these files were changed? If not, they should be rolled back. ludovic (SVN) wrote: > Author: ludovic > Date: 2009-01-01 11:57:53 +0100 (Thu, 01 Jan 2009) > New Revision: 14999 > > Modified: > platform/web/trunk/standard/src/main/webapp/templates/attachmentsinline.vm > platform/web/trunk/standard/src/main/webapp/templates/attachwysiwyg.vm > platform/web/trunk/standard/src/main/webapp/templates/macros.vm > platform/web/trunk/standard/src/main/webapp/templates/uploadattachwysiwyg.vm > Log: > XWIKI-3060 Adding Google calendar velocity macros to the core > > Modified: platform/web/trunk/standard/src/main/webapp/templates/attachmentsinline.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/attachmentsinline.vm 2009-01-01 10:56:59 UTC (rev 14998) > +++ platform/web/trunk/standard/src/main/webapp/templates/attachmentsinline.vm 2009-01-01 10:57:53 UTC (rev 14999) > @@ -31,7 +31,7 @@ > <div id="_attachments"> > #if($attachments.size()>0) > #foreach ($attach in $attachments) > - <div class="attachment #if($velocityCount % 2 == 0) even #else odd #end"> > + <div class="displayers #if($velocityCount % 2 == 0) even #else odd #end"> > <span class="mime">#mimetypeimg($attach.getMimeType().toLowerCase() $attach.getFilename().toLowerCase())</span> > <div class="information"> > <span class="name"><a href="$doc.getAttachmentURL("${attach.filename}", "download")" title="$msg.get("downloadthisattachment")">#packName($attach.filename)</a></span> > > Modified: platform/web/trunk/standard/src/main/webapp/templates/attachwysiwyg.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/attachwysiwyg.vm 2009-01-01 10:56:59 UTC (rev 14998) > +++ platform/web/trunk/standard/src/main/webapp/templates/attachwysiwyg.vm 2009-01-01 10:57:53 UTC (rev 14999) > @@ -9,7 +9,7 @@ > <br /><br /> > $msg.get("choosefiletoupload"): > <input type="file" name="filepath" value="" size="40" /> <br /><br /> > - <input type="submit" id="attachment" name="attachment" value="$msg.get("attachthisfile")" /> > + <input type="submit" id="displayers" name="displayers" value="$msg.get("attachthisfile")" /> > </p> > </form> > #set($counter=0) > Modified: platform/web/trunk/standard/src/main/webapp/templates/uploadattachwysiwyg.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/uploadattachwysiwyg.vm 2009-01-01 10:56:59 UTC (rev 14998) > +++ platform/web/trunk/standard/src/main/webapp/templates/uploadattachwysiwyg.vm 2009-01-01 10:57:53 UTC (rev 14999) > @@ -7,6 +7,6 @@ > $msg.get("choosefiletoupload"): > <input type="file" name="filepath" value="" size="40" /> <br /><br /> > #set($action = $doc.getURL("upload")) > - <input type="button" id="attachment" name="attachment" onclick="updateAttachName(document.forms.attach); document.forms.attach.action = '$action' ; document.forms.attach.submit();" value="$msg.get("attachthisfile")" /> > + <input type="button" id="displayers" name="displayers" onclick="updateAttachName(document.forms.attach); document.forms.attach.action = '$action' ; document.forms.attach.submit();" value="$msg.get("attachthisfile")" /> > </p> > </div> > \ No newline at end of file -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 1 month

Re: [xwiki-devs] [xwiki-notifications] r15020 - in platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml: html internal/html

by Vincent Massol

Hi Asiri, You absolutely need a JIRA issue for this! Actually you would also normally need a vote since you're modifying a public API but it's probably ok.... See also the comments below. On Jan 2, 2009, at 5:07 PM, asiri (SVN) wrote: > Author: asiri > Date: 2009-01-02 17:07:40 +0100 (Fri, 02 Jan 2009) > New Revision: 15020 > > Modified: > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > HTMLCleaner.java > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/ > html/DefaultHTMLCleaner.java > Log: > * Introduced a clean(Reader html, Map<String, String> params) method > to the HTMLCleaner interface. > > Modified: platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/ > html/HTMLCleaner.java > =================================================================== > --- platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > HTMLCleaner.java 2009-01-02 15:42:50 UTC (rev 15019) > +++ platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > HTMLCleaner.java 2009-01-02 16:07:40 UTC (rev 15020) > @@ -20,12 +20,13 @@ > package org.xwiki.xml.html; > > import java.io.Reader; > +import java.util.Map; > > import org.w3c.dom.Document; > > /** > * Transforms any HTML content into valid XHTML that can be feed to > the XHTML Parser for example. > - * > + * > * @version $Id: $ > * @since 1.6M1 > */ > @@ -43,4 +44,14 @@ > * @return the cleaned HTML as a w3c DOM (this allows further > transformations if needed) > */ > Document clean(Reader originalHtmlContent); > + > + /** > + * Transforms any HTML content into valid XHTML. Additional > parameters may be passed in to fine tune the cleaning > + * process. > + * > + * @param originalHtmlContent The original html content to be > cleaned. > + * @param params Additional parameters (implementation > dependent) for cleaning. > + * @return The cleaned HTML as a w3c DOM You should use "the" and not "The". See http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle which points to http://java.sun.com/j2se/javadoc/writingdoccomments/ > > + */ > + Document clean(Reader originalHtmlContent, Map<String, String> > params); Can you rename params to cleaningParameters since this is more explicit and this is what we discussed? > > } > > Modified: platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/ > internal/html/DefaultHTMLCleaner.java > =================================================================== > --- platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/ > internal/html/DefaultHTMLCleaner.java 2009-01-02 15:42:50 UTC (rev > 15019) > +++ platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/ > internal/html/DefaultHTMLCleaner.java 2009-01-02 16:07:40 UTC (rev > 15020) > @@ -24,6 +24,7 @@ > import java.io.StringReader; > import java.util.ArrayList; > import java.util.List; > +import java.util.Map; > > import org.htmlcleaner.CleanerProperties; > import org.htmlcleaner.CleanerTransformations; > @@ -64,20 +65,20 @@ > this.filters = new ArrayList<CleaningFilter>(); > this.filters.add(new ListCleaningFilter()); > this.filters.add(new DocTypeCleaningFilter()); > - > + > // The clean method below is thread safe. However it seems > that DOMOutputter.output() is not > // fully thread safe since it causes the following exception > on the first time it's called > // from different threads: > - // Caused by: org.jdom.JDOMException: Reflection failed > while creating new JAXP document: > - // duplicate class definition: org/apache/xerces/jaxp/ > DocumentBuilderFactoryImpl > - // at > org.jdom.adapters.JAXPDOMAdapter.createDocument(JAXPDOMAdapter.java: > 191) > - // at > org > .jdom > .adapters.AbstractDOMAdapter.createDocument(AbstractDOMAdapter.java: > 133) > - // at > org.jdom.output.DOMOutputter.createDOMDocument(DOMOutputter.java:208) > - // at > org.jdom.output.DOMOutputter.output(DOMOutputter.java:127) > + // Caused by: org.jdom.JDOMException: Reflection failed > while creating new JAXP document: > + // duplicate class definition: org/apache/xerces/jaxp/ > DocumentBuilderFactoryImpl > + // at > org.jdom.adapters.JAXPDOMAdapter.createDocument(JAXPDOMAdapter.java: > 191) > + // at > org > .jdom > .adapters.AbstractDOMAdapter.createDocument(AbstractDOMAdapter.java: > 133) > + // at > org.jdom.output.DOMOutputter.createDOMDocument(DOMOutputter.java:208) > + // at org.jdom.output.DOMOutputter.output(DOMOutputter.java: > 127) Why did you remove the white space I had put to indent the stack trace? :) > > // Since this only happens once, we call it first here at > initialization time (since there's > // no thread contention at that time). > // Note: This email thread seems to say it's thread safe but > that's not what we see here: > - // http://osdir.com/ml/text.xml.xforms.chiba.devel/2006-09/msg00025.html > + // http://osdir.com/ml/text.xml.xforms.chiba.devel/2006-09/msg00025.html same here. > > clean(new StringReader("")); > } > > @@ -90,25 +91,30 @@ > { > org.w3c.dom.Document result; > > - // HtmlCleaner is not threadsafe. Thus we need to recreate > an instance at each run since otherwise > - // we would need to synchronize this clean() method which > would slow down the whole system by > + // HtmlCleaner is not threadsafe. Thus we need to recreate > an instance at each run since > + // otherwise Why did you break at 100 chars when we are breaking at 120? > > + // we would need to synchronize this clean() method which > would slow down the whole system > + // by > // queuing up cleaning requests. > - // See http://sourceforge.net/tracker/index.php?func=detail&aid=2139927&group_id=1… > + // See > + // http://sourceforge.net/tracker/index.php?func=detail&aid=2139927&group_id=1… > + // 903699 Same here. > > HtmlCleaner cleaner = new HtmlCleaner(); > cleaner.setTransformations(getCleaningTransformations()); > CleanerProperties cleanerProperties = cleaner.getProperties(); > cleanerProperties.setOmitUnknownTags(true); > > - // By default HTMLCleaner treats style and script tags as > CDATA. This is causing errors if we use > + // By default HTMLCleaner treats style and script tags as > CDATA. This is causing errors if > + // we use > // the best practice of using CDATA inside a script. For > example: > - // <script type="text/javascript"> > - // //<![CDATA[ > - // ... > - // // ]]> > - // </script> > + // <script type="text/javascript"> > + // //<![CDATA[ > + // ... > + // // ]]> > + // </script> > // Thus we need to turn off this feature. > cleanerProperties.setUseCdataForScriptAndStyle(false); > - > + > TagNode cleanedNode; > try { > cleanedNode = cleaner.clean(originalHtmlContent); > @@ -120,7 +126,7 @@ > > // Fix cleaned node bug > fixCleanedNodeBug(cleanedNode); > - > + > Document document = new JDomSerializer(cleanerProperties, > false).createJDom(cleanedNode); > > // Perform other cleaning operation this time using the W3C > Document interface. > @@ -139,9 +145,20 @@ > } > > /** > - * @return the cleaning transformations to perform on tags, in > addition to the base transformations done by > - * HTML Cleaner > + * {@inheritDoc} > + * <p> > + * {@link DefaultHTMLCleaner} does not allow fine-tuning of > html cleaning via parameters. > + * </p> > */ > + public org.w3c.dom.Document clean(Reader originalHtmlContent, > Map<String, String> params) > + { > + return clean(originalHtmlContent); the params don't seem to be used? > > + } > + > + /** > + * @return the cleaning transformations to perform on tags, in > addition to the base transformations done by HTML > + * Cleaner > + */ > private CleanerTransformations getCleaningTransformations() > { > CleanerTransformations transformations = new > CleanerTransformations(); > @@ -174,9 +191,9 @@ > } > > /** > - * There's a known limitation (bug?) in HTML Cleaner where if > there's a XML declaration specified > - * it'll be copied as the first element of the body. Thus > remove it if it's there. > - * See https://sourceforge.net/forum/message.php?msg_id=4657800 > + * There's a known limitation (bug?) in HTML Cleaner where if > there's a XML declaration specified it'll be copied as > + * the first element of the body. Thus remove it if it's there. > See > + * https://sourceforge.net/forum/message.php?msg_id=4657800 > * > * @param cleanedNode the cleaned node (ie after the HTML > cleaning) > */ Thanks -Vincent http://xwiki.com http://massol.net http://xwiki.org

16 years, 1 month

Re: [xwiki-devs] [Issue] Commented: (XAOFFICE-1) Develop the initial feature set for office-importer plugin.

by Asiri Rathnayake

Hi vincent, Vincent Massol commented on XAOFFICE-1: > --------------------------------------- > > 31-12-2008 Review: > * Invalid dep: Log4j Fixed. * components must be in an internal package, see > http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikisp… Fixed. > * Abstract classes must have Abstract in their name as a prefix. > OfficeImporterHTMLCleaner is not following this. See > http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle Fixed * OfficeImporterHTMLCleaner should be named AbstractOfficeHTMLCleaner Fixed. * I don't think that the default/strict/moderate thing should be implemented > as components. IMO there should be a singme OpenOfficeHTMLCleaner and a > single MicrosoftOfficeHTMLCleaner and the interface signature should be > something like: clean(Reader, CleaningStrategy) where CleaningStrategy is an > enum of STRICT, MODERATE or LENIENT. The reason is that it's a property of > the cleaning IMO and not a different type of cleaner. Fixed. * The org.xwiki.officeimporter.html.cleaner package should be instead > org.xwiki.officeimporter.cleaner. No need for "html" since we don't have > any other cleaner. > * org.xwiki.officeimporter.html.filter should renamed to > org.xwiki.officeimporter.cleaner.filter Fixed. * Don't use public static final String in an interface since String are > always public static final in interfaces! Fixed. * Fix javadoc errors Partially Fixed (working on it) * I have no idea why we need a special cleaner WysiwygDefaultHTMLCleaner and > the javadoc doesn't help to understand the reason. Need to improve the javadoc comments. * OfficeImporter.import takes a byte[] array. I don't think this is a good > idea since you'd also need to specify the encoding. Better use a Reader. As I explained, office documents are binary files. So this has to be a byte[]. * OfficeImporterVelocityContextInitializer should be in the internal package Fixed. * "private static final String[] presentationFormatExtensions" private > static final strings should be in uppercase. Also this would be better as an > enum. Fixed. * I don't understand the notion of Transformer. What's the difference > between Transformer and Importer? Transformers are now inside internal package and they are not components anymore. Importer is composed of DocumentTransformers. * components that wants logging must extend AbstractLogEnabled Fixed. * filters need to be reorganized. There are too many notions mixed together: > strict/lenient/moderate vs ImageFilter/Etc I'm not sure how to do this. Unlike other filters, ImageFilter needs to have access to the original XWikiDocument (via DocumentAccessBridge) other than the w3c DOM. This is because when cleaning image links, the src attribute need to be replaced by the corresponding attachment url. This is why I introduced XWikiHTMLCleaner which takes in the OfficeImporterContext in addition to the w3c dom. * there shouldn't be a utils package Fixed. * role hints should be simpler and lowercase Fixed. * there are no tests! Few added. More unit/integration tests will be added. > * there are test resources but they're not used! > Fixed (Removed) Thanks. - Asiri

16 years, 1 month

[xwiki-devs] [VOTE] Support mixed syntaxes for lists

by Thomas Mortagne

Hi xwikiers, Currently XWiki 2.0 only support the same way of mixing lists than XWiki 1.0: --------------------- 1. item 1 1*. item 2 1*. item 3 1. item 4 --------------------- This only support two syntaxes : the default ordered numbers and the default point list. Plus It does not sounds very natural to me. I propose to be able to really mix list syntaxes without any particular syntax: ------------------------------ 1. item 1 ** item 2 (% style="list-style-type: lower-alpha" %) *** subitem 2.1 *** subitem 2.2 ** item 3 1. item 4 --------------------------- Currently this generate 5 different lists: <ol> <li>item 1</li> </ol> <ul> <li> <ul> <li>item 2</li> <li>item 3</li> </ul> </li> </ul> <ul style="list-style-type: lower-alpha"> <li> <ul> <li> <ul> <li>subitem 2.1</li> <li>subitem 2.2</li> </ul> </li> </ul> </li> </ul> <ul> <li> <ul> <li>item 3</li> </ul> </li> </ul> <ol> <li>item 4</li> </ol> Also another problem is also that this will generate a very different XWiki syntax that the original one. I propose to generate only one big list giving something like: <ol> <li> item 1 <ul> <li> item 2 <ul style="list-style-type: lower-alpha"> <li>subitem 2.1</li> <li>subitem 2.2</li> </ul> </li> <li> item 3</li> </ul> </li> <li> item 4</li> </ol> Here is my +1 Thanks, -- Thomas Mortagne

16 years, 1 month

Re: [xwiki-devs] [xwiki-notifications] r14932 - platform/core/trunk/xwiki-macros/xwiki-macro-groovy

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-12-27 17:18:10 +0100 (Sat, 27 Dec 2008) > New Revision: 14932 > > Modified: > platform/core/trunk/xwiki-macros/xwiki-macro-groovy/pom.xml > Log: > XWIKI-3038: Move Groovy dependency to 1.6 RC1 > > Modified: platform/core/trunk/xwiki-macros/xwiki-macro-groovy/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-macros/xwiki-macro-groovy/pom.xml 2008-12-27 16:17:57 UTC (rev 14931) > +++ platform/core/trunk/xwiki-macros/xwiki-macro-groovy/pom.xml 2008-12-27 16:18:10 UTC (rev 14932) > @@ -41,7 +41,7 @@ > <dependency> > <groupId>com.sun.script</groupId> > <artifactId>groovy-engine</artifactId> > - <version>1.6-beta-2-xwiki</version> > + <version>1.6-RC-1-xwiki</version> Why are we using a custom build of Groovy? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 1 month

[xwiki-devs] Include 2 patches in 1.7.1

by Ludovic Dubost

Hi, I would like to vote to include the 2 following patches on 1.7.1. They would allow Curriki to run on the standard 1.7.1 core (except for Lucene which has other changes). http://jira.xwiki.org/jira/browse/XWIKI-3054 Support configurable velocity macro files in xwiki.cfg http://jira.xwiki.org/jira/browse/XWIKI-3054 Fix a bug which prevents to use "order by" in queries on DBListClass Both patches have been used successfully on a custom 1.5.2 based core in Curriki Here is my +1 Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs