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

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 05 Nov '08

05 Nov '08

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]

3 6

[xwiki-devs] [Proposal] Support use of local and external JS libs with JSX
by Jerome Velociter 05 Nov '08

05 Nov '08

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.

3 6

[xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros
by Jerome Velociter 05 Nov '08

05 Nov '08

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.

3 8

[xwiki-devs] [proposal] Use exclusively css to mark links towards new pages
by Anca Paula Luca 04 Nov '08

04 Nov '08

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

6 7

Re: [xwiki-devs] [xwiki-notifications] r13945 - sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/plugin/officeimporter/filter
by Vincent Massol 04 Nov '08

04 Nov '08

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

2 1

Re: [xwiki-devs] [xwiki-notifications] r13944 - sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/plugin/officeimporter/transformer
by Vincent Massol 04 Nov '08

04 Nov '08

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

2 2

[xwiki-devs] [XAOFFICE] [Proposal] Should we respect style / font attributes when importing office documents ?
by Asiri Rathnayake 04 Nov '08

04 Nov '08

Hi Devs, When converting office documents into html (before they are transformed into xwiki syntax) lots of style information gets added into the html. For an example : <p class="western">Text in a <sup><span style="color:;font-family=;font-size=2pt;">superscript</span></sup>format</p> And finally when this is transformed into xwiki syntax, the result will look something like : (% class="western" %) Text in a ^^(% style="color:;font-family=;font-size=2pt;" %)superscript^^(%%) format The problem with this is, the resulting xwiki document will have lot's of (%%) elements which makes it difficult to make modifications in wiki mode. And another argument is that content is more important than style (vincent). So, there are three options : 1. Rip off style information. 2. Keep style information as it is. 3. Give the user an option to select between 1 and 2. I'm going with 3. :) WDYT ? Thanks. - Asiri [image: Asiri Rathnayake's Facebook profile]<http://www.facebook.com/people/Asiri_Rathnayake/534607921>

8 13

Re: [xwiki-devs] [xwiki-notifications] r13942 - 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 04 Nov '08

04 Nov '08

Hi Asiri, On Nov 4, 2008, at 5:47 AM, asiri (SVN) wrote: > Author: asiri > Date: 2008-11-04 05:47:05 +0100 (Tue, 04 Nov 2008) > New Revision: 13942 > > Added: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/HtmlFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/HtmlStylesFilter.java > Removed: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/HTMLFilter.java > Modified: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/EmptyLinkFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/ImageTagFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/PinLiFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/TagRemoveFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/UnderlineLinkFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/XWikiSyntaxEscapeFilter.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/transformer/HtmlToXWikiTransformer.java > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/transformer/HtmlToXWikiTwoZeroTransformer.java > 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: > JIRA : http://jira.xwiki.org/jira/browse/XAOFFICE-1 This is not the way we use to comment. Please use instead this format: XAOFFICE-1: <description of issue as in jira here> * Additional information here Thanks -Vincent

2 1

[xwiki-devs] XWikiContext cloning
by Sergiu Dumitriu 04 Nov '08

04 Nov '08

Hi devs, We all know that the old XWikiContext is a burden that must still be carried around, in order to access any non-componentized functionality. The problem is that a context object is not supposed to be used by more than one thread. Example of non-threadsafe parts of the context are: - the Hibernate session - the request and response objects, cleared by the container - the velocity context - the XClass cache - the current wiki name - and maybe others This single-thread restriction is generally acceptable, since most of the code is executed in the single-threaded request-response workflow. Yet, some plugins execute in separate threads, for example the Lucene indexer and the scheduler plugin, and they need their XContext object. The current strategy is to clone the context and remove some of the dangerous elements listed above. This is not good, since: - it has to be done in every plugin that creates threads (duplication) - adding more non-threadsafe things to the context requires that all these plugins are changed - some non-threadsafe things might not yet be identified, and they surface sometimes as unidentified bugs - some things cannot be cleared from the outside (for example the XClass cache, which is a private member of the context) There are several solutions to this problem: 1. Override the clone() method to remove non-threadsafe elements from the cloned context. Pro: removes duplication Pro: establishes a safe clone method for all the codebase Con: some unsafe things might be overlooked, surfacing from time to time in rare thread inter-weaving. 2. Override the clone() method to create a blank context and only copy what needs to be part of any context. Pro: same as above, but also eliminates all possible non-threadsafe elements. Con: We might overlook something that needs to be part of the context. The advantage over option 1 is that this is always reproducible, and a simple stack trace is enough to spot the problem, unlike multithreaded issues. Con: We might introduce a regression, this needs to be tested well. 3. Override the clone() method to just eliminate non-threadsafe things that are unaccessible from outside (the XClass cache is the only one I see). Pro: keeps the current behavior, reducing the risk of regressions. Con: Doesn't really solve the problem. I'd go with option 2. Any other opinions? -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 1

Re: [xwiki-devs] [xwiki-notifications] r13932 - sandbox/plugins/comments
by Vincent Massol 03 Nov '08

03 Nov '08

There's something wrong here. All projects in sandbox should use the SANDBOX JIRA project and only move to their own jira project when they graduate out of the sandbox. We have the exact same problem for the XOFFICE JIRA project. Let's leave them like this for now but please in the future follow this rule (which we had agreed on previously on the dev list). Thanks -Vincent PS: I should have raised this earlier on but I'm lagging behind on my mail on the list... On Nov 3, 2008, at 5:26 PM, jvelociter (SVN) wrote: > Author: jvelociter > Date: 2008-11-03 17:26:43 +0100 (Mon, 03 Nov 2008) > New Revision: 13932 > > Modified: > sandbox/plugins/comments/pom.xml > Log: > XACOMMENTS-1 Implement the initial feature set of the new comments > application > > * Set the plugin version to 1.0-SNAPSHOT > * Temporary set the dependency towards xwiki-core to 1.5.2, until I > resolve the need to have a patched core. (Currently, one need to > patch the 1.5.2 tag of xwiki-core to be able to build this comments > plugin.) > > Modified: sandbox/plugins/comments/pom.xml > =================================================================== > --- sandbox/plugins/comments/pom.xml 2008-11-03 13:18:22 UTC (rev > 13931) > +++ sandbox/plugins/comments/pom.xml 2008-11-03 16:26:43 UTC (rev > 13932) > @@ -31,7 +31,7 @@ > <version>10-SNAPSHOT</version> > </parent> > <artifactId>xwiki-plugin-comments</artifactId> > - <version>0.1-SNAPSHOT</version> > + <version>1.0-SNAPSHOT</version> > <name>XWiki Platform - Plugins - Comments</name> > <packaging>jar</packaging> > <description>XWiki Platform - Plugins - Comments</description> > @@ -39,7 +39,7 @@ > <dependency> > <groupId>com.xpn.xwiki.platform</groupId> > <artifactId>xwiki-core</artifactId> > - <version>1.6-SNAPSHOT</version> > + <version>1.5.2</version> > <scope>provided</scope> > </dependency> > </dependencies>

2 4