November 2008 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] Add JAR resource HTML extension in SX
by Jerome Velociter 27 Nov '08

27 Nov '08

Hello everybody, Right now with Skin eXtensions we can hit "jsx" and "ssx" action URLs to retrieve JavaScript and CSS files, that either comes from XObjects (the original SX idea) or from JAR resources (since SX 1.3). I'm playing with the idea of adding a new action that would return text/html, possibly available as JAR resource extension _only_. I explain below how I came to this need. This morning I gave some thoughts on the behavior the {{map}} macro should have when the Internet is not reachable, but the wiki is (any resemblance to actual facts is... not coincidental;)). The only alternative I found not to have the macro blocking the whole page loading until the HTTP requests gives up trying to get the library from the service provider (google, yahoo, etc.) is to have it being loaded in an iframe (and then display the map in that iframe, too). For this to happen however, I need to pass an URL to that iframe which will give the html needed (<script> tag for the library, <script> to consume the library, and probably a <div> container for the map itself, etc.) Since I work with the constraint of being to publish the macro as a jar only, I would like this HMTL file to be a resource file of my macro (otherwise, a simple wiki page called with "xpage=plain" would do the trick, obviously). Since ssx and jsx returns content type according to the resource they provide, we cannot use them for this purpose (and it would be hackish use anyway). Thus I propose we add a new action "hsx" for example, to return "text/html" content. This extension does not have much sense as a document extension (since we don't know where to inject the result, unless the new XClass has a "extension point" field but then it becomes somehow an IX class), so I it would be available only as JAR resource extension. Did I miss something there ? Sergiu what do you think ? Others ? Jerome.

1 3

[xwiki-devs] [Rendering] Refactoring Idea: JCR...
by Vincent Massol 27 Nov '08

27 Nov '08

Hi, One refactoring idea: we could probably replace our Block implementation by the JCR API. This would allow to benefit from already existing code (JackRabbit for ex) such as the query manager, navigation in the XDOM tree, etc. Pros: - less code to write - more powerful API - standard-based Cons: - Need to rewrite our Block implementation - more external dependencies (jackrabbit and what it draws) WDYT? Thanks -Vincent

1 1

[xwiki-devs] Join me on Bebo
by Arvind Gupta 27 Nov '08

27 Nov '08

You will like it. Click to find out why Please accept or reject this invitation by clicking below: http://www.bebo.com/in/8210404647a433319350b135 ...................................................................... This email was sent to you at the direct request of Arvind Gupta <arvind.bernaulli(a)gmail.com>. You have not been added to a mailing list. If you would prefer not to receive invitations from ANY Bebo members please click here - http://www.bebo.com/unsub/8210404647a433319350 Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.

2 2

[xwiki-devs] Resolving the mismatch between an xwiki page and a dav collection resource.
by Asiri Rathnayake 27 Nov '08

27 Nov '08

Hello Devs, In webdav view of xwiki, a wiki page (document) is represented by a webdav collection resource (somewhat like a directory). This collection resource is comprised of wiki.txt, wiki.xml, attachments & child pages. As you can see, there is a mismatch between these two concepts: without wiki.txt & wiki.xml (children), a wiki page (the parent) cannot exist, but this is the otherway around in a filesystem like structure. So a question arises, in webdav space what does it mean to delete a wiki page ? 1. We can treat deleting wiki.txt and/or wiki.xml as deleting the whole page. But deleting the parent when only the children were asked to be deleted is wrong. And most of the webdav clients go insane. 2. We can prohibit wiki.txt & wiki.xml being deleted (i.e. throw an exception). But this would prohibit users from deleting pages on some clients because they use a recursive delete procedure (i.e. delete children first and then delete the parent). When deleting children fails, the whole operation fails. 3. We can trick the clients to believe that the delete was a success (repport AOK) and continue like nothing went wrong. This way a recursive delete will succeed. But if the client re-request the resource just to make sure the delete was a success, the deleted wiki.xml and wiki.txt will appear again. Some clients indeed behave like this and they fail. This is the current approach we have taken. 4. We can put wiki.txt & wiki.xml inside the HttpSession object the first time we initialize a particular resource. This way, the deletes will succeed and even if the client re-validates the delete, those child resources will not appear again. This approach seems to prevent all of the above mentioned problems but again, we're using a hack. Also, this implies that a page (dav collection) can exist without wiki.txt & wiki.xml. I voting in favour of the 4th option. Do you see any other way to get around this mismatch ? Thanks. - Asiri [image: Asiri Rathnayake's Facebook profile]<http://www.facebook.com/people/Asiri_Rathnayake/534607921>

2 3

[xwiki-devs] [Rendering] Honor whitespaces in cells or not?
by Vincent Massol 27 Nov '08

27 Nov '08

Hi, Do we want to honor whitespaces in table cells or not? The main advantage of trimming them is to get aligned cell symbols. See http://www.wikicreole.org/wiki/Creole1.0#section-Creole1.0-Tables Right now we're honoring whitespaces (they are significant). If we want to be consistent with normal wiki text we should honor them since we're honoring spaces in wiki text. However we just need to agree that it won't be possible to get nicely aligned cell delimiters then. WDYT? Thanks -Vincent

6 13

[xwiki-devs] [Rendering] Refactoring Proposal
by Vincent Massol 27 Nov '08

27 Nov '08

Hi, I'd like to propose refactoring the Listener/Renderer classes for the following reasons: * too hard to write renderers since they're using a "streaming" API which makes it very difficult to have lookaheads * streaming api not required since we're using a XDOM object which "breaks" streaming anyway Thus I'm proposing to: * Remove Listener interface * Modify Renderer interface to have a single method: render(XDOM, WikiPrinter) * Rewrite existing Renderers and make them components (it would now be possible) I have brainstormed on this with Thomas Mortagne and we have both agreed that we don't see any problems with this since we absolutely need the XDOM object for: * ability to have macro priorities (TOC, Include macro, etc) and powerful transformations in general * ability to cache parsed content Let me know what you think quickly since I'd like to start the refactoring ASAP since it's a prerequisite for doing another refactoring (moving the XWikiXhtmlEscapeHandler to the XWikiSyntaxRenderer) which itself is required for solving this issue: http://jira.xwiki.org/jira/browse/XWIKI-2851 Thanks -Vincent

1 0

[xwiki-devs] Translations : syntax to use (msg.get values) to internationalize pages
by Thomas Eveilleau 27 Nov '08

27 Nov '08

Hello, I'd like to work on translations of default XE pages (pages that are not internationalized yet) like Photos.WebHome, Main.Tags, Panels etc. In order to do things correctly I'd like to now the syntax I should use for the $msg.get values. What we have in a page like XWiki.XWikiUserSheet is : "platform.core.profile.firstname" for the firstname 1 ) Should I use the same syntax ("platform.core.tags.title" for the title of Main.Tags - if i keep my example) ? 2 ) Or should we use more scalable values (tomorrow we will have a core and applications on it : should we consider the Panels as an application and have something like "application.panel.panelname.element" ?). 3 ) Maybe that we also can use things like the fullname of a page in the value (to quickly identify it) and having something like : "appplication.panel.Panels.Search.title" I'm waiting for your advices on this (1 / 2 / 3 or another proposal). Thanks, Thomas Eveilleau

5 9

[xwiki-devs] java.lang.ClassNotFoundException: org.xwiki.container.servlet.XWikiPlexusServletContextListener
by Juergen Lorenz Simon 26 Nov '08

26 Nov '08

Hi, I'm trying to develop plugins for XWiki using Eclipse 3.4. I went through the process outlined in the developer wiki twice and can not get the project to start up. (xe- debug-web). When I start the web project in Tomcat 6, I get hit by this exception: Nov 26, 2008 6:47:52 PM org.apache.tomcat.util.digester.SetPropertiesRule begin WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'source' to 'org.eclipse.jst.jee.server:xe-debug-web' did not find a matching property. Nov 26, 2008 6:47:52 PM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: .:/Users/simon/Library/Java/Extensions:/Library/ Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java Nov 26, 2008 6:47:52 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 Nov 26, 2008 6:47:52 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 633 ms Nov 26, 2008 6:47:52 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Nov 26, 2008 6:47:52 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.18 Nov 26, 2008 6:47:52 PM org.apache.catalina.core.StandardContext listenerStart 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: 1387) at org .apache .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: 1233) at org .apache .catalina.core.StandardContext.listenerStart(StandardContext.java:3786) at org.apache.catalina.core.StandardContext.start(StandardContext.java: 4342) 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) Nov 26, 2008 6:47:52 PM org.apache.catalina.core.StandardContext listenerStart SEVERE: Skipped installing application listeners due to previous error(s) Nov 26, 2008 6:47:52 PM org.apache.catalina.core.StandardContext start SEVERE: Error listenerStart Nov 26, 2008 6:47:52 PM org.apache.catalina.core.StandardContext start SEVERE: Context [/xe-debug-web] startup failed due to previous errors Nov 26, 2008 6:47:52 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 Nov 26, 2008 6:47:53 PM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 Nov 26, 2008 6:47:53 PM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/37 config=null Nov 26, 2008 6:47:53 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 1003 ms I took extra care the second time round to ensure I followed the instructions to the letter. I noticed again that the WEB-INF/lib directory is EMPTY. I assumed that Maven should download and install the required jarfiles there? Am I missing something? Cheers, J.L.Simon

2 1

Re: [xwiki-devs] [xwiki-notifications] r14446 - sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/plugin/officeimporter/filter
by Sergiu Dumitriu 26 Nov '08

26 Nov '08

asiri (SVN) wrote: > Author: asiri > Date: 2008-11-26 07:18:39 +0100 (Wed, 26 Nov 2008) > New Revision: 14446 > > Modified: > sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/plugin/officeimporter/filter/HtmlStyleFilter.java > Log: > XAOFFICE-1 : Develop the initial feature set for office-importer plugin. > > * Adding 'colspan' attribute to the allowed attribute lists under strict & moderate filter levels. This is acceptable since 'colspan' is a structuring element rather than styling element. Then rowspan should be allowed, too. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

Re: [xwiki-devs] [xwiki-notifications] r14455 - in xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors: . contentassist contentassist/strategies scanners scanners/rules utils
by Sergiu Dumitriu 26 Nov '08

26 Nov '08

fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2008-11-26 13:28:10 +0100 (Wed, 26 Nov 2008) > New Revision: 14455 > > Modified: > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/Constants.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/Preferences.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/XWikiEditorActionContributor.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/XWikiSourceViewerConfiguration.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/contentassist/CompoundContentAssistProcessor.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/contentassist/MacroContentAssistProcessor.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/contentassist/VelocityVariableContentAssistProcessor.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/contentassist/XWikiHeadingContentAssistProcessor.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/contentassist/XWikiLinkContentAssistProcessor.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/contentassist/XWikiStyleContentAssistProcessor.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/contentassist/strategies/TableAutoEditStrategy.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/contentassist/strategies/VelocityAutoEditStrategy.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/contentassist/strategies/XWikiMarkupAutoEditStrategy.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/scanners/VelocityScanner.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/scanners/XWikiMarkupScanner.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/scanners/XWikiPartitionScanner.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/scanners/rules/BalancedParenthesisRule.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/scanners/rules/RegExRule.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/utils/CharacterScannerCharSequence.java > xeclipse/trunk/plugins/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/editors/utils/XWikiApiTemplateManager.java > Log: > Cleanup. Removed all @author tags from source code in order to comply with XWiki code guidelines. You should add @version $Id$. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0