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

by Vivian Richard

Hi I am trying to use the excel plugin for xwiki enterprise 1.7. Since I am using java 1.6, I downloaded this plugin http://code.xwiki.org/xwiki/bin/view/Plugins/ExcelPluginDownload?version=1.… and followed these instructions: http://code.xwiki.org/xwiki/bin/view/Plugins/ExcelPlugin But with out any result. By the way I am using my windows XP machine. Can someone please point out why it is not working and how can I make it work? Regards.....

16 years, 8 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r15010 - in sandbox/xwiki-officeimporter: . src/main/java/org/xwiki/officeimporter/html/filter src/test/java/org/xwiki/officeimporter/html/cleaner

by Vincent Massol

Hi Asiri, If you want to run your tests with different initial conditions you should use a Test Suite instead and pass the cleaner in the constructor of the Test Case class. That said, I don't see why you'd want to run the same tests again. Since the implementation is the same the result will be the same! What you need to test are the extra things you've added to WysiwygDefaultHTMLCleaner. Thanks -Vincent On Jan 2, 2009, at 7:04 AM, asiri (SVN) wrote: > Author: asiri > Date: 2009-01-02 07:04:20 +0100 (Fri, 02 Jan 2009) > New Revision: 15010 > > Added: > sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/AbstractHTMLCleanerTestCase.java > sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/WysiwygDefaultHTMLCleanerTest.java > Modified: > sandbox/xwiki-officeimporter/pom.xml > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/html/filter/TableFilter.java > sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/OpenOfficeDefaultHTMLCleanerTest.java > Log: > * Added few more test cases. > > Modified: sandbox/xwiki-officeimporter/pom.xml > =================================================================== > --- sandbox/xwiki-officeimporter/pom.xml 2009-01-02 03:59:29 UTC > (rev 15009) > +++ sandbox/xwiki-officeimporter/pom.xml 2009-01-02 06:04:20 UTC > (rev 15010) > @@ -73,4 +73,17 @@ > <scope>test</scope> > </dependency> > </dependencies> > + <build> > + <plugins> > + <plugin> > + <groupId>org.apache.maven.plugins</groupId> > + <artifactId>maven-surefire-plugin</artifactId> > + <configuration> > + <excludes> > + <exclude>**/Abstract*.java</exclude> > + </excludes> > + </configuration> > + </plugin> > + </plugins> > + </build> > </project> > \ No newline at end of file > > Modified: sandbox/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/html/filter/TableFilter.java > =================================================================== > --- sandbox/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/html/filter/TableFilter.java 2009-01-02 03:59:29 UTC > (rev 15009) > +++ sandbox/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/html/filter/TableFilter.java 2009-01-02 06:04:20 UTC > (rev 15010) > @@ -36,12 +36,12 @@ > public class TableFilter implements HTMLFilter > { > /** > - * Tags that need to be removed from cell items. > + * Tags that need to be removed from cell items while > preserving there children. > */ > private static final String[] filterTags = new String[] {"p"}; > > /** > - * Tags that need to be removed from cell items. > + * Tags that need to be completely removed from cell items. > */ > private static final String[] removeTags = new String[] {"br"}; > > @@ -54,7 +54,7 @@ > for (int i = 0; i < cellItems.getLength(); i++) { > Node cellItem = cellItems.item(i); > cleanNode(cellItem); > - // Workaround empty cells. > + // Workaround empty cells. > if (cellItem.getTextContent().equals("")) { > boolean empty = true; > for (int j = 0; j < > cellItem.getChildNodes().getLength(); j++) { > @@ -81,7 +81,13 @@ > NodeList children = node.getChildNodes(); > boolean removed = false; > if (node.getNodeType() == Node.TEXT_NODE) { > - node.setTextContent(node.getTextContent().trim()); > + String trimmedContent = node.getTextContent().trim(); > + if (trimmedContent.equals("")) { > + parent.removeChild(node); > + removed = true; > + } else { > + node.setTextContent(trimmedContent); > + } > } else if (Arrays.binarySearch(filterTags, > node.getNodeName()) >= 0) { > while (children.getLength() > 0) { > Node child = children.item(0); > @@ -95,7 +101,9 @@ > removed = true; > } else { > for (int i = 0; i < children.getLength(); i++) { > - i = cleanNode(children.item(i)) ? i-- : i; > + if (cleanNode(children.item(i))) { > + --i; > + } > } > } > return removed; > > Added: sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/AbstractHTMLCleanerTestCase.java > =================================================================== > --- sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/ > AbstractHTMLCleanerTestCase.java (rev 0) > +++ sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/AbstractHTMLCleanerTestCase.java > 2009-01-02 06:04:20 UTC (rev 15010) > @@ -0,0 +1,112 @@ > +/* > + * 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.officeimporter.html.cleaner; > + > +import java.io.StringReader; > + > +import org.w3c.dom.Document; > +import org.w3c.dom.NodeList; > +import org.xwiki.xml.html.HTMLCleaner; > + > +import com.xpn.xwiki.test.AbstractXWikiComponentTestCase; > + > +/** > + * Abstract test case class for all HTMLCleaner tests. > + * > + * @version $Id$ > + * @since 1.8M1 > + */ > +public class AbstractHTMLCleanerTestCase extends > AbstractXWikiComponentTestCase > +{ > + /** > + * Beginning of the test html document. > + */ > + protected String header = "<html><head><title>Title</title></ > head><body>"; > + > + /** > + * Beginning of the test html document, which has a {@code > <style> tag.} > + */ > + protected String headerWithStyles = > + "<html><head><style type=\"text/css\">h1 {color:red} p > {color:blue} </style><title>Title</title></head><body>"; > + > + /** > + * Ending of the test html document.. > + */ > + protected String footer = "</body></html>"; > + > + /** > + * Test most basic cleaning. > + */ > + public void testBasicCleaning(HTMLCleaner cleaner) > + { > + String html = header + footer; > + Document doc = cleaner.clean(new StringReader(html)); > + assertNotNull(doc.getDoctype()); > + } > + > + /** > + * Test stripping of {@code <style>} and {@code <script>} tags. > + */ > + public void testTagStripping(HTMLCleaner cleaner) > + { > + String html = headerWithStyles + footer; > + Document doc = cleaner.clean(new StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("style"); > + assertEquals(0, nodes.getLength()); > + html = > + header + "<script type=\"text/javascript > \">document.write(\"Hello World!\")</script>" > + + footer; > + doc = cleaner.clean(new StringReader(html)); > + nodes = doc.getElementsByTagName("script"); > + assertEquals(0, nodes.getLength()); > + } > + > + /** > + * Test stripping of redundant tags. > + */ > + public void testRedundancyFiltering(HTMLCleaner cleaner) > + { > + // <span> & <div> tags without attributes should be > stripped off. > + String htmlTemplate = header + "<p>Test%sRedundant > %sFiltering<p>" + footer; > + String[] attributeWiseFilteredTags = new String[] {"span", > "div"}; > + for (String tag : attributeWiseFilteredTags) { > + String startTag = "<" + tag + ">"; > + String endTag = "</" + tag + ">"; > + String html = String.format(htmlTemplate, startTag, > endTag); > + Document doc = cleaner.clean(new StringReader(html)); > + NodeList nodes = doc.getElementsByTagName(tag); > + assertEquals(0, nodes.getLength()); > + } > + // Tags that usually contain textual information like > <strong>, <code>, <em> etc. etc. > + // should be filtered if they do not contain any textual > content. > + htmlTemplate = header + "<p>Test%sRedundant%s%s > %sFiltering<p>" + footer; > + String[] contentWiseFilteredTags = > + new String[] {"em", "strong", "dfn", "code", "samp", > "kbd", "var", "cite", "abbr", > + "acronym", "address", "blockquote", "q", "pre", "h1", > "h2", "h3", "h4", "h5", "h6"}; > + for(String tag: contentWiseFilteredTags) { > + String startTag = "<" + tag + ">"; > + String endTag = "</" + tag + ">"; > + String html = String.format(htmlTemplate, startTag, > endTag, startTag, endTag); > + Document doc = cleaner.clean(new StringReader(html)); > + NodeList nodes = doc.getElementsByTagName(tag); > + assertEquals(1, nodes.getLength()); > + } > + } > +} > > Modified: sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/OpenOfficeDefaultHTMLCleanerTest.java > =================================================================== > --- sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/OpenOfficeDefaultHTMLCleanerTest.java > 2009-01-02 03:59:29 UTC (rev 15009) > +++ sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/OpenOfficeDefaultHTMLCleanerTest.java > 2009-01-02 06:04:20 UTC (rev 15010) > @@ -22,48 +22,135 @@ > import java.io.StringReader; > > import org.w3c.dom.Document; > +import org.w3c.dom.Element; > +import org.w3c.dom.Node; > +import org.w3c.dom.NodeList; > import org.xwiki.xml.html.HTMLCleaner; > > -import com.xpn.xwiki.test.AbstractXWikiComponentTestCase; > - > /** > * Test case for default open office html cleaner. > - * > + * > * @version $Id$ > * @since 1.8M1 > */ > -public class OpenOfficeDefaultHTMLCleanerTest extends > AbstractXWikiComponentTestCase > +public class OpenOfficeDefaultHTMLCleanerTest extends > AbstractHTMLCleanerTestCase > { > /** > - * Beginning of the test html document. > - */ > - private String header = "<html><head><title>Title</title></ > head><body>"; > - > - /** > - * Ending of the test html document.. > - */ > - private String footer = "</body></html>"; > - > - /** > * Open office html cleaner. > */ > private HTMLCleaner cleaner; > - > + > /** > * {@inheritDoc} > */ > protected void setUp() throws Exception > { > super.setUp(); > - cleaner = (HTMLCleaner) > getComponentManager().lookup(HTMLCleaner.ROLE, "openoffice-default"); > + cleaner = > + (HTMLCleaner) > getComponentManager().lookup(HTMLCleaner.ROLE, "openoffice-default"); > } > - > + > /** > * Test most basic cleaning. > */ > - public void testBasicCleaning() { > - String html = header + footer; > + public void testBasicCleaning() > + { > + super.testBasicCleaning(cleaner); > + } > + > + /** > + * Test stripping of {@code <style>} and {@code <script>} tags. > + */ > + public void testTagStripping() > + { > + super.testTagStripping(cleaner); > + } > + > + /** > + * Test stripping of redundant tags. > + */ > + public void testRedundancyFiltering() > + { > + super.testRedundancyFiltering(cleaner); > + } > + > + /** > + * Test filtering of html links. > + */ > + public void testLinkFiltering() > + { > + String html = header + "<a href=\"http://www.xwiki.org > \">xwiki</a>" + footer; > Document doc = cleaner.clean(new StringReader(html)); > - assertNotNull(doc.getDoctype()); > + NodeList nodes = doc.getElementsByTagName("a"); > + assertEquals(1, nodes.getLength()); > + Node link = nodes.item(0); > + Element span = (Element) link.getParentNode(); > + assertEquals("span", span.getNodeName()); > + assertEquals("wikiexternallink", span.getAttribute("class")); > + Node startComment = span.getPreviousSibling(); > + > assertTrue(startComment.getNodeValue().startsWith("startwikilink")); > + Node stopComment = span.getNextSibling(); > + > assertTrue(stopComment.getNodeValue().startsWith("stopwikilink")); > } > + > + /** > + * Test filtering of html lists. > + */ > + public void testListFiltering() > + { > + // Leading spaces inside list items are not allowed. > + String html = header + "<ol><li> Test</li></ol>" + footer; > + Document doc = cleaner.clean(new StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("li"); > + Node listContent = nodes.item(0).getFirstChild(); > + assertEquals(Node.TEXT_NODE, listContent.getNodeType()); > + assertEquals("Test", listContent.getNodeValue()); > + // Paragraphs inside list items are not allowed. > + html = header + "<ol><li><p>Test</p></li></ol>" + footer; > + doc = cleaner.clean(new StringReader(html)); > + listContent = nodes.item(0).getFirstChild(); > + assertEquals(Node.TEXT_NODE, listContent.getNodeType()); > + assertEquals("Test", listContent.getNodeValue()); > + // Leading space plus a starting paragraph. > + html = header + "<ol><li> <p>Test</p></li></ol>" + footer; > + doc = cleaner.clean(new StringReader(html)); > + listContent = nodes.item(0).getFirstChild(); > + assertEquals(Node.TEXT_NODE, listContent.getNodeType()); > + assertEquals("Test", listContent.getNodeValue()); > + } > + > + /** > + * Test filtering of html tables. > + */ > + public void testTableFiltering() > + { > + // Leading or trailing spaces inside cell items are not > allowed. > + String html = header + "<table><tr><td> Test </td></tr></ > table>" + footer; > + Document doc = cleaner.clean(new StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("td"); > + Node cellContent = nodes.item(0).getFirstChild(); > + assertEquals(Node.TEXT_NODE, cellContent.getNodeType()); > + assertEquals("Test", cellContent.getNodeValue()); > + // Paragraphs are not allowed inside cell items. > + html = header + "<table><tr><td> <p>Test</p> </td></tr></ > table>" + footer; > + doc = cleaner.clean(new StringReader(html)); > + nodes = doc.getElementsByTagName("td"); > + cellContent = nodes.item(0).getFirstChild(); > + assertEquals(Node.TEXT_NODE, cellContent.getNodeType()); > + assertEquals("Test", cellContent.getNodeValue()); > + // Line breaks are not allowed inside cell items. > + html = header + "<table><tr><td><br/><p><br/>Test</p> </ > td></tr></table>" + footer; > + doc = cleaner.clean(new StringReader(html)); > + nodes = doc.getElementsByTagName("td"); > + cellContent = nodes.item(0).getFirstChild(); > + assertEquals(Node.TEXT_NODE, cellContent.getNodeType()); > + assertEquals("Test", cellContent.getNodeValue()); > + // Empty cells should be replaced by a '-' (this is > temporary) > + html = header + "<table><tr><td><br/><p><br/></p> </td></ > tr></table>" + footer; > + doc = cleaner.clean(new StringReader(html)); > + nodes = doc.getElementsByTagName("td"); > + cellContent = nodes.item(0).getFirstChild(); > + assertEquals(Node.TEXT_NODE, cellContent.getNodeType()); > + assertEquals("-", cellContent.getNodeValue()); > + } > } > > Added: sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/WysiwygDefaultHTMLCleanerTest.java > =================================================================== > --- sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/ > WysiwygDefaultHTMLCleanerTest.java (rev 0) > +++ sandbox/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/html/cleaner/WysiwygDefaultHTMLCleanerTest.java > 2009-01-02 06:04:20 UTC (rev 15010) > @@ -0,0 +1,71 @@ > +/* > + * 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.officeimporter.html.cleaner; > + > +import org.xwiki.xml.html.HTMLCleaner; > + > +/** > + * Test case for default wysiwyg html cleaner. > + * > + * @version $Id$ > + * @since 1.8M1 > + */ > +public class WysiwygDefaultHTMLCleanerTest extends > AbstractHTMLCleanerTestCase > +{ > + > + /** > + * Wysiwyg html cleaner. > + */ > + private HTMLCleaner cleaner; > + > + /** > + * {@inheritDoc} > + */ > + protected void setUp() throws Exception > + { > + super.setUp(); > + cleaner = > + (HTMLCleaner) > getComponentManager().lookup(HTMLCleaner.ROLE, "wysiwyg-default"); > + } > + > + /** > + * Test most basic cleaning. > + */ > + public void testBasicCleaning() > + { > + super.testBasicCleaning(cleaner); > + } > + > + /** > + * Test stripping of {@code <style>} and {@code <script>} tags. > + */ > + public void testTagStripping() > + { > + super.testTagStripping(cleaner); > + } > + > + /** > + * Test stripping of redundant tags. > + */ > + public void testRedundancyFiltering() > + { > + super.testRedundancyFiltering(cleaner); > + } > +}

16 years, 8 months

2
2
0 0

[xwiki-devs] RESTful API alpha

by Fabio Mancinelli

Dear all, I've committed a first implementation of the RESTful API as described on http://dev.xwiki.org/xwiki/bin/view/Design/RestfulAPI Not all the URIs are working but pages and translations are. You can: * GET / * GET /spaces * GET /spaces/{spaceId}/pages * GET|PUT /spaces/{spaceId}/pages/{pageId} * GET|PUT /spaces/{spaceId}/pages/{pageId}/translations/{translationId} PUT will create/modify the corresponding page. You can use curl to interoperate with the API. Some examples: * curl -u Admin:admin -X PUT -d "Hello world" -H "Content-Type: text/plain" http://localhost:8080/xwiki/rest/spaces/Main/pages/WebHome Will set the content of Main.WebHome to "Hello world" * curl -u Admin:admin -X PUT -d @text.txt -H "Content-Type: text/plain" http://localhost:8080/xwiki/rest/spaces/Main/pages/WebHome Will set the Main.WebHome content to whatever is writen in the text.txt file. * curl -u Admin:admin -X PUT -d @page.xml -H "Content-Type: application/xml" http://localhost:8080/xwiki/rest/spaces/Main/pages/WebHome Will set the Main.WebHome attributes to whatever is written in the page.xml. The xml file must conform to the structure described in the design page. This allows to change the content, the title and to reparent the page. * curl -u Admin:admin -X PUT -d @text.txt -H "Content-Type: text/plain" http://localhost:8080/xwiki/rest/spaces/Not/pages/Existing Will create the Not.Existing page and set its content to whatever is writen in the text.txt file. Currently the implementation is in the sandbox and is available for public review (http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-core-rest/). It uses the XStream library (http://xstream.codehaus.org) for XML serialization/deserialization of data types. Very handy. Comments are welcome. -Fabio

16 years, 8 months

3
5
0 0

[xwiki-devs] [Idea] Add document XDOM structure content to XML page export

by Vincent Massol

Hi, I think it might be interesting to export a document's structure (the XDOM) to the XML we generate for pages (?xpage=xml), in addition to the unparsed content and the rendered content. This would make it easy for external tools to process page structures and extract required information. More importantly it's something easy to do now. WDYT? This is low priority but I thought it could be interesting. Technically this means writing a DOMListener (which creates a w3c Document from a XDOM). Thanks -Vincent

16 years, 8 months

4
4
0 0

[xwiki-devs] [PROPOSAL] Update DocumentAccessBridge

by Asiri Rathnayake

Hi Devs, I'm upgrading office-importer code base to new architecture. For this I suggest following methods to be added to the DocumentAccessBridge: 1. createNewDocument(String documentName, String content) //This method will throw an exception if the document already exists. 2. setDocumentContent(String documentName, String newContent) //For updating an existing document. 3. setDocumentSyntaxId(String documentName, String syntaxId) //For presentation documents the syntax would be 1.0 and for others it would be 2.0 4. addAttachmentToDocument(String documentName, String AttachmentName, byte [] attachmentData) //For making attachments 5. isDocumentEditable(String documentName) //This is following isDocumentViewable() mthod. But we could also have a hasRight() mthod instead. I'm +1 for all. But please let me know if any of above methods are redundant / not required / has wrong signature. Thanks. - Asiri

16 years, 8 months

3
3
0 0

[xwiki-devs] [VOTE] Support multilines headers

by Thomas Mortagne

Hi everyone Currently the XWiki 2.0 parser does not support multilines headers, meaning that it consider new line as end of header: = Heading 1 = give "<h1>Heading</h1><p>1 =</p>" I propose to have the same things than paragraphs: need two consecutive new lines (or the =* syntax of course) to be end of header. = Heading 1 = = Heading 2 = would give "<h1>Heading<br/>1</h1><h1>Heading</h1><p>2 =</p>" Here is my +1 Thanks, -- Thomas Mortagne

16 years, 8 months

5
6
0 0

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

by Vincent Massol

On Dec 29, 2008, at 10:49 AM, Ludovic Dubost wrote: > Marius Dumitru Florea wrote: >> ludovic (SVN) wrote: >> >>> Author: ludovic >>> Date: 2008-12-29 10:10:55 +0100 (Mon, 29 Dec 2008) >>> New Revision: 14946 >>> >>> Modified: >>> platform/web/trunk/standard/src/main/webapp/templates/ >>> editwysiwygnew.vm >>> Log: >>> XWIKI-3046 GWT Editor SyncPlugin: correct loading of initial >>> content supporting images. Added a reset sync action >>> >>> Modified: platform/web/trunk/standard/src/main/webapp/templates/ >>> editwysiwygnew.vm >>> =================================================================== >>> --- platform/web/trunk/standard/src/main/webapp/templates/ >>> editwysiwygnew.vm 2008-12-29 09:10:38 UTC (rev 14945) >>> +++ platform/web/trunk/standard/src/main/webapp/templates/ >>> editwysiwygnew.vm 2008-12-29 09:10:55 UTC (rev 14946) >>> @@ -47,11 +47,16 @@ >>> hookId: 'content', >>> #if($request.sync=="1") >>> syncPage: '$doc.fullName', >>> + plugins: 'separator text valign list indent undo format >>> symbol link image table sync', >>> >> >> >>> + inputURL: "${request.contextPath}/ >>> com.xpn.xwiki.wysiwyg.Wysiwyg/empty.html", >>> >> >> > Well I need a read empty content, and the issue is that when > parseTemplate returns empty this is not considered as ok and will > generate an error. So I have to use a real static HTML. What I need is > not the exact relative path but the server part name so that images > display properly. > > This is currently working. This is good enough for now and specific to > the sync method, since this is demo code. We can change it later. Well this definitely needs comments since it's a hack and not an obvious one. Thanks -Vincent > Ludovic > >> Why do you need this empty.html? Did you try setting the wysiwyg >> input >> to an empty string? >> >> #set($ok = $wysiwygInput.put($wysiwygInputKey, "")) ? >> >> Plus, all the links and images will be relative to >> ${request.contextPath}/com.xpn.xwiki.wysiwyg.Wysiwyg and this is >> not good. >> >> >>> + #if($request.reset=="1") >>> + syncReset: 1, >>> + #end >>> #else >>> inputURL: "${tdoc.getExternalURL("view", >>> "xpage=wysiwyginput&key=$wysiwygInputKey")}", >>> + plugins: 'separator text valign list indent undo format >>> symbol link image table', >>> #end >>> syntax: "$doc.syntaxId", >>> - plugins: 'separator text valign list indent undo format >>> symbol link image table', >>> toolbar: 'bold italic underline strikethrough | subscript >>> superscript | unorderedlist orderedlist | outdent indent | undo >>> redo | format | hr symbol | link unlink | image | inserttable >>> deletetable | insertrowbefore insertrowafter deleterow | >>> insertcolbefore insertcolafter deletecol', >>> space: '${doc.space}', >>> page: '${doc.name}',

16 years, 8 months

2
1
0 0

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

by Vincent Massol

On Dec 29, 2008, at 10:17 AM, Anca Paula Luca wrote: > ludovic (SVN) wrote: >> Author: ludovic >> Date: 2008-12-29 10:10:55 +0100 (Mon, 29 Dec 2008) >> New Revision: 14946 >> >> Modified: >> platform/web/trunk/standard/src/main/webapp/templates/ >> editwysiwygnew.vm >> Log: >> XWIKI-3046 GWT Editor SyncPlugin: correct loading of initial >> content supporting images. Added a reset sync action >> >> Modified: platform/web/trunk/standard/src/main/webapp/templates/ >> editwysiwygnew.vm >> =================================================================== >> --- platform/web/trunk/standard/src/main/webapp/templates/ >> editwysiwygnew.vm 2008-12-29 09:10:38 UTC (rev 14945) >> +++ platform/web/trunk/standard/src/main/webapp/templates/ >> editwysiwygnew.vm 2008-12-29 09:10:55 UTC (rev 14946) >> @@ -47,11 +47,16 @@ >> hookId: 'content', >> #if($request.sync=="1") >> syncPage: '$doc.fullName', >> + plugins: 'separator text valign list indent undo format >> symbol link image table sync', > > Ludovic, > is the sync plugin ready to be activated by default? I hope it's not activated by default on the 1.7 branch! (haven't checked) Thanks -Vincent > Happy coding, > Anca Luca > >> + inputURL: "${request.contextPath}/ >> com.xpn.xwiki.wysiwyg.Wysiwyg/empty.html", >> + #if($request.reset=="1") >> + syncReset: 1, >> + #end >> #else >> inputURL: "${tdoc.getExternalURL("view", >> "xpage=wysiwyginput&key=$wysiwygInputKey")}", >> + plugins: 'separator text valign list indent undo format >> symbol link image table', >> #end >> syntax: "$doc.syntaxId", >> - plugins: 'separator text valign list indent undo format >> symbol link image table', >> toolbar: 'bold italic underline strikethrough | subscript >> superscript | unorderedlist orderedlist | outdent indent | undo >> redo | format | hr symbol | link unlink | image | inserttable >> deletetable | insertrowbefore insertrowafter deleterow | >> insertcolbefore insertcolafter deletecol', >> space: '${doc.space}', >> page: '${doc.name}', >>

16 years, 8 months

2
1
0 0

[xwiki-devs] General Development Flow + Release Cycles

by Vincent Massol

Hi everyone, We have discussed this in the past but I wanted to formalize it so I've taken the time to write 2 new sections in our development practices: * General Development Flow: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneral… * Frequent Releases: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HFrequen… All devs should be sure to read them and agree with them. If you don't agree that's fine, we can discuss it and revise what's written. The end goal is to make us work all together nicely and smoothly. Thanks and a merry christmas to all -Vincent

16 years, 9 months

1
0
0 0

[xwiki-devs] [RFC] RESTful API + Mediatypes

by Fabio Mancinelli

Dear all, I am starting a new thread because the old one started to be overloaded. I have started to write some media types that could be used as the representations returned by our RESTful API. It's a first attempt but they already contain some ideas and the guiding design principle I would like to follow. You can find them on http://dev.xwiki.org/xwiki/bin/view/Design/RestfulAPI Comments are welcome. -Fabio

16 years, 9 months

1
0
0 0

[xwiki-devs] [Proposal] Closing old rendering/wysiwyg issues as won't fix

by Vincent Massol

Hi, We need to decide something: do we want to close old rendering/wysiwyg issues as won't fix explaining that they are fixed in the new rendering/new wysiwyg? My take is the following: * I don't think any xwiki committers will want to spend time fixing old rendering/old wysiwyg issues since all our energy is spent on the new versions * We're going to have a XWiki Syntax 1.0 --> 2.0 converter soon (before 16th of January) * The new wysiwyg editor should also be usable before the 16th of January * If a contributor wants to fix some old rendering/old wysiwyg issue he can create a new issues or reopen a closed one. As a consequence I think we can close them as won't fix and explain that the user should move to the new Syntax. WDYT? Thanks -Vincent

16 years, 9 months

7
6
0 0

[xwiki-devs] [RFC] RESTful API

by Fabio Mancinelli

Dear all, I worked a bit on the design of the RESTful API and as a result I've integrated what was written on the http://dev.xwiki.org/xwiki/bin/view/Design/RestfulAPI page. There is still a big and important part missing (maybe the most important one), i.e., the one about the data formats for representations (in particular the XML schemas to be used in requests and responses). I am working on it. Anyway you can already comment on what is present on the page. Thank you. -Fabio

16 years, 9 months

8
66
0 0

Re: [xwiki-devs] [xwiki-notifications] r14895 - in platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc: . model

by Sergiu Dumitriu

fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2008-12-20 22:13:33 +0100 (Sat, 20 Dec 2008) > New Revision: 14895 > > Added: > platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/XWikiXmlRpcApi.java > Modified: > platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/model/Utils.java > platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/model/XWikiClass.java > platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/model/XWikiClassSummary.java > platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/model/XWikiExtendedId.java > platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/model/XWikiObject.java > platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/model/XWikiObjectSummary.java > platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/model/XWikiPage.java > platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/model/XWikiPageHistorySummary.java > platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/model/XWikiPageSummary.java > Log: > XWIKI-3028: XMLRPC Subsystem refactoring/improvement > XWIKI-3029: XMLRPC getObject() does not return any information about DBList, DBTreeList, etc. values. > > (XWIKI-3028) Definition of the XmlRpcApi. > > (XWIKI-3029) The XWikiObject class has been extended with a mechanism for retrieving metadata associated to properties. This is necessary for attaching to a property which is a DBList, for example, the list of the allowed values. Meta-properties are stored as normal object properties but they have a special suffix. The getProperties method does not return these meta-properties. In order to access to meta-properties additional methods are provided. > > Added: platform/core/trunk/xwiki-xmlrpc/xwiki-xmlrpc-model/src/main/java/org/xwiki/xmlrpc/XWikiXmlRpcApi.java > =================================================================== > +public interface XWikiXmlRpcApi > +{ > + /* Authentication */ > + public String login(String username, String password) throws Exception; > + > + public Boolean logout(String token) throws Exception; > + > + /* General */ > + public Map/* ServerInfo */getServerInfo(String token) throws Exception; > + > + /* Spaces */ > + public List/* List<SpaceSummary> */getSpaces(String token) throws Exception; > + > + public Map/* Space */getSpace(String token, String spaceKey) throws Exception; > + > + public Map/* Space */addSpace(String token, Map spaceMap) throws Exception; > + > + public Boolean removeSpace(String token, String spaceKey) throws Exception; > + > + /* Pages */ > + public List/* List<PageSummary> */getPages(String token, String spaceKey) throws Exception; > + > + public Map/* XWikiPage */getPage(String token, String pageId) throws Exception; > + > + public Map/* XWikiPage */storePage(String token, Map pageMap) throws Exception; > + > + public Map/* XWikiPage */storePage(String token, Map pageMap, boolean checkVersion) throws Exception; > + > + public Boolean removePage(String token, String pageId) throws Exception; > + > + public List/* List<XWikiPageHistorySummary> */getPageHistory(String token, String pageId) throws Exception; > + > + public String renderContent(String token, String space, String pageId, String content) throws Exception; Why is there a "String space" parameter? > + /* Comments */ > + public List/* List<Comment> */getComments(String token, String pageId) throws Exception; > + > + public Map/* Comment */getComment(String token, String commentId) throws Exception; > + > + public Map/* Comment */addComment(String token, Map commentMap) throws Exception; > + > + public Boolean removeComment(String token, String commentId) throws Exception; > + > + /* Attachments */ > + public List/* List<Attachment> */getAttachments(String token, String pageId) throws Exception; > + > + public Map/* Attachmnent */addAttachment(String token, Integer contentId, Map attachmentMap, byte[] attachmentData) > + throws Exception; What is the contentId? > + public byte[] getAttachmentData(String token, String pageId, String fileName, String versionNumber) > + throws Exception; How do I find out the possible version numbers? > + public Boolean removeAttachment(String token, String pageId, String fileName) throws Exception; > + > + /* Classes */ > + public List/* List<XWikiClassSummary> */getClasses(String token) throws Exception; > + > + public Map/* XWikiClass */getClass(String token, String className) throws Exception; > + > + /* Objects */ > + public List/* List<XWikiObjectSummary> */getObjects(String token, String pageId) throws Exception; > + > + public Map/* XWikiObject */getObject(String token, String pageId, String className, Integer id) throws Exception; > + > + public Map/* XWikiObject */storeObject(String token, Map objectMap) throws Exception; > + > + public Map/* XWikiObject */storeObject(String token, Map objectMap, boolean checkVersion) throws Exception; Where is the original version stored? In XWiki, objects don't have versions. > + public Boolean removeObject(String token, String pageId, String className, Integer id) throws Exception; > + > + /* Search */ > + public List/* List<SerarchResult> */search(String token, String query, int maxResults) throws Exception; > + > + public List/* List<XWikiPageHistorySummary> */getModifiedPagesHistory(String token, Date date, int numberOfResults, > + int start, boolean fromLatest) throws Exception; > + > +} > -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 9 months

1
0
0 0

[xwiki-devs] Office Importer Wysiwyg Integration

by Asiri Rathnayake

Devs, I'm working on integrating office importer functionality into our new wysiwyg editor and I thought of sharing few ideas and different approaches available to us so that you can comment on them and help me select the most appropriate path. First of all, a crude version of the integration is available at http://91.121.237.216/xwiki/bin/view/Main/. You can login with asiri/asiri and try editing the Main.WebHome page. You will notice the import button placed right next to first 4 text formatting buttons. Now the full version of the importer dialog will include two tabs. First visible tag will allow a user to paste office content right into a local rich-text-area and import them in place of the current selection in the wysiwyg editor. The second tab allows the user to upload an office document which will also be imported in place of the current selection. My idea is to include the first tab's functionality into 1.8M1 release. The general approach towards implementation is to introduce a new wysiwyg plugin called "importer". The crude version mentioned above make use of the default WysiwygService::cleanHTML() gwt rpc call for cleaning the pasted html content. But for the actual implementation we have to introduce a new importer specific gwt rpc call because the default cleanHTML() is not going to be enough when cleaning html content comming from various office suits. So here I propose we introduce WysiwygService::cleanOfficeHTML() gwt rpc call. The next question is about the implementation of the cleanOfficeHTML() method. Here the complication arises from the fact that the incomming html can be from various sources; it can be MSWord, MSExcel, OpenOffice Writer and any editor capable of exporting html content into user's clipboard (so that user can paste them). I see several approaches to solve this issue: 1. Perform an exhaustive cleaning leaving out only basic html elements that we can handle. Here we'll have to consider various formatting elements used by different office suits and convert them as necessary. For an example, http://office.microsoft.com/en-us/help/HA010549981033.aspx contains information about various MSOffice 2000 specific markup. 2. By analysing the incomming html content, first we determine the office suite which generated the content (with a default case for unknowns). And there after perform a specific cleaning procedure for that office suite. Note that there is no generic way of determining the office suite and there can be many such suites. 3. We pass the incomming html through jodconverter (openoffice server) and get the resulting html. Since this html is from openoffice, there is no need to worry about different office suites and we can perform our cleaning afterwards. The downsides of this approach are: * Passing though openoffice server can be time consuming. * Jodconverter seems to have some limitations with html formats as mentioned at http://www.artofsolving.com/opensource/jodconverter/guide/supportedformats Of the three approaches mentioned above, I'm preferring the first approach since it's the most simple one. Also, the other two approaches doesn't seem to provide any advantages w.r.t first approach. And the final question is about embedded elements inside pasted html content (like images). This is not a problem if the whole document is uploaded for importing; the document is a container for images and they can be retrieved on the server. But with pasted html content, images are simply links to local files. Now I don't know if it's possible to trigger an automated upload of these files but for the moment I'm proposing we should strip-off such content. Thanks. - Asiri

16 years, 9 months

4
4
0 0

Re: [xwiki-devs] [xwiki-notifications] r14879 - in platform/core/trunk/xwiki-rendering/src/test: java/org/xwiki/rendering resources/list

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-12-19 15:33:02 +0100 (Fri, 19 Dec 2008) > New Revision: 14879 > > Added: > platform/core/trunk/xwiki-rendering/src/test/resources/list/list10.test > Modified: > platform/core/trunk/xwiki-rendering/src/test/java/org/xwiki/rendering/RenderingTests.java > Log: > XWIKI-3006: All spaces at the begining of a list item content are consummed by the parser. > * add unit test > + suite.addTestsFromResource("list/list10", false); Why is there a need to manually add test cases? Why don't we just use all the test cases available? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 9 months

2
1
0 0

[xwiki-devs] [VOTE] Makes list content first spaces meaningful in XWiki 2.0 syntax (was Re: [Rendering 2.0][Vote] About whitespace management in list item context)

by Thomas Mortagne

Hi devs, We already decided that in a general way, spaces entered by user are meaningful: when you enter "Some<space><space><space>content" you will get in XHTML "<p>Some   content</p>" This not fully the case with list for example where: "**<space><space><space>list<space><space><space>content" will give "<li>list   content</li>" I propose, for consistency, to make first spaces of list content meaningful like in any other content: "**<space><space><space>list<space><space><space>content" will give "<li>   list   content</li>" Here is my +1 On Wed, Dec 17, 2008 at 3:50 PM, Vincent Massol <vincent(a)massol.net> wrote: > > On Dec 17, 2008, at 3:39 PM, Thomas Mortagne wrote: > >> On Wed, Dec 17, 2008 at 3:38 PM, Thomas Mortagne >> <thomas.mortagne(a)xwiki.com> wrote: >>> On Wed, Dec 17, 2008 at 3:12 PM, Vincent Massol >>> <vincent(a)massol.net> wrote: >>>> >>>> On Dec 17, 2008, at 3:07 PM, Thomas Mortagne wrote: >>>> >>>>> On Wed, Dec 17, 2008 at 3:02 PM, Vincent Massol >>>>> <vincent(a)massol.net> >>>>> wrote: >>>>>> >>>>>> On Dec 17, 2008, at 2:38 PM, Thomas Mortagne wrote: >>>>>> >>>>>>> On Wed, Dec 17, 2008 at 1:15 PM, Vincent Massol <vincent(a)massol.net >>>>>>> > >>>>>>> wrote: >>>>>>>> >>>>>>>> On Dec 17, 2008, at 12:57 PM, Lucien PEREIRA wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Working on annotation feature, I need to retrieve >>>>>>>>> xwiki document source code from a selection on XHTML. >>>>>>>>> >>>>>>>>> This requires to have a correspondence between content >>>>>>>>> typed by user and content that appears in html. >>>>>>>>> >>>>>>>>> I noticed in xwiki 2.0 synthax that white spaces typed >>>>>>>>> in a list item context are ignored : >>>>>>>>> >>>>>>>>> *< >>>>>>>>> space >>>>>>>>>> >>>>>>>>> < >>>>>>>>> space >>>>>>>>>> < >>>>>>>>>> space >>>>>>>>>>> < >>>>>>>>>>> space><space>foo<space><space><space>bar<space><space><space> >>>>>>>>> >>>>>>>>> renders in XHTML >>>>>>>>> >>>>>>>>> <li>foo<space>  bar   </li> >>>>>>>>> >>>>>>>>> so I could not determine the real offset of selection in xwiki >>>>>>>>> document source. >>>>>>>> >>>>>>>> There's another problem: leading spaces before list items and >>>>>>>> headers. >>>>>>>> We need to allow them (for several reasons, one of them is for >>>>>>>> supporting indenting velocity code when we have velocity mixed >>>>>>>> with >>>>>>>> wiki syntax). So in term of rendering they should be considered >>>>>>>> as a >>>>>>>> ListItemBlock and the spaces should not be rendered. >>>>>>>> >>>>>>>> One problem is when we go through the wysiwyg these spaces >>>>>>>> will be >>>>>>>> removed. Removing them for content not in macros is not such a >>>>>>>> big >>>>>>>> deal IMO (except for Lucien's use case but there are other >>>>>>>> ways of >>>>>>>> doing it for him). Removing them would be a problem when inside >>>>>>>> macros. Fortunately we don't touch at macro content for the >>>>>>>> moment. >>>>>>>> >>>>>>>>> This can be solved by not ignoring spaces so render become : >>>>>>>>> >>>>>>>>> < >>>>>>>>> li >>>>>>>>>> >>>>>>>>> &nbsp >>>>>>>>> ;&nbsp >>>>>>>>> ;&nbsp >>>>>>>>> ;  foo<space>  bar   </ >>>>>>>>> li> >>>>>>>>> >>>>>>>>> This policy of rendering already exists in underline or italic >>>>>>>>> context so it's strange to have a different behaviour in list >>>>>>>>> item context. >>>>>>>>> >>>>>>>>> Moreover I think we should not suppose what content is >>>>>>>>> relevant for user or not, so source shouldn't be altered. >>>>>>>> >>>>>>>> We have to alter source in the case of badly formed content, >>>>>>>> as in >>>>>>>> "**bold". We also later for unisignificant escapes (as with >>>>>>>> "~hello"' >>>>>>>> is transformed into "hello") + some other use cases probably. >>>>>>>> >>>>>>>> Right now I don't have any idea of what to do differently. Only >>>>>>>> idea I >>>>>>>> could think of would be to have a parameter for list items and >>>>>>>> headers, passing to them the number of leading spaces, tabs, etc >>>>>>>> but I >>>>>>>> don't like this too much. >>>>>>>> >>>>>>>> I think the idea of leaving the content intact is not correct >>>>>>>> and >>>>>>>> we >>>>>>>> shouldn't expect that behavior for a wiki syntax. A wiki syntax >>>>>>>> needs >>>>>>>> to be as simple as possible for users to use. Allowing leading >>>>>>>> spaces >>>>>>>> go in that direction. OTOH I agree with Lucien that we've >>>>>>>> decided >>>>>>>> to >>>>>>>> make spaces in paragraph significant so it's not fully >>>>>>>> consistent. >>>>>>>> >>>>>>>> What do others think? >>>>>>> >>>>>>> I agree that it's not alway possible to respect the original >>>>>>> source >>>>>>> especially with useless escapes (~toto which become toto). >>>>>>> >>>>>>> Now in the case of list item content I think we should support it >>>>>>> because it's exactly the same context that space in a paragraph >>>>>>> and >>>>>>> such so it have to behave the same way for consistency. >>>>>>> >>>>>>> So +1 to support spaces at beginning of list item. >>>>>> >>>>>> Could you explain what you mean by "support spaces at begining of >>>>>> list >>>>>> item"? >>>>> >>>>> Yes it's not very clear: +1 for not removing first spaces of list >>>>> item >>>>> content. In other words +1 for changing the current behavior. >>>> >>>> This is still not clear. >>>> >>>> If we don't remove leading spaces is it still a list item? >>>> >>>> And if it's still a list item how do we implement this since lists >>>> are >>>> block elements? >>>> >>>> And what about spaces after the first space after the list item >>>> delimiters? >>>> >>> >>> +1 for : >>> >>> <#LI: (<SPACE>)* ( ("*")+ (":" | ";")* | ( "1" | "*" )+ "." (":" | >>> ";")* | (":" | ";")+ ) (<SPACE>)* > >> >> I mean >> <#LI: (<SPACE>)* ( ("*")+ (":" | ";")* | ( "1" | "*" )+ "." (":" | >> ";")* | (":" | ";")+ ) (<SPACE>) > > > ok, I'd agree with this one. It makes sense to me too. > > Note for others: it still means that entering: > > (space)(space)*(space)item > > is transformed into: > > *(space)item > > for example when going from wysiwyg editor to wiki syntax. > > Thanks > -Vincent > >>> in place of >>> >>> <#LI: (<SPACE>)* ( ("*")+ (":" | ";")* | ( "1" | "*" )+ "." (":" | >>> ";")* | (":" | ";")+ ) (<SPACE>)+ > >>> >>>> Thanks >>>> -Vincent > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

16 years, 9 months

5
5
0 0

[xwiki-devs] [Proposal] Roadmap for XE 1.8

by Vincent Massol

Time for the new roadmap definition. Here's a proposal. Note that I've discussed the points below with all people I've put as leads. Of course if anyone from the community/committers want to implement additional stuff you're most welcome :) * Finish new rendering: Continue Macro rewrite: rss, graph and more. - Lead: Dan Miron * Finish new rendering: Add embedded doc support + converter from 1.0 syntax to 2.0 + various leftovers - Lead: Thomas Mortagne * Office Importer (all types: word, excel, powerpoint, etc). Available from the WYSIWYG editor too. - Lead: Asiri * Working JCR/Query Manager - Lead: Artem * Finish WYSIWYG editor (UI + bug fixes + missing features). - Lead: Marius/Anca * MS Office Plugin - Lead: Florin. * Start design work on new Application Manager (ability to package in a XAR: pages, external libraries, skin extensions, resources, macros, components, etc + ability to list/install/remove/upgrade applications + ability to install from a remote repo) - Lead: Thomas Mortagne/Jean- Vincent * Work on usability/navigation/UI improvements (like redesign special pages: WebHome, AllDocs, Tags, etc, improve navigation with a treeview panel, autosuggest in search box, etc). We need to define 3-4 items we want in priority. Lead: Jean-Vincent with Laurent/Guillaume * Invitation: backporting the invitation work done in XWS to XE. Lead: Jerome * French XE (was supposed to be done for 1.7) - Lead: Jean-Vincent with Thomas Eveilleau's help * MediaWiki import - Lead: Vincent with Asiri * Drag and drop spaces/pages in the AllDocs treeview to reorganize pages and spaces - Lead: Marius/Anca * Revamp the xwiki.org web site to focus on XE only (for ex main page should only list XE with aggregated feature list) so that we show that we have only one product but various add-ons. Lead: Vincent (note: I need to make a proposal for this) * Skin extensions/Interface extension finalization + Template/Skin cleanup. Lead: Sergiu + Jerome * Internal refactoring to redesign interfaces and transform them into components (Model, Actions, URLs, Velocity Bridge, etc). Lead: Vincent Let me know what you think and if ok I'll put it up on http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap If we can do all this XE 1.8 will be a great release, possibly our greatest :) Thanks -Vincent

16 years, 9 months

1
3
0 0

[xwiki-devs] [RFC] Interface Components, or Where to put core skin extensions?

by Sergiu Dumitriu

Hi devs, While working on a UI feature that makes use of skin extensions (both script and style), I was faced with a difficult choice: where to put these extensions? The difficulty comes from several factors: - This is a small feature that doesn't deserve its own application - Yet, it does not fit in any of the existing applications - I don't want to put the js and css in Albatross, as it was done until now - Resource-based extensions are not as flexible as document-based ones, and I'd still need a .jar module to stick them to. Since this is just the first in a long series of such small extensions, leading to a simpler and more modular skin mechanism, I think we should take a decision. A while back, when designing Interface eXtensions, I also proposed Interface Components, which is exactly what I would like to do (as the packaging, since the code is already structured like a component). See http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions#HAfterwards So, the choices are: 1. Stick to the past and put the code in Albatross, registering it in platform-web/javascript.vm and stylesheet.vm. 2. Put the files as resource skin extensions inside xwiki-core. 3. Force the documents into an existing application, for example administration or enterprise-wiki. 4. Create a new application for holding Interface Components. 5. Create a new application for each IC. Currently, my preference is +1 for 5, with a +0 for 4 and -1 for the rest. Here's some of my motivations: 1. is dead wrong. This is what we've been doing until now, and we managed to overwhelm the skin with resources, putting a hard requirement on Albatross, registering no less than 14 global javascript files, most of the times unneeded, but hard to remove since nobody knows where and how they are used. If a bug is found, we need to redeploy the whole skin and wait for the next XE release, although it only affects one small part of the wiki. This also ties the platform to the skin. And it is completely not modular. 2. is dead wrong too. What does the core have to do with CSS??! 3. is slightly better. Since the SX are documents, they should be in an application. enterprise-wiki used to be the catch-all place to put documents, but we all decided that it must be split into modular applications. Plus, this is not XE specific, but it can be used in any product. administration is not suited either, since this has nothing to do with the wiki administration. The other existing apps are even less suited. 4. is a good alternative. The problem with only one application is that it is not modular enough. We must release the whole bunch when only one component was changed, which leads to numerous releases, or delayed releases until enough bugs have been found and fixed, which prevents users from benefiting of already solved bugs. The advantage is that we don't have to create numerous tiny projects in Jira. 5. is the best alternative when thinking of the future. With a good Interface Components manager, and a good Application Manager, installing and upgrading applications will be very easy. This solves the problems of 4, since each app can be released as soon as its bugs are solved, and auto-updated on all clients in no time. The problem is that we would need a lot of tiny Jira projects, each with its own release cycle. This is not a code problem, but a infrastructure one. In the future we should drop Jira (which IMO is much too company-oriented than umbrella-oriented), and replace it with our own infrastructure: interface.xwiki.org, as a repository of interface components, where each component has its own space, including our future agile project management tool. WDYT? Anything against option 5? If no, we'll need to decide some more details, as to where to put ICs in the svn repo, where to list them in the wiki, how to name them, etc. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 9 months

7
9
0 0

[xwiki-devs] Create users/groups programmatically

by Juergen Lorenz Simon

Hi, I'm trying to create wiki users and groups programmatically. The problem arises in integration of XWiki with a portal solution. The users log in with the portal, the portal sets a cookie and the xwiki plugin for authentication picks it up. It checks if the user exists, if not creates it. So far so good. I can create a user with code mimicking the user creation code in XWiki.class. But I still have a problem grasping permissions. I'd like to add the user to a special group of portal users, which should be checked and created on the fly if need be. That group should have all the permissions needed. However I don't see a way of doing it. The xwiki.org documentation on the data model did not seem to cover this ground well. Can you give me some pointers? Thanks, J.L.Simon

16 years, 9 months

1
0
0 0

[xwiki-devs] Create a document using database

by David Matos

Hi, I need to create several documents, each one with two tags. After some research I discovered that a document and their respective tags are registered in the following tables: - XWIKIOBJECTS; - XWIKILISTITEMS; - XWIKIPROPERTIES; - XWIKILIST; - XWIKIDOC; - XWIKIRCS; After creating a record in each of these tables the tags are successfully created but the documents appear on the xwiki with errors and when I click them I need to create the doument again, duplicating the record in the database. Am I missing any table do create the document?

16 years, 9 months

1
0
0 0

[xwiki-devs] Use a function from another page

by David Matos

Hi, Can I use a function from another page? For example, I have a page where I store some functions and this functions would be called from another pages. Thanks in advance

16 years, 9 months

2
1
0 0

[xwiki-devs] [Rendering 2.0][Vote] About whitespace management in list item context

by Lucien PEREIRA

Hi, Working on annotation feature, I need to retrieve xwiki document source code from a selection on XHTML. This requires to have a correspondence between content typed by user and content that appears in html. I noticed in xwiki 2.0 synthax that white spaces typed in a list item context are ignored : *<space><space><space><space><space>foo<space><space><space>bar<space><space><space> renders in XHTML <li>foo<space>  bar   </li> so I could not determine the real offset of selection in xwiki document source. This can be solved by not ignoring spaces so render become : <li>     foo<space>  bar   </li> This policy of rendering already exists in underline or italic context so it's strange to have a different behaviour in list item context. Moreover I think we should not suppose what content is relevant for user or not, so source shouldn't be altered. WDYT ? Lucien

16 years, 9 months

3
8
0 0

[xwiki-devs] XE 1.7.1 - Postponing a bit

by Vincent Massol

Hi everyone, After discussing with Marius and Anca we'd like to postpone the 1.7.1 release a bit. As a reminder the goal of 1.7.1 is to make the new GWT editor solid enough to be used day to day instead of the current tinymce editor. Thus it needs not to have any major bugs. Since we've discovered a few important bugs recently we need a few more days. The new plan is to release XE 1.7.1 for Friday afternoon, hoping that we don't discover too many new ones. If we do we'll have to postpone by a few more days once more. Note to everyone: we need the max number of people to test the latest snapshot versions of the WYSIWYG editor - here: http://maven.xwiki.org/snapshots/com/xpn/xwiki/products/xwiki-enterprise-je… Thanks everyone -Vincent

16 years, 9 months

1
0
0 0

[xwiki-devs] Problem with WYSIWYG editor

by David Matos

Hi! Some pages of my wiki have some code edited with the wiki editor. This code works fine but if someone tries to use de WYSIWYG editor it changes the code and it stops working. I need WYSIWYG editor to work without changing the pages's code, what can I do? thanks in advance

16 years, 9 months

2
2
0 0

[xwiki-devs] [VOTE] How to handle a bold starting with a space at the beginning of the line

by Thomas Mortagne

Hi devs, We have an issue in the XWiki renderer when the XDOM contains a bold starting with a space at the beginning of a line. For example when we get an html containing <p><strong> some bold text</strong></p> in the office importer. In that case currently we lost the bold when rendering because one or more stars followed by a space is a list in XWiki syntax. I see two solutions: 1) Escape the first space in a verbatim block : **{{{<space>}}}some bold text** 2) Move the first spaces before the bold block: <space>**some bold text** 3) Remove all the first spaces of the bold block: **some bold text** I would prefer 1) because it's the only one which is really the same thing than the input but I think 2) is better for most users because it's less disturbing for something which is not really that important. I listed 3) because it's easier to implement than 2). WDYT ? Here is my +1 for 2) and +0 for 1) and 3) -- Thomas Mortagne

16 years, 9 months

5
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs