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

Mailsender plugin
by Stéphane Laurière 15 Jul '07

15 Jul '07

Hi everyone, I've refactored some code contributed by Fabrice and Jérome into a plugin that I committed to the xwiki-sandbox, under the plugins/mailsender folder (I'm using the sandbox since I find it handy for progressive refactoring and integration, but Vincent, please let me know if I should use JIRA attachments instead!). The plugin currently has the following API: =========== int sendTextMessage(String from, String to, String subject, String message) int sendTextMessage(String from, String to, String cc, String bcc, String subject,String message, List<Attachment> attachments) int sendHtmlMessage(String from, String to, String cc, String bcc, String subject, String body, String alternative, List<Attachment> attachments) int sendMessageFromTemplate(String from, String to, String cc, String bcc, String language, String documentFullName, VelocityContext vcontext) =========== The plugin creates its own "XWiki.Mail" class that has the following fields: - subject - language - text part - optional html part The class XWik.Mail is used by the method "sendMessageFromTemplate": this method evaluates the fields of the XWiki.Mail objects attached to the template document for building a custom message by using a VelocityRenderer. What do you think of the API? Any refactoring or enhancement remarks? Can we proceed with test and documentation writing, and submission for integration into 1.1M4? Related JIRA thread: http://jira.xwiki.org/jira/browse/XWIKI-1473 Cheers Stéphane

1 0

[Architecture V2] Request Handling
by Vincent Massol 15 Jul '07

15 Jul '07

Hi, After discussing the Model I'd now like to discuss the architecture for request handling. I propose the following: General Architecture: * A Request Manager component to handle incoming requests. * Action classes called by the Request Manager Details: * In web.xml we define a ServletContextListener for initializing the Component Manager (CM) the first time XWiki is started. This puts the component manager as an attribute in ServletContext. For Plexus this means registering PlexusServletContextListener.java * In web.xml we define the main XWiki Servlet. It depends on the CM. For Plexus this means extending the PlexusServlet class. The main thing that Servlet does it use the CM to find the Request Manager component and to call it. The other thing it does is create a XWikiRequest component and a Session component so that the CM can inject them in components requiring them. * The request manager is configured using the Component Manager configuration mechanism. For Plexus this is through a component.xml file located in META-INF/plexus. The configuration defines the different components to use for the different actions. For example: <components> <component> <role>org.xwiki.request.Action</role> <implementation>org.xwiki.request.ViewAction</implementation> <configuration> <action>view</action> <order>100</order> </configuration> </component> ... </components> Note: The order is there so that it's possible for non-core components to contribute Actions. For example this is useful for the ZipExplorer component which will contribute a ZipExplorerDownloadAction which should be executed before the default DownloadAction. * Other details: We'll have a XWikiRequest and a XWikiResponse classes and a URL Handler component and a XWikiURL class. * Here's an example of how an Action will be coded: public class MyAction implements Action { private XWikiRequest request; private XWikiSession session; public XWikiResponse execute() { ... } } The request and session object in this example are being injected automatically by the CM. * There are 2 kinds of configuration: static configuration like the one shown above for registering action names and order for Actions and user configuration (the one we currently have in xwiki.cfg). For user configuration we can have a Configuration component or even better have the config properties automatically injected in the component so that the component writer would one write: private List plugins; (in that case the mapping between "plugins" and the xwiki.plugins property would be defined in components.xml) * For logging, we can have define our own LoggerManager component and tell the CM to use it by registering it in plexus.xml. This will allow not to depend on any specific CM for logging (otherwise we would get a org.plexus.logger.Logger object). To summarize, with this proposal there are only 2 classes that depend on the CM: - the servlet context initializer - the main servlet which is just using the CM to call the Request Manager. WDYT? For OSGi lovers, how would you implement this in OSGi? Thanks -Vincent

1 0

removePage() XMLRPC not implemented ?
by tharindu jayasuriya 15 Jul '07

15 Jul '07

Hi All, I implemented the Boolean removeSpace(String token, String spaceKey)<http://confluence.atlassian.com/display/DOC/Remote+API+Specification> XML-RPC and executed that method. Then I got get an exception saying, "No such handler: confluence1.removePage". It seems like that removePage XMLRPC does not seem to be implemented on the server. Any help for this concern is highly appriciated. Here is the full stack-trace..................... org.apache.xmlrpc.XmlRpcException: No such handler: confluence1.removePage at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse( XmlRpcStreamTransport.java:184) at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest( XmlRpcStreamTransport.java:145) at org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest( XmlRpcHttpTransport.java:94) at org.apache.xmlrpc.client.XmlRpcSunHttpTransport.sendRequest( XmlRpcSunHttpTransport.java:39) at org.apache.xmlrpc.client.XmlRpcClientWorker.execute( XmlRpcClientWorker.java:53) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java :166) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java :157) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java :146) at org.xwiki.plugins.eclipse.rpc.impl.XWikiRPCHandler.rpcCall( XWikiRPCHandler.java:79) at org.xwiki.plugins.eclipse.rpc.impl.XWikiRPCHandler.removePage( XWikiRPCHandler.java:146) at org.xwiki.plugins.eclipse.model.impl.XWikiSpace.removeChildPage( XWikiSpace.java:408) at org.xwiki.plugins.eclipse.model.wrappers.XWikiSpaceWrapper$3.run( XWikiSpaceWrapper.java:271) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run( ModalContext.java:113) Thanks -Tharindu

3 7

Notice: 1.1M4 is the last release before the RCs
by Vincent Massol 14 Jul '07

14 Jul '07

Hi, Just wanted to remind everyone that 1.1M4 is the last release planned before the 1.1 RCs. Thus if you have some code you wish to see in 1.1 you'll need to get it before end of July (1.1M4 release date). Thanks -Vincent

1 0

Fwd: XWiki-Eclipse Plug-in Source Code Review.
by tharindu jayasuriya 14 Jul '07

14 Jul '07

For some reason this mail didn't go through. Sorry if you receive it twice.. - Tharindu ---------- Forwarded message ---------- From: tharindu jayasuriya <djtharindu(a)gmail.com> Date: Jul 13, 2007 1:37 PM Subject: XWiki-Eclipse Plug-in Source Code Review. To: xwiki-dev(a)objectweb.org Hi Vincent, We have cleaned up our source code and we're ready for a review. I have attached the eclipse project at, http://jira.xwiki.org/jira/browse/XECLIPSE-11 Looking forward to hear from you. Any comments that would help us improve our code are really appreciated. We'll start to implement the rest of the features allocated for R!.0M1 from now on. Thank you all. - Tharindu & Asiri

1 0

New XWiki Syntax Guide
by Vincent Massol 14 Jul '07

14 Jul '07

Hi everyone, Just wanted to let you know I have completely rewritten the XWiki Syntax Guide. It's available at: http://www.xwiki.org/xwiki/bin/view/UserGuide/XWikiSyntax Please let me know if you think anything is missing or not correct. That'll help improve it. Thanks -Vincent

2 1

Curriki database build (was Re: [xwiki-commits] r3966 - in xwiki-products/curriki/trunk: . gwt/src/main/java/org/curriki/gwt/client gwt/src/main/java/org/curriki/gwt/client/widgets/addfile gwt/src/main/java/org/curriki/gwt/client/wizard gwt/src/main/java/org/curriki/gwt/server web/src/main/webapp/skins/curriki8)
by Vincent Massol 13 Jul '07

13 Jul '07

Hi David, On Jul 13, 2007, at 12:41 AM, David Ward wrote: > Author: dward > Date: 2007-07-13 00:41:40 +0200 (Fri, 13 Jul 2007) > New Revision: 3966 > > Added: > xwiki-products/curriki/trunk/gwt/src/main/java/org/curriki/gwt/ > client/widgets/addfile/URLEntry.java > xwiki-products/curriki/trunk/gwt/src/main/java/org/curriki/gwt/ > client/widgets/addfile/VidiTalkUpload.java > xwiki-products/curriki/trunk/gwt/src/main/java/org/curriki/gwt/ > client/widgets/addfile/VidiTalkUploadDialog.java > Modified: > xwiki-products/curriki/trunk/gwt/src/main/java/org/curriki/gwt/ > client/Constants.java > xwiki-products/curriki/trunk/gwt/src/main/java/org/curriki/gwt/ > client/CurrikiService.java > xwiki-products/curriki/trunk/gwt/src/main/java/org/curriki/gwt/ > client/CurrikiServiceAsync.java > xwiki-products/curriki/trunk/gwt/src/main/java/org/curriki/gwt/ > client/widgets/addfile/AddFileDialog.java > xwiki-products/curriki/trunk/gwt/src/main/java/org/curriki/gwt/ > client/wizard/AddFileWizard.java > xwiki-products/curriki/trunk/gwt/src/main/java/org/curriki/gwt/ > server/CurrikiServiceImpl.java > xwiki-products/curriki/trunk/pom.xml > xwiki-products/curriki/trunk/web/src/main/webapp/skins/curriki8/ > macros.vm > Log: > - Add VIDITalk video asset creation to GWT code > - Center the VIDITalk playback component > - Allow compiling without database pieces (still has issues with > mysql) [snip] What's the problem? Thanks -Vincent > Modified: xwiki-products/curriki/trunk/pom.xml > =================================================================== > --- xwiki-products/curriki/trunk/pom.xml 2007-07-12 20:36:23 UTC > (rev 3965) > +++ xwiki-products/curriki/trunk/pom.xml 2007-07-12 22:41:40 UTC > (rev 3966) > @@ -41,14 +41,30 @@ > <developerConnection>scm:svn:svn+ssh://svn.forge.objectweb.org/ > svnroot/xwiki/xwiki-applications/curriki/trunk</developerConnection> > <url>http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/xwiki/ > xwiki-applications/curriki/trunk</url> > </scm> > - <modules> > - <module>plugins</module> > - <module>gwt</module> > - <module>web</module> > - <module>wiki</module> > - <module>database</module> > - <module>distribution</module> > - </modules> > + <profiles> > + <profile> > + <id>default</id> > + <activation> > + <activeByDefault>true</activeByDefault> > + </activation> > + <modules> > + <module>plugins</module> > + <module>gwt</module> > + <module>web</module> > + <module>wiki</module> > + <module>database</module> > + <module>distribution</module> > + </modules> > + </profile> > + <profile> > + <id>curriki-nodb</id> > + <modules> > + <module>plugins</module> > + <module>gwt</module> > + <module>web</module> > + </modules> > + </profile> > + </profiles> > <build> > <extensions> > <extension>

1 0

Removing the Navigation panel
by Vincent Massol 12 Jul '07

12 Jul '07

Hi, Yesterday, we had a discussion on IRC about removing the Navigation panel from right menu in the default XE menu. We all (Sergiu, Marta, Catalin and me) agree to remove it and thus I've gone ahead with it and it's now removed. With this email I'd like to make sure this is ok with everyone. I have added a new Panel called Quick Links which presents links to the most important pages on the wiki. Now I'm having some second thoughts. The Quick Links is great to navigate in the default wiki. The issue I have is the following: - We have a Create Panel and thus users are going to use it to create pages. This means their pages are not going to be linked from an existing page and thus the only way to browse them will be either though the Search or through the Index page/Treeview page. I think this is not enough as it's too long to require users to click on Index and search for their pages to access them. Of course they should create a navigation (as we're doing on xwiki.org for example) but they might need some practices before realising this. I think I'd be ok to add again the Navigation panel but we should exclude by default all the pages that have a quick links. WDYT? Any better idea? <some time pass/> Ah I have another idea. We could have a Navigation Panel showing pages that have no link to them (we need that anyway and we need to add that to the AllDocs page too). In that way any page that is linked could be accessed through their navigation and pages that are not linked can still be accessed easily. This should try to encourage users to create navigations without penalizing them . WDYT? Thanks -Vincent PS: I've just had an idea and I think it would be a killer feature... :) What about adding a shortcut so that on any page you can type ctrl+P (or ctrl+D or whatever other shortcut) and it would present a text field in the middle of the page allowing you to enter the name of the page you want to navigate to. It would work exactly as it works on IntelliJ IDEA (Ctrl+N) so you can type some letters and it'll propose pages. Even better, if the user hits the right arrow key, it would provide some actions for that page: view, edit, rename, delete with view being the default action so ctrl+P + Enter opens the page in view mode and ctrl+P + right arrow + down arrow + Enter opens the page in edit mode, etc. I'm very excited by the idea... WDYT?

3 4

XEM and Curriki duplicates
by Vincent Massol 12 Jul '07

12 Jul '07

Hi, I've noticed that the curriki and xem project duplicate a lot of content from the XE wiki. Just to give an example: - XWiki.Results - Admin.CopyDocument XE is being improved almost daily and as these are copy XEM and Curriki are not improved on their side. Also if they make improvements to these pages XE won't benefit from them either. I think we should not duplicate pages unless they are modified by XEM or Curriki. And even when there are modifications we should discuss how we could refactor the page to have common parts shared. This could be achieved by splitting the page in 2, or by creating templates or by creating new APIs for example. WDYT? Thanks -Vincent

1 0

Are there issues with the Maven build, or is it just me?
by Radu Danciu 12 Jul '07

12 Jul '07

For the last week or so, the build hasn't been working for me. I keep getting errors around the GWT Curriki part of the build. I thought it was something I did (I ctrl+c-ed out of the mvn install once), so I deleted the whole trunks-users from my drive, and svn co again. Tried mvn install then, and a new error pops up at about the same place: [INFO] Building XWiki Products - Curriki - Database [INFO] task-segment: [install] [INFO] ---------------------------------------------------------------------------- [INFO] [remote-resources:process] [INFO] [xwiki-build-xar:unxar] [INFO] [xwiki-packager:import] --------------------------------------------------- constituent[0]: file:/maven2/lib/maven-embedder-2.1-SNAPSHOT-ueber.jar constituent[1]: file:/Users/rhadoo/.m2/repository/com/xpn/xwiki/platform/xwiki-build-xar-handlers/1.1-SNAPSHOT/xwiki- build-xar-handlers-1.1-SNAPSHOT.jar --------------------------------------------------- Exception in thread "main" java.lang.OutOfMemoryError: Java heap space and it just freezes there, i have to force quit out of the terminal. I've updated the settings.xml to the latest version, and at this point I'm completely out of ideas. Help? Please? Radu

3 5