xwiki-devs November 2008

xwiki-devs@xwiki.org

36 participants
108 discussions

by Paul Bernard

I don't see documentation anywhere which identifies which versions of jar files are being used (lucene, ecache, etc.). Is there a way to find this out? Also a way to know which versions are being used in a pending release? Thanks, Paul Bernard

15 years, 10 months

[xwiki-devs] [Proposal] Make XHTML macro not parse wiki syntax by default

by Vincent Massol

Hi, Right now the XHTML macro parses wiki syntax by default. For example the following generates a bold: {{xhtml}} <p>**bold**</p> {{/xhtml}} I propose to change that so that wiki syntax is not parsed by default so that users will need to use the following to parse wiki syntax: {{xhtml wiki=true}} <p>**bold**</p> {{/xhtml}} Note that I'm proposing to change the current "escapeWikiSyntax" to "wiki" (another proposal is to use "allowWikiSyntax"). WDYT? Thanks -Vincent

15 years, 10 months

[xwiki-devs] [VOTE] add glassfish/derby distribution and move jetty distributions in jetty subfolder

by Thomas Mortagne

Hi devs, Since the general discussion about distributions (see http://markmail.org/message/nqyvd34knm5eqkru) will need some time and I need to commit the glasshfish distribution build as soon as possible, I propose: - add a folder "glassfish" - add a "derby" subfolder containing the glassfish-derby distribution build - move all jetty related distributions in "jetty" folder et same lever than "glassfish" and change all artifact ids as xwiki-enterprise-jetty-* (xwiki-enterprise-jetty-hsqldb, xwiki-enterprise-jetty-derby, etc.) - use -Pglassfish to build glassfish and -Pjetty to build jetty (jetty being the default one to not change anything to current build except for the artifacts ids) here is my +1 WDYT ? -- Thomas Mortagne

15 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r13949 - in sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/plugin/officeimporter: filter transformer

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2008-11-04 11:31:26 +0100 (Tue, 04 Nov 2008) > New Revision: 13949 > + private void filter(Node node) > + { > + if (node.hasAttributes()) { > + try { > + node.getAttributes().removeNamedItem("style"); > + } catch (DOMException ex) { > + // Not a problem. > + } > + } I don't like this... try-catch code is costly, since creating an exception takes a lot of time and memory. Can't you check if the 'style' attribute exists instead? And a catch block in general should indicate an exceptional execution, not a normal, expected case. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r13965 - in sandbox/xwiki-plugin-officeimporter/src: main/java/com/xpn/xwiki/plugin/officeimporter/filter main/java/com/xpn/xwiki/plugin/officeimporter/transformer test/java/com/xpn/xwiki/plugin/officeconverter

by Vincent Massol

On Nov 5, 2008, at 6:32 AM, asiri (SVN) wrote: > Author: asiri > Date: 2008-11-05 06:32:43 +0100 (Wed, 05 Nov 2008) > New Revision: 13965 > > Added: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/ImgToWikiFilter.java > Removed: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/ImageTagFilter.java > Modified: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/transformer/HtmlToXWikiXhtmlTransformer.java > sandbox/xwiki-plugin-officeimporter/src/test/java/com/xpn/xwiki/ > plugin/officeconverter/HtmlFilterTest.java > Log: > Renamed the ImageTagFilter as ImgToWikiFilter to make more sense. > This filter is only used with xhtml rendering. Funnily I don't understand what ImgToWikiFilter means whereas ImageTagFilter is very expressive to me (it performs some filtering on image tags). I don't understand what an image to wiki means. Also I don't understand why we need this filter since it converts to XWiki Syntax 1.0 which we're not supporting. Thanks -Vincent [snip]

15 years, 10 months

[xwiki-devs] [Proposal] Support use of local and external JS libs with JSX

by Jerome Velociter

Hello, Following the open question #1 here http://dev.xwiki.org/xwiki/bin/view/Design/SkinExtensions#HUsage " Open question 1: Should $jsx.useFile("filename.js") work for files located on the disk? This allows the same pull process to be used with files located in the skin, without requiring SX documents and objects. I'd say yes. Then, what should the URL look like? /xwiki/bin/jsx/skins/albatross/somestyle.css is OK? " I would like to propose to go even further, and to allow injection of script tags referring libraries on the cloud or on a different server using the jsx plugin. This would allow to not have users writing scripts tags in the body of the document to add a library. I would see something like : $jsx.use("http://maps.google.com/maps?file=api&v=2&key=XXX") or $jsx.useFile("http://maps.google.com/maps?file=api&v=2&key=XXX") What do you think ? Regards, Jerome.

15 years, 10 months

[xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros

by Jerome Velociter

Hello all, I started working on a {{map}} macro (http://jira.xwiki.org/jira/browse/XWIKI-2784). This raise the question of how (or if) we should work when writing macros depending on JS APIs (being here google maps, yahoo maps, etc.). The variants I've envisaged so far : 1a. We write all the needed JavaScript in the macro itself. We do it in Strings we transform in lists of WordBlock + SpaceBlock we append as children of a XMLBlock "script". I find this a little painful and not very natural. 1b. We write all the needed JavaScript in the macro itself. We do it in Strings we pass as content of a html/xhtml macros blocks. 2a. We write most of the JavaScript in a JSX object (for example a sort of facade to some google maps APIs), and only the needed calls in the macro itself (for example the call to load a map in a div element). For the code in the macro, we use the same strategy as 1a, except that there is just one of such XML block, and it's relatively short. The JSX Strategy in 2a/2b has that clear advantage to make it much simpler on the server side, but as a counterpart, the macro needs to be distributed as a xar + jar, while in 1) it's a jar only. 2b. Same as 2a using the strategy in 1b for the part in the macro. This is the way I have my prototype working right now. I admit I don't really know what to think about the fact I'm building macros blocks (a velocity one for the jsx "use" call, and a html one for the javascript call) inside the macro itself. I hope you can tell more about this, and let me know if it's a bad practice. 3. We don't do such macro :) We consider it's not what wiki macro should be and we decide to have such macros only as velocity macros which are much simpler to write in that case. This does not change anything for the wysiwyg users, as far as I understand, but it does for the wiki users.{{map location="Paris, France"}} is much more elegant than {{velocity}}#map("Paris, France"){{/velocity}} ; and is much better too in terms of configuration (in velocity we would need to give values to all parameters, even if we want to use default value for most of them). WDYT ? Are there some variants I did not envisage ? Regards, Jerome.

15 years, 10 months

[xwiki-devs] [proposal] Use exclusively css to mark links towards new pages

by Anca Paula Luca

Hi devs, starting from a Wysiwyg implementation issue, we had a discussion yesterday about marking links towards new pages in the wiki. Right now, a question mark ('?') text is appended to the end of the link label and coloured properly. I would like to change this into using exclusively css, for the following reason: * this question mark represents *styling only*: it's as if we'd colour links towards new pages with a different color (the way mediawiki does), therefore this information (either it's a qm, or colour or whatever) should *not appear as part of the document content*, the way a ? text does (the raw HTML contains it). One method of doing this in CSS is appending the text itself (with :after pseudoelement), but that is not cross-browser, and the other method is using an image for the question mark. I'm +1 for the image qm for 2 more reasons (besides the cross browser issue): * this information would not append to document content at all (e.g. if I copied the rendered document content in an ascii editor, I wouldn't have the ?) * it is a solution closer to the colour solution or marking the link to a new page with a non-character sign (see, for example, the way mediawiki marks external links) -- we can decide to change that anytime and we *don't have to change rendering rules* which makes very much sense to me. Here's the issue on JIRA for this solution: http://jira.xwiki.org/jira/browse/XWIKI-2803 WDYT? Happy coding, Anca Luca

15 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r13945 - sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/plugin/officeimporter/filter

by Vincent Massol

On Nov 4, 2008, at 7:36 AM, asiri (SVN) wrote: > Author: asiri > Date: 2008-11-04 07:36:17 +0100 (Tue, 04 Nov 2008) > New Revision: 13945 > > Added: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/StyleFixFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/TableFixFilter.java > Log: > JIRA : http://jira.xwiki.org/jira/browse/XAOFFICE-1 > > Introduced two fix filters. These filters pre-process the xhtml > document so that rendering via xwiki 2.0 syntax renderer produces > acceptable results. > > Copied: sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/ > xwiki/plugin/officeimporter/filter/StyleFixFilter.java (from rev > 13943, sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/ > xwiki/plugin/officeimporter/filter/HtmlStylesFilter.java) > =================================================================== > --- sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/ > StyleFixFilter.java (rev 0) > +++ sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/StyleFixFilter.java 2008-11-04 06:36:17 > UTC (rev 13945) > @@ -0,0 +1,56 @@ > +package com.xpn.xwiki.plugin.officeimporter.filter; > + > +import org.w3c.dom.DOMException; > +import org.w3c.dom.Document; > +import org.w3c.dom.Element; > +import org.w3c.dom.Node; > +import org.w3c.dom.NodeList; > + > +/** > + * This particular filter searches for {@code <span>} and {@code > <div>} tags containing style > + * attributes and removes such attributes if present. I don't think this is correct. You should filter style attributes for ALL HTML elements. I have no idea what your second filter does and whether it should be done in the office importer or not. Thanks -Vincent > Also, if the resulting {@code <span>} or > + * {@code <div>} tag has no other attributes, this filter will > completely rip off the tag itself and > + * append the content of the tag into it's parent. > + */ > +public class StyleFixFilter implements HtmlFilter > +{ > + /** > + * Tags that contain style information. > + */ > + private static final String[] styleTags = new String[] {"span", > "div"}; > + > + /** > + * {@inheritDoc} > + */ > + public void filter(Document document) > + { > + Element root = document.getDocumentElement(); > + for (String tagName : styleTags) { > + NodeList tagList = root.getElementsByTagName(tagName); > + for (int i = 0; i < tagList.getLength(); i++) { > + Node tag = tagList.item(i); > + if (tag.hasAttributes()) { > + try { > + tag.getAttributes().removeNamedItem("style"); > + } catch (DOMException ex) { > + // Not a problem. > + } > + } > + // Check if the tag has no more attributes. > + if (!tag.hasAttributes()) { > + // Append the children into parent node. > + Node parentNode = tag.getParentNode(); > + NodeList grandChildren = tag.getChildNodes(); > + for (int j = 0; j < grandChildren.getLength(); j > ++) { > + > parentNode.appendChild(grandChildren.item(j)); > + } > + // Get rid of it. > + parentNode.removeChild(tag); > + // Removing the tag causes the tag list to > collapse. > + // To address this issue, we need to decrement > the counter. > + i--; > + } > + } > + } > + } > +} > > > Property changes on: sandbox/xwiki-plugin-officeimporter/src/main/ > java/com/xpn/xwiki/plugin/officeimporter/filter/StyleFixFilter.java > ___________________________________________________________________ > Name: svn:mergeinfo > + > > Added: sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/ > xwiki/plugin/officeimporter/filter/TableFixFilter.java > =================================================================== > --- sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/ > TableFixFilter.java (rev 0) > +++ sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/TableFixFilter.java 2008-11-04 06:36:17 > UTC (rev 13945) > @@ -0,0 +1,19 @@ > +package com.xpn.xwiki.plugin.officeimporter.filter; > + > +import org.w3c.dom.Document; > + > +/** > + * The purpose of this filter is to pre-adjust the html {@code > <table>} elements so that they are > + * rendered properly in the xwiki 2.0 syntax renderer. This also > implies any formatting elements > + * present in the html which are not compatible with xwiki 2.0 > getting ripped off entirely. > + */ > +public class TableFixFilter implements HtmlFilter > +{ > + /** > + * {@inheritDoc} > + */ > + public void filter(Document document) > + { > + > + } > +} > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

15 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r13944 - sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/plugin/officeimporter/transformer

by Vincent Massol

Hi Asiri, On Nov 4, 2008, at 7:06 AM, asiri (SVN) wrote: > Author: asiri > Date: 2008-11-04 07:06:01 +0100 (Tue, 04 Nov 2008) > New Revision: 13944 > > Modified: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/transformer/HtmlToXWikiTwoZeroTransformer.java > Log: > JIRA : http://jira.xwiki.org/jira/browse/XAOFFICE-1 > > Fixes lists support. <p> tags inside <li> tags are not rendered > properly in xwiki 2.0. Rip them off and it works fine. I don't think this is correct. Either it's valid XHTML to have <P> inside <LI> and in which case it's a bug of the XHTML parser or it's not valid and it's a job for the HTML cleaner. In both cases I don't think this is related to office imports. It's really import that whenever you need a transformation/cleaning that you decide where it should go: * in the XHTML parser * in the HTML cleaner * in the office importer Thanks -Vincent

15 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2008