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

[xwiki-devs] [VOTE] Change default table syntax

by Thomas Mortagne

Hi devs, Currently in xwiki syntax 2.0 we are using || title cell 1 || title cell2 | cell 1 | cell 2 for table syntax. The problem is that with this grammar it's impossible to have empty cells because you can't use || as it mean title cell. Creole is using (see http://www.wikicreole.org/wiki/Creole1.0#section-Creole1.0-Tables): |= title cell 1 |= title cell2 | | cell 1 | cell 2 | I propose to change our current || by |= meaning the difference with the Creole syntax will be just that we don't need the ending |: |= title cell 1 |= title cell2 | cell 1 | cell 2 - we generally agreed to use Creole as much as possible - this syntax support space - this cell header syntax is more consistent with our header syntax (which is the Creole one ok ;)) - I think it's more readable than the current one because it's easier to differentiate header cell and cell especially when there is lot's of them So here is my +1 -- Thomas Mortagne

16 years, 10 months

8
10
0 0

[xwiki-devs] Location, release cycle and distribution of non core macros 2.0

by Jerome Velociter

Hello devs, This week we created a new "xwiki-macros" module under platform/core/ for macros of the XWiki Syntax 2.0. Another question now is what do we do for macros that are not "core macros" (i.e. not indispensable for what we consider being the basic working wiki, unlike the TOC macro, or the velocity macro). Development of such macros already started, for example the instant messenger status macro, and the map macro. Possibilities I see : 1. having them at the same level we have applications/ plugins/ under platform : adding a macros/ directory. 2. having them in the xwiki-macros core submodule, despite the fact they are not core I am for solution 1 right now, but maybe there are better alternatives to this, too. We also have to decide how we do release and distribute them, for example do we pack them with XE, or do we release them separately, and let users install them themselves as it is the case for most of the applications already. (For me the answer to this latest question seems obvious : we _should_ send them together with XE) Let me know what you think, I'd like if still possible having the map macro in 1.7 RC1. Jerome.

16 years, 10 months

4
11
0 0

[xwiki-devs] Office-Importer Test Server.

by Asiri Rathnayake

Hi All, I have setup a test server for testing the new xwiki-office-importer feature @ http://91.121.237.216/xwiki/bin/view/Main/ Please note that this is the same server used for testing xwiki-webdav interface. Known issues for office-importer : * Table support is limited due to : http://jira.xwiki.org/jira/browse/XWIKI-2804 & http://jira.xwiki.org/jira/browse/XWIKI-2834 * List support is limited due to : http://jira.xwiki.org/jira/browse/XWIKI-2812 * Image links (links with images as labels) are not supported yet : http://jira.xwiki.org/jira/browse/XWIKI-2832 Please help us improve office importer by testing it out and reporting as many bugs as you can ;) Thanks. - Asiri

16 years, 10 months

4
24
0 0

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

by Vincent Massol

Hi Asiri, On Nov 24, 2008, at 6:08 PM, asiri (SVN) wrote: > Author: asiri > Date: 2008-11-24 18:08:51 +0100 (Mon, 24 Nov 2008) > New Revision: 14425 > > Modified: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/RedundantTagFilter.java > Log: > XAOFFICE-1 : Develop the initial feature set for office-importer > plugin. > > * Added support for filtering empty / redundant paragraphs. > > Modified: sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/ > xwiki/plugin/officeimporter/filter/RedundantTagFilter.java > =================================================================== > --- sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/RedundantTagFilter.java 2008-11-24 > 15:17:17 UTC (rev 14424) > +++ sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/RedundantTagFilter.java 2008-11-24 > 17:08:51 UTC (rev 14425) > @@ -31,12 +31,13 @@ > > public void filter(Document document, ImporterContext context) > { > - for(String key : attributeWiseFilteredTags) { > + for (String key : attributeWiseFilteredTags) { > > filterNodesWithZeroAttributes(document.getElementsByTagName(key)); > } > - for(String key : contentWiseFilteredTags) { > + for (String key : contentWiseFilteredTags) { > > filterNodesWithEmptyTextContent(document.getElementsByTagName(key)); > - } > + } > + filterEmptyParagraphs(document); > } > > /** > @@ -70,10 +71,35 @@ > { > for (int i = 0; i < elements.getLength(); i++) { > Element element = (Element) elements.item(i); > - if (element.getTextContent().trim().equals("")) { > + if (element.getTextContent().trim().equals("")) { > element.getParentNode().removeChild(element); > i--; > } > } > } > + > + /** > + * OpenOffice server generates redundant paragraphs (with empty > content) to achieve spacing. > + * These paragraphs should be stripped off / replaced with > {@code <br/>} elements appropriately > + * because otherwise they result in spurious {@code (%%)} > elements in generated xwiki content. > + * > + * @param document The html document. > + */ > + private void filterEmptyParagraphs(Document document) > + { > + NodeList paragraphs = document.getElementsByTagName("p"); > + for (int i = 0; i < paragraphs.getLength(); i++) { > + Element paragraph = (Element) paragraphs.item(i); > + if (paragraph.getTextContent().trim().equals("")) { > + // We suspect this is an empty paragraph but it is > possible that it contains other > + // non-textual tags like images. For the moment > we'll only search for internal image > + // tags, we might have to refine this criterion > later. > + NodeList internalImages = > paragraph.getElementsByTagName("img"); > + if (internalImages.getLength() == 0) { > + paragraph.getParentNode().removeChild(paragraph); > + i--; I don't understand this algorithm. There can be a lot of other valid XHTML elements inside a P element (see the XHTML spec). Why are you searching for IMG tags at all? What about all the other tags? Again I'm not sure this code is in the right place. For example what will happen if the user provides an empty P as input for a wiki page (using XHTML syntax)? Your code will never run in this case. To be honest I haven't looked at the office importer code for some time but we really need to be careful to move all generic code outside of it and into the HTML cleaner or into the XHTML parser. Could you please check that there are only office-related code in there? Thanks -Vincent

16 years, 10 months

2
3
0 0

[xwiki-devs] problem installing xwiki

by antoine seilles

Hi i'm trying to install xwiki on ubuntu 8.10 with Tomcat5.5, JVM 1.6 and mysql 5.0 I have followed instructions of http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation I ve tried to google this error but i didn't find a solution. When trying to access my xwiki app, i have the following message : javax.servlet.ServletException: L'exécution de la servlet a lancé une exception com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:94) com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287) com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) *cause mère* java.lang.NoClassDefFoundError: org/jgroups/blocks/RpcDispatcher$Marshaller java.lang.ClassLoader.defineClass1(Native Method) java.lang.ClassLoader.defineClass(ClassLoader.java:621) java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1853) org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:875) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1330) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1209) java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) java.lang.Class.getDeclaredMethods0(Native Method) java.lang.Class.privateGetDeclaredMethods(Class.java:2427) java.lang.Class.getDeclaredMethods(Class.java:1791) org.jboss.cache.util.reflect.ReflectionUtil.inspectRecursively(ReflectionUtil.java:53) org.jboss.cache.util.reflect.ReflectionUtil.getAllMethods(ReflectionUtil.java:36) org.jboss.cache.factories.ComponentRegistry.addComponentDependencies(ComponentRegistry.java:232) org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:219) org.jboss.cache.factories.ComponentRegistry.<init>(ComponentRegistry.java:98) org.jboss.cache.DefaultCacheFactory.bootstrap(DefaultCacheFactory.java:125) org.jboss.cache.DefaultCacheFactory.createAndWire(DefaultCacheFactory.java:115) org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:94) org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:79) org.xwiki.cache.jbosscache.internal.JBossCacheCache.initialize(JBossCacheCache.java:101) org.xwiki.cache.jbosscache.internal.JBossCacheCacheFactory.newCache(JBossCacheCacheFactory.java:78) com.xpn.xwiki.store.XWikiCacheStore.initCache(XWikiCacheStore.java:99) com.xpn.xwiki.store.XWikiCacheStore.initCache(XWikiCacheStore.java:84) com.xpn.xwiki.store.XWikiCacheStore.<init>(XWikiCacheStore.java:64) com.xpn.xwiki.XWiki.initXWiki(XWiki.java:679) com.xpn.xwiki.XWiki.<init>(XWiki.java:655) com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:315) com.xpn.xwiki.XWiki.getXWiki(XWiki.java:386) com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:135) com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115) org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) javax.servlet.http.HttpServlet.service(HttpServlet.java:689) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:94) com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287) com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) *cause mère* java.lang.ClassNotFoundException: org.jgroups.blocks.RpcDispatcher$Marshaller org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1363) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1209) java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) java.lang.ClassLoader.defineClass1(Native Method) java.lang.ClassLoader.defineClass(ClassLoader.java:621) java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1853) org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:875) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1330) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1209) java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) java.lang.Class.getDeclaredMethods0(Native Method) java.lang.Class.privateGetDeclaredMethods(Class.java:2427) java.lang.Class.getDeclaredMethods(Class.java:1791) org.jboss.cache.util.reflect.ReflectionUtil.inspectRecursively(ReflectionUtil.java:53) org.jboss.cache.util.reflect.ReflectionUtil.getAllMethods(ReflectionUtil.java:36) org.jboss.cache.factories.ComponentRegistry.addComponentDependencies(ComponentRegistry.java:232) org.jboss.cache.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:219) org.jboss.cache.factories.ComponentRegistry.<init>(ComponentRegistry.java:98) org.jboss.cache.DefaultCacheFactory.bootstrap(DefaultCacheFactory.java:125) org.jboss.cache.DefaultCacheFactory.createAndWire(DefaultCacheFactory.java:115) org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:94) org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:79) org.xwiki.cache.jbosscache.internal.JBossCacheCache.initialize(JBossCacheCache.java:101) org.xwiki.cache.jbosscache.internal.JBossCacheCacheFactory.newCache(JBossCacheCacheFactory.java:78) com.xpn.xwiki.store.XWikiCacheStore.initCache(XWikiCacheStore.java:99) com.xpn.xwiki.store.XWikiCacheStore.initCache(XWikiCacheStore.java:84) com.xpn.xwiki.store.XWikiCacheStore.<init>(XWikiCacheStore.java:64) com.xpn.xwiki.XWiki.initXWiki(XWiki.java:679) com.xpn.xwiki.XWiki.<init>(XWiki.java:655) com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:315) com.xpn.xwiki.XWiki.getXWiki(XWiki.java:386) com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:135) com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115) org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) javax.servlet.http.HttpServlet.service(HttpServlet.java:689) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:94) com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287) com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) Thanks for your time.

16 years, 10 months

3
7
0 0

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

by Vincent Massol

Hi Asiri, Are you sure this should go in the office importer and not in the HTML cleaner or in the XHMTL parser? Thanks -Vincent On Nov 24, 2008, at 6:08 PM, asiri (SVN) wrote: > Author: asiri > Date: 2008-11-24 18:08:51 +0100 (Mon, 24 Nov 2008) > New Revision: 14425 > > Modified: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/RedundantTagFilter.java > Log: > XAOFFICE-1 : Develop the initial feature set for office-importer > plugin. > > * Added support for filtering empty / redundant paragraphs. > > Modified: sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/ > xwiki/plugin/officeimporter/filter/RedundantTagFilter.java > =================================================================== > --- sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/RedundantTagFilter.java 2008-11-24 > 15:17:17 UTC (rev 14424) > +++ sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/ > plugin/officeimporter/filter/RedundantTagFilter.java 2008-11-24 > 17:08:51 UTC (rev 14425) > @@ -31,12 +31,13 @@ > > public void filter(Document document, ImporterContext context) > { > - for(String key : attributeWiseFilteredTags) { > + for (String key : attributeWiseFilteredTags) { > > filterNodesWithZeroAttributes(document.getElementsByTagName(key)); > } > - for(String key : contentWiseFilteredTags) { > + for (String key : contentWiseFilteredTags) { > > filterNodesWithEmptyTextContent(document.getElementsByTagName(key)); > - } > + } > + filterEmptyParagraphs(document); > } > > /** > @@ -70,10 +71,35 @@ > { > for (int i = 0; i < elements.getLength(); i++) { > Element element = (Element) elements.item(i); > - if (element.getTextContent().trim().equals("")) { > + if (element.getTextContent().trim().equals("")) { > element.getParentNode().removeChild(element); > i--; > } > } > } > + > + /** > + * OpenOffice server generates redundant paragraphs (with empty > content) to achieve spacing. > + * These paragraphs should be stripped off / replaced with > {@code <br/>} elements appropriately > + * because otherwise they result in spurious {@code (%%)} > elements in generated xwiki content. > + * > + * @param document The html document. > + */ > + private void filterEmptyParagraphs(Document document) > + { > + NodeList paragraphs = document.getElementsByTagName("p"); > + for (int i = 0; i < paragraphs.getLength(); i++) { > + Element paragraph = (Element) paragraphs.item(i); > + if (paragraph.getTextContent().trim().equals("")) { > + // We suspect this is an empty paragraph but it is > possible that it contains other > + // non-textual tags like images. For the moment > we'll only search for internal image > + // tags, we might have to refine this criterion > later. > + NodeList internalImages = > paragraph.getElementsByTagName("img"); > + if (internalImages.getLength() == 0) { > + paragraph.getParentNode().removeChild(paragraph); > + i--; > + } > + } > + } > + } > }

16 years, 10 months

1
0
0 0

[xwiki-devs] java.lang.ClassNotFoundException: org.xwiki.container.servlet.XWikiPlexusServletContextListener

by Juergen Lorenz Simon

Hi, I'm attempting to develop a couple of plugins to integrate XWiki into a portal solution. Unfortunately I'm having problems getting a debug session going in Eclipse. I followed the instructions in the XWiki dev wiki to the letter, with the small change of going from 1.6 (as stated in the wiki examples) to 1.7, which seems to be the latest snapshot. Also I'm using Tomcat 6. I get the following exception when attempting to run the app on the server: SEVERE: Error configuring application listener of class org.xwiki.container.servlet.XWikiPlexusServletContextListener java.lang.ClassNotFoundException: org.xwiki.container.servlet.XWikiPlexusServletContextListener at org .apache .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: 1360) at org .apache .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: 1206) at org .apache .catalina.core.StandardContext.listenerStart(StandardContext.java:3786) at org.apache.catalina.core.StandardContext.start(StandardContext.java: 4350) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java: 1045) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java: 1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java: 443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java: 710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) I also noticed that the tmp0/wtpapps/xe-debug-web/WEB-INF/lib directory only contains the plugin code. All other dependencies are not pulled in. That does not seem right. I'm using Eclipse 3.4, M2Eclipse 0.9.6 and Tomcat 6. Here is the xe-debug-web's pom file:

16 years, 10 months

1
0
0 0

[xwiki-devs] [proposal] Access to XWQL & QueryManager for scripts

by Artem Melentyev

Hi devs! As you know XWQL was introduced in 1.6, but without some easy access from scripts. Currently it is accessible via $xwiki.xWiki.store.queryManager.createQuery(stmt, "xwql") and only with programming rights. We need some easy ways to access to XWQL similar as $xwiki.searchDocuments, countDocuments and search. This will allow to users much more test XWQL and send us feedback. I planed to implement this by 1.7RC1 or 1.7. This is just an interface for xwiki scripts and doesn't affect to important parts of platform. Name of this service? 1. $xwiki.queryManager ($xwiki.query is occupied by old QueryPlugin) Later this will be obsoleted by 2. or 2. $services.query $services was proposed in our velocity bridge proposal[1]. We may implement only $service now as just simple services holder, without uberspectors. $services will be reimplemented later, but "$service.query" name will be saved. [1] http://markmail.org/message/nnybto3mluvp2rov I'm for 1 because velocity bridge isn't exist yet and its design may be changed. Technically it will be just some proxy for QueryManager and Query with access right checking. Functionality? 1. Just the same as QueryManager so: .createQuery("stmt", "lang").execute() or 2. The same as QueryManager + .xwql("stmt") method which will call .createQuery("stmt", "xwql") .xwql("stmt") is much more laconically than createQuery. Later it may be transparently replaced by 3. or 3. QueryManager + dynamic methods like .language("stmt") impossible without velocity bridge uberspectors. I'm for 2. Access rights? One way: 1. short-form xwql queries like "where <whereexpr>" and "from <fromexp> where <whereexpr>" return only document names, so will be available for everyone. this is analogue for $xwiki.searchDocuments() 2. full-form xwql ("select <selectlist> from <etc>" ) will require programming rights. this is analogue for $xwiki.search() 3. all other languages (currently only HQL) in QueryManager will require programming rights. 4. Query.setWiki will require programming rights. So we need to wrap Query with some SecureQuery. How should be analogue for "$xwiki.countDocuments"? Ways: 0. No analogue. just query.execute().size() JCRSQL2 has no aggregate functions at all. We could make lazy query result list to fix negatives. 1. just accept all queries like "select count(*) ..." ("*" is not supported in count() according jpql) 2. implement some simple syntax extension in xwql: "count [from ...] where ..." no parser change, just replace the statement prefix I'm 0 for now. WDYT? -- Artem Melentyev

16 years, 10 months

5
5
0 0

[xwiki-devs] [Proposal][Vote] Design of Annotation feature

by Lucien PEREIRA

Hi, I'd like to propose this design <http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature> for annotation feature implementation. Vote is about choosing between solution 1 and 2. if we can have an (almost) perfect bijective function between HTML and XWiki code, I'm +1 for solution 2 because implementation will be more efficient , stable and clean. Otherwise solution 1 seems to be a good solution. WDYT? Lucien

16 years, 10 months

6
10
0 0

Re: [xwiki-devs] [VOTE][UI] WYSIWYG general layout (SUMMARY)

by Jean-Vincent Drean

Six +1, no 0, no -1. Vote passed. Thanks, JV. On Fri, Nov 21, 2008 at 10:33 AM, Jean-Vincent Drean <jv(a)xwiki.com> wrote: > Hi XWikiers, > > I've started to refactor WYSIWYG mockups according to the last > discussions on the list. For this first vote I propose to validate its > general layout. > The mockup can be found here, I hope it is self-explaining : > http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HToolb… > You can ignore the inline syntax help in wiki mode, it was just a > thought while doing the mockup. > > Here's my +1. > > JV. >

16 years, 10 months

1
0
0 0

[xwiki-devs] [VOTE][UI] WYSIWYG general layout

by Jean-Vincent Drean

Hi XWikiers, I've started to refactor WYSIWYG mockups according to the last discussions on the list. For this first vote I propose to validate its general layout. The mockup can be found here, I hope it is self-explaining : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HToolb… You can ignore the inline syntax help in wiki mode, it was just a thought while doing the mockup. Here's my +1. JV.

16 years, 10 months

7
9
0 0

[xwiki-devs] [Rendering] Parameters for images that are linked to

by Vincent Massol

Hi, We have a decision to take to support image parameters when we're linking to an image. Here's what this would mean with the current syntax: [[[[image:attach.png||height="100" width="100"]]>>http://xwiki.org|| param=value]] Is that what we want? I'm not even sure we can implement this since wikimodel will consider the reference to be: [[[[image:attach.png||height="100" width="100"]] (since it'll use the first closing reference marker, i.e. "]]") So the question is: do we want to use a different syntax for images or should I try to make this one work? WDYT? Thanks -Vincent

16 years, 10 months

4
10
0 0

Re: [xwiki-devs] [xwiki-notifications] r14301 - in platform/core/trunk/xwiki-rendering/src: main/java/org/xwiki/rendering/internal/transformation test/java/org/xwiki/rendering test/java/org/xwiki/rendering/internal/transformation test/resources/META-INF/plexus test/resources/macros

by Vincent Massol

On Nov 21, 2008, at 2:51 AM, Sergiu Dumitriu wrote: > vmassol (SVN) wrote: >> + getLogger().debug("The [" + >> macroHolder.macroBlock.getName() + "] macro doesn't support inline >> mode."); > >> + getLogger().debug("Failed to execute macro [" + >> macroHolder.macroBlock.getName() + "]. Internal error [" >> + + e.getMessage() + "]"); > >> getLogger().debug("Failed to locate macro [" + >> macroBlock.getName() + "]. Ignoring it."); > > You should use the new formatting logger methods, like: > > getLogger().debug("Failed to locate macro [{0}]. Ignoring it.", > macroBlock.getName()); Can you remind me what are the advantages since I see 2 drawbacks: * the log message becomes harder to write and read since you need to mentally map the numbers with the parameters * If you have single quote in debug messages it'll fail (in message formats you must always use '' (two single quotes) to display a single single quote. I've been bitten by this in the past. Note that performance don't matter at all for logging errors. One advantage I'd see is to for i18n, However I don't think we want to internationalize error messages. I'm not against using this. I just want to be sure we have a good rationale before we start converting systematically all our logs to it. Thanks -Vincent

16 years, 10 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r14355 - sandbox/xwiki-application-ratings/src/main/resources/XWiki

by Sergiu Dumitriu

jvelociter (SVN) wrote: > +Event.observe(window, 'load', function() I learned that the version of prototype we are using allows us to use: document.observe("dom:loaded", function(){...}); This is better, since onload is triggered once all the components of the page are loaded (including images), while dom:loaded is triggered as soon as all the HTML was received, without waiting for other resources to load. More info on http://www.prototypejs.org/api/document/observe -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 10 months

2
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r14298 - in platform/core/trunk: . xwiki-core xwiki-core/src/main/java/com/xpn/xwiki/render xwiki-core/src/main/java/com/xpn/xwiki/render/groovy xwiki-macros xwiki-macros/xwiki-macro-groovy xwiki-macros/xwiki-ma

by Thomas Mortagne

On Fri, Nov 21, 2008 at 7:28 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > tmortagne (SVN) wrote: >> Author: tmortagne >> Date: 2008-11-19 15:57:38 +0100 (Wed, 19 Nov 2008) >> New Revision: 14298 > >> Log: >> XWIKI-2825: Create a generic script macro > > A quick review of the xwiki-script module: > > - DefaultScriptContextManager and ScriptExecutionContextInitializer > should be in the internal package. > - ScriptExecutionContextInitializer is not declared in components.xml, > thus it is not used. > - getScriptContext calls the initializers on each call. Is that correct? > Shouldn't the context be initialized only once? It in initialized only once (there is an if if (scriptContext.getAttribute("util") == null) in it). I was in a hurry for the 1.7M3 release so I just follow the way it's done for Velocity. > - scriptContextInitializerList (which also contains a typo in its name) > could be completely injected by Plexus, thus there's no need for > Initializable and Composable on this class. Just declare a dependency on > ScriptContextInitializer components. How do you do that ? The context initializers are retrieved the same way in DefaultExecutionContextInitializerManager so I assumed it was not possible to inject a list of dependencies in component.xml. > - The javadocs on the interfaces could be improved... They are rather > short right now. > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

16 years, 10 months

2
1
0 0

[xwiki-devs] [OFFICEIMPORTER] Style Filtering Policy & Mechanism.

by Asiri Rathnayake

Hi Devs, I'm working on implementing the style filtering functionality of xwiki-office-importer application. But first, i need to make sure that I'm clear about the policy and the correct approach towards filtering style information from imported office documents. I would really appreciate your input on this because I'm not an expert on either html or css :) Ok, I plan to do two types of filtering. One is filtering various attributes of various elements (like removing bgcolor attribute from the <body> element). And the second one is filtering css related stuff. Let's take one by one. 1. Filtering attributes. This is quite straight-forward but i see two possible approaches. * The first approach is to keep a list of attributes that we allow when importing documents. We'll scan each and every tag and strip off any unwanted attributes present. * The second approach is to associate each tag with what attributes we allow for that tag. A list of legal attributes for common tags is presented here http://www.devx.com/projectcool/Article/19816. Similarly, we'll have our tag_name->allowed_attributes mapping and filter all other attributes present. I'm currently leaning towards the second option, WDYT ? 2. Filtering css styles. Ok, there are three ways one can associate css with html content. Let's take one by one. (i) External Style Sheet Well, AFAIK OpenOffice server does not produce this type of output when converting office documents into html. I mean it doesn't output html files that refer external css files. So I guess this is something we don't need to worry about. (ii) Internal Style Sheet This is something we need to worry about. OpenOffice server produces html pages with content like <head><style type="text/css">....</style></head>. Currently we strip off <style> tags completely regardless of the filtering mode (i.e whether styles are set to be filtered or not <style> tags get removed). Does this behaviour need to change ? (iii) In-line Styles This is the most common type of styling found (Example : <p style="....">). Present behaviour is to strip off this style attribute completely (if filterStyles is set to true). The question is, there are some inline styles that directly maps to xwiki 2.0 syntax like <p style="font-weight:bold">, what are we going to do about these ? In any case, I will have to parse the in-line style attribute string to filter those style directives that are not necessary. The complete grammar for in-line style attributes seems to be a bit complicated to be hand crafted (http://www.w3.org/TR/css-style-attr) although in OpenOffice converted documents i have only seen the "key:value;key:value" format. What should be the correct approach to parse the style attribute string ? Thank you very much for your ideas. :) [image: Asiri Rathnayake's Facebook profile]<http://www.facebook.com/people/Asiri_Rathnayake/534607921>

16 years, 10 months

4
14
0 0

[xwiki-devs] [ANN] XWiki Enterprise 1.7 Milestone 3 Released

by Thomas Mortagne

he XWiki development team is pleased to announce the release of XWiki Enterprise 1.7 Milestone 3. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Last milestone of the XWiki Enterprise 1.7 version. Main changes: * Webdav support * Groovy upgrade * New script macro Important bug fixes: * The old LDAP authenticator is still used by default in some cases Note that general goals for XWiki Enterprise 1.7 are * Working and usable (i.e. users can use them for their day to day work instead of the old Syntax and old WYSIWYG editor) versions of new rendering and new WYSIWYG editor. * Working JCR (can be used for day to day work instead of Hibernate). * French XE * Blog revamping * Webdav integration For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise17M3 Thanks, The XWiki dev team

16 years, 10 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r14298 - in platform/core/trunk: . xwiki-core xwiki-core/src/main/java/com/xpn/xwiki/render xwiki-core/src/main/java/com/xpn/xwiki/render/groovy xwiki-macros xwiki-macros/xwiki-macro-groovy xwiki-macros/xwiki-macro-groovy/src xwiki-macros/xwiki-macro-groovy/src/main xwiki-macros/xwiki-macro-groovy/src/main/resources xwiki-macros/xwiki-macro-groovy/src/main/resources/META-INF xwiki-macros/xwiki-macro-groovy/src/main/resources/META-INF/plexus xwiki-macros/xwiki-macro-gro

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-11-19 15:57:38 +0100 (Wed, 19 Nov 2008) > New Revision: 14298 > Log: > XWIKI-2825: Create a generic script macro A quick review of the xwiki-script module: - DefaultScriptContextManager and ScriptExecutionContextInitializer should be in the internal package. - ScriptExecutionContextInitializer is not declared in components.xml, thus it is not used. - getScriptContext calls the initializers on each call. Is that correct? Shouldn't the context be initialized only once? - scriptContextInitializerList (which also contains a typo in its name) could be completely injected by Plexus, thus there's no need for Initializable and Composable on this class. Just declare a dependency on ScriptContextInitializer components. - The javadocs on the interfaces could be improved... They are rather short right now. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 10 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r14301 - in platform/core/trunk/xwiki-rendering/src: main/java/org/xwiki/rendering/internal/transformation test/java/org/xwiki/rendering test/java/org/xwiki/rendering/internal/transformation test/resources/META-INF/plexus test/resources/macros

by Sergiu Dumitriu

vmassol (SVN) wrote: > + getLogger().debug("The [" + macroHolder.macroBlock.getName() + "] macro doesn't support inline mode."); > + getLogger().debug("Failed to execute macro [" + macroHolder.macroBlock.getName() + "]. Internal error [" > + + e.getMessage() + "]"); > getLogger().debug("Failed to locate macro [" + macroBlock.getName() + "]. Ignoring it."); You should use the new formatting logger methods, like: getLogger().debug("Failed to locate macro [{0}]. Ignoring it.", macroBlock.getName()); -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 10 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r14297 - in platform/core/trunk: xwiki-bridge/src/main/java/org/xwiki/bridge xwiki-core/src/main/java/com/xpn/xwiki/doc xwiki-rendering/src/test/java/org/xwiki/rendering/internal

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-11-19 15:48:09 +0100 (Wed, 19 Nov 2008) > New Revision: 14297 > > Modified: > platform/core/trunk/xwiki-bridge/src/main/java/org/xwiki/bridge/DocumentAccessBridge.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/DefaultDocumentAccessBridge.java > platform/core/trunk/xwiki-rendering/src/test/java/org/xwiki/rendering/internal/MockDocumentAccessBridge.java > Log: > XWIKI-2855: Add a bridge to know if current document author has programming rights > I don't quite like this. Programming rights should not be part of the model. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 10 months

2
1
0 0

[xwiki-devs] Problems on xwiki.org and myxwiki.org DB servers

by Vincent Massol

Hi, Just to let you know that for the next 20 minutes, it's possible that you'll find some problem saving tasks in jira, or wiki pages on our free wikis. Thanks -Vincent

16 years, 10 months

1
0
0 0

[xwiki-devs] Trouble with Panel Wizard

by MinhHoang To

Hi, I created a new widget displaying some statistical data via the Panel Wizard. With the 'admin' logins, that widget is always visible. However, when i logged in with non-admin username ( with View right granted), the newly created widget is no longer visible. Apparently, there are 2 most likely causes: -The widget contains a Groovy/Velocity snippet that requires Programming right to see - The non-admin username does not enough rights to see the widget Anyone could help me?

16 years, 10 months

1
0
0 0

[xwiki-devs] Protect script macros executing

by Thomas Mortagne

Hi devs, I'm finishing the generic script macro (based on jsr 223) and the groovy macro based on it. It's working pretty well but I have a last issue: what do we do about security ? I can't commit as it is because, like the "old" groovy macros, you can do almost everything so we have to protected the script macros from "simple" users. Now how do we do that ? 1) The quicker is to use the programming right with some bridge like the old groovy macro but it would be better to get rid of this special right in the new architecture. 2) we could also use the JAVA security policy to run the scripts in a "sandbox" but I think it means that the XWiki platform called by a scripts is also running in the same limited sandbox (?). 3) groovy has it's own support of JAVA security policy (see http://groovy.codehaus.org/Security) which give us the best control on it but it means it's only groovy 2) and 3) means also for us to define the exhaustive list of allowed or forbidden JVM api. I'm -1 for 1), I'm not sure for the details of 2) and I would prefer to be as generic as possible so i don't like 3) very much. I did not looked deeply on 2) and 3) yet, it's just a first mail to know if someone already played with theses concepts in JAVA. So WDYT ? Any other ideas ? -- Thomas Mortagne

16 years, 10 months

2
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r14029 - platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/transformation

by Vincent Massol

Note: We're testing the ability to change the log of an already committed message. It's not working yet since I just changed the log and it's showing a diff in the code... Thanks -Vincent On Nov 18, 2008, at 3:28 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-11-06 18:55:27 +0100 (Thu, 06 Nov 2008) > New Revision: 14029 > > Modified: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/ > rendering/transformation/MacroTransformationContext.java > Log: > Fixed javadoc (test) > > Modified: platform/core/trunk/xwiki-rendering/src/main/java/org/ > xwiki/rendering/transformation/MacroTransformationContext.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/ > rendering/transformation/MacroTransformationContext.java 2008-11-06 > 17:44:22 UTC (rev 14028) > +++ platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/ > rendering/transformation/MacroTransformationContext.java 2008-11-06 > 17:55:27 UTC (rev 14029) > @@ -125,7 +125,7 @@ > } > > /** > - * @param syntaxId the current syntax. > + * @param syntax the current syntax. > */ > public void setSyntax(Syntax syntax) > {

16 years, 10 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r14266 - sandbox/xwiki-application-officeimporter/src/main/resources/Import

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2008-11-18 09:01:29 +0100 (Tue, 18 Nov 2008) > New Revision: 14266 > > Added: > sandbox/xwiki-application-officeimporter/src/main/resources/Import/Importer > Removed: > sandbox/xwiki-application-officeimporter/src/main/resources/Import/Converter > Modified: > sandbox/xwiki-application-officeimporter/src/main/resources/Import/WebHome > Log: > XAOFFICE-1 : Develop the initial feature set for office-importer plugin. Wiki document sources should have the .xml extension. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 10 months

2
1
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