September 2008 - xwiki-devs@xwiki.org

Re: [xwiki-devs] Rich HTML editing in the browser
by Vincent Massol 30 Sep '08

30 Sep '08

(forwarding this very good article to the xwiki dev list) Indeed a very good article explaining well the issues. From the article I conclude that this feature is: * HTML 5 (and XHTML) * not standardized and thus with huge varying implementations depending on the browser Since I'm a newbie in this domain I'll ask some newbie questions... :) As a consequence of the above I don't understand why any cross-browser WYSIWYG editor would use this feature as of now. Wouldn't it be easier to implement everything in javascript? Since there are javascript frameworks that isolate the user from the browser specificities wouldn't it be easy to do that? Are all the existing WYSIWYG editor using this designMode/ ContentEditable feature? Thanks -Vincent On Sep 27, 2008, at 8:25 PM, Marius Dumitru Florea wrote: > Hi Vincent, > > I found by chance this article http://tinyurl.com/5rlwps . I's not > too long and worth reading in order to better understand the > difficulty of making a good cross-browser WYSIWYG editor. You're > already familiar with some of the issues discussed there. > > Have a nice evening, > Marius

2 1

[xwiki-devs] xwiki-webdav : xwiki-ui integration
by Asiri Rathnayake 30 Sep '08

30 Sep '08

Hello devs, Following couple of weeks i've been working on integrating xwiki-webdav in the xwiki ui and i'm confident now it's time to move out this effort from sandbox to our main xwiki source tree. Before discussing about where to put the xwiki-webdav and associated modules in the main source tree, following is a brief status update on what's going with xwiki-webdav. * xwiki-webdav can be deployed on it's own (with a preconfigured hsqldb) or more likely be integrated into an existing XE installation. Once deployed, various webdav clients (provided by your operating system or thirdparty applications) will be able to brows through an XE repository pretty easily. - It's worth to mention at this point that there are so many webdav clients out there and they vary in bahaviour a lot. This is the MOST-PAINFUL problem we're currently facing. And to get xwiki-webdav into shape, we need to test it a LOT! :) * xwiki-webdav is configured as a maven project ( http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-webdav/) and it can be deployed (for testing) pretty easily through maven-jetty-plugin. Also we have added quite a few integration tests to make sure of the basic dav functionality. * For interoperability with XP's built-in webdav client we had to put up a separate root servlet, this project is currently located at http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-rootwebapp/. xwiki-rootwebapp handles redirection and proper reply for the PROPFIND request at root level of webserver. * xwiki-webdav is integrated into xwiki ui with two approaches, one by provding an 'Edit' link in the attachments view of a page (for editing attachments via webdav) and the other is thorugh foxwiki's context menu. * To implement the 'Edit' link in the attachments view, we created the xwiki-webdav-plugin ( http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-webdav-plugin/) which is responsible for providing webdav urls given document attachments. The actual editing of attachments is carried either via foxwiki (if you are running firefox) or via IE's built-in capabilities of openning webdav urls with native editors. * As mentioned above we had to revamp foxwiki to make it easy for us to integrate xwiki-webdav in the xwiki-ui. But we have the added bonus of all previous foxwiki features too :). Presently foxwiki is configured as a maven project (http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-clients/FoXWiki/) and it can be built and tested pretty easily (refer to README). * A fully configured test server is located at http://91.121.237.216/xwiki/bin/view/Main/ (along with instructions) so that you may test out xwiki-webdav:xwiki-ui integration yourself :) * So altogether we have 4 projects [xwiki-rootwebapp],[xwiki-webdav],[xwiki-webdav-plugin],[foxwiki] and follwing is our task break down for days to come : 1. Cleanup the source code and make it upto xwiki standards (2 more days work remaining, need to add javadoc comments). 2. Create a maven build (Done). 3. Discuss proper places to land these projects (on trunk). 4. Send a vote to move these projects into trunk. 5. Create JIRA projects as necessary. (i'm not sure if we would have four separate projects or not) 6. Release a first version. * Now to start with, we need to discuss where to place these projects under the main source tree, following are some initial suggessions but i'm not certain about these :) [xwiki-rootwebapp] : No Idea. [xwiki-webdav] : http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-webdav [xwiki-webdav-plugin] : http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-plugins/trunk/xwiki-webda… be we should change the name ?) [foxwiki] : http://svn.xwiki.org/svnroot/xwiki/foxwiki WDYT ? - Asiri

2 3

[xwiki-devs] jgroups is not downloaded ?
by rssh＠gradsoft.com.ua 30 Sep '08

30 Sep '08

------------------------------------------------------------------------------- Test set: com.xpn.xwiki.XWikiTest ------------------------------------------------------------------------------- Tests run: 14, Failures: 0, Errors: 14, Skipped: 0, Time elapsed: 2.609 sec <<< FAILURE! Hmm - looks like maven does not get jgroups. testCreatorAfterDocumentCopy(com.xpn.xwiki.XWikiTest) Time elapsed: 1.077 sec <<< ERROR! java.lang.NoClassDefFoundError: org/jgroups/blocks/RpcDispatcher$Marshaller at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:637) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) at java.net.URLClassLoader.access$000(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:212) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:323) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:268) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2444) at java.lang.Class.getDeclaredMethods(Class.java:1808)

2 2

Re: [xwiki-devs] [xwiki-notifications] r13076 - in watch/trunk: . component component/src component/src/main component/src/main/java component/src/main/java/org component/src/main/java/org/xwiki component/src/main/java/org/xwiki/watch component/src/main/java/org/xwiki/watch/component component/src/main/java/org/xwiki/watch/component/contextualizer component/src/main/resources component/src/main/resources/META-INF component/src/main/resources/META-INF/plexus
by Vincent Massol 29 Sep '08

29 Sep '08

Hi Anca, Very good! I'm real happy you're jumping in the bandwagon on this :) Just one note: In the future the way to expose a component in velocity will be done differently. See http://tinyurl.com/3qu923 in case you haven't followed the discussion. This way of doing it should probably be removed once we have the new way. This is the current right way though :) Thanks -Vincent On Sep 29, 2008, at 2:14 PM, lucaa (SVN) wrote: > Author: lucaa > Date: 2008-09-29 14:14:31 +0200 (Mon, 29 Sep 2008) > New Revision: 13076 > > Added: > watch/trunk/component/ > watch/trunk/component/pom.xml > watch/trunk/component/src/ > watch/trunk/component/src/main/ > watch/trunk/component/src/main/java/ > watch/trunk/component/src/main/java/org/ > watch/trunk/component/src/main/java/org/xwiki/ > watch/trunk/component/src/main/java/org/xwiki/watch/ > watch/trunk/component/src/main/java/org/xwiki/watch/component/ > watch/trunk/component/src/main/java/org/xwiki/watch/component/ > DefaultWatchService.java > watch/trunk/component/src/main/java/org/xwiki/watch/component/ > WatchService.java > watch/trunk/component/src/main/java/org/xwiki/watch/component/ > contextualizer/ > watch/trunk/component/src/main/java/org/xwiki/watch/component/ > contextualizer/WatchServiceContextualizer.java > watch/trunk/component/src/main/resources/ > watch/trunk/component/src/main/resources/META-INF/ > watch/trunk/component/src/main/resources/META-INF/plexus/ > watch/trunk/component/src/main/resources/META-INF/plexus/ > components.xml > Modified: > watch/trunk/pom.xml > Log: > XWATCH-230: Prepare build for the creation the component > * created the "component" module in Watch > * created a WatchService component, visible in velocity context > (through the VelocityContextInitializer), with no functions for the > moment. >

2 1

[xwiki-devs] [Rendering] Multi syntax support configuration
by Vincent Massol 29 Sep '08

29 Sep '08

Hi, I'm committing the following change to make it easier for users to try the new syntax: * There's a property in xwiki.cfg to enable different syntaxes: # [Since 1.6RC1] Defines the list of supported syntaxes # Available syntaxes are: # xwiki/1.0, xwiki/2.0, confluence/1.0, jspwiki/1.0, creole/1.0, # mediawiki/1.0, xhtml/1.0, twiki/1.0 xwiki.rendering.syntaxes = xwiki/1.0, xwiki/2.0 * It defaults to XWiki Syntax 1.0 and 2.0 (because the other syntaxes are not quite ready) * I'm adding a new XWiki API: XWiki.getConfiguredSyntaxes() * Any user will be able to see the list of configured syntaxes in wiki edit mode Please shout quickly if you don't think this is a good idea. Thanks -Vincent

2 2

[xwiki-devs] [Summary] Bug fixing week result - Week of the 22/09/2008
by Vincent Massol 29 Sep '08

29 Sep '08

Hi devs, Here's the result of our bug fixing week (31 bugs fixed). Congrats to the following XWiki committers who have participated: Vincent - 8 Thomas - 5 Anca - 4 Sergiu - 4 Artem - 4 Jerome - 6 Out of these,a very special thanks to the committers who fixed *existing* jira issues (unlike myself since I have only fixed bugs on what I was working on, i.e. rendering). Let's hope even more committers participate next time (we are about 15 committers and 6 have participated). Note that we should continue to do our Wednesday bug fixing day too, starting next week. Issues fixed: [XWIKI-2691] Support nesting styles (bold, italic, etc) in the new rendering [XAWM-88] WikiManager plugin doesn't works in sub wikis. [XWIKI-2694] Top level element should be separated by 2 new lines in the XWiki Syntax renderer [XWIKI-2699] Underline elements are not recognized when saved [XWIKI-2700] XHTMLRenderer does not escape XML entities [XWIKI-2702] api.Document#getObjects(class, key, value) don't works for non string properties [XWIKI-2701] Events renderer does not escape attributes [XWS-163] The new XWS Administration interface breaks the underlying XE administration interface [XWIKI-2690] Doing Save and Continue when editing a section displays full content in editor [XWIKI-2706] The (% style="" %) syntax is applied to all items afterwards [XWIKI-2709] XHTMLRenderer does not output span element around wikicreatelink links [XSALBATROSS-39] There is no proper CSS for <blockquote> in the Albatross skin [XSTOUCAN-51] There is no proper CSS for <blockquote> in the Toucan skin [XWS-55] In a photo galerie the "Uploaded on" sometimes overlap its picture box [XE-310] XWiki.Treeview needs programming rights [XWIKI-2712] Some info is missing in object diff when object delete is present [XWIKI-2530] Problem with label when comparing 2 versions having a comment change [XWS-166] When deleting a photo gallery, activity events are generated for each deleted picture [XWS-168] Activity event displayed on space dashboard when deleting a photo gallery present a link to the deleted gallery [XWIKI-2060] Rights Management interface should support adding groups into groups [XWATCH-223] Article titles should be escaped for wiki syntax when printed in the press review [XWATCH-187] WatchCode.LoadingStatus produces too many empty versions of WatchCode.WatchVersionClass [XWATCH-225] Limit does not work for press review macros [XWIKI-1983] "Version $request.rev2" displayed in the version compare interface [XWIKI-2648] Chart Plugin fails in XE 1.6M1 [XSKINX-7] Cache policy: forbid does not actually prevent caching [XSKINX-5] JS should be forced to UTF-8 [XSKINX-6] Language-dependent extensions should be cached separated [XSALBATROSS-40] Fix upper greek list support [XSTOUCAN-52] Greek Numbered lists do not work anymore [XWATCH-168] Search field needs a click on the 'OK'-button, 'Enter' is not working More details at http://tinyurl.com/3n8jnt Unfortunately we're still off by 14 bugs in the past 3 months. We need to continue the effort. Thanks -Vincent

2 2

[xwiki-devs] Not Able To See The Comment's
by Prathap Pandian 29 Sep '08

29 Sep '08

Hi, I have add the comment from the inline form (/xwiki/bin/inline/XWiki/). Now i can't able to see it any where. Can any one tell me we can i able to see the comment. -- Prathap

1 1

[xwiki-devs] building XWiki
by [Ricardo Rodriguez] Your EPEC Network ICT Team 28 Sep '08

28 Sep '08

Hi all, Please, allow me a simple question or, much better, to confirm if I am well understanding the process. Once I get Maven installed and working, I understand that now it is possible to build the whole XWiki modules. But this will be also possible by installing an IDE as Eclipse. Maven is always required for this process, but by using Subclipse, M2Eclipse and WTP the whole process can be done from within Eclipse. Please, is this correct? Thanks! Best, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

3 6

[xwiki-devs] Fwd: [ANN] Maven Reactor Plugin 1.0 Released
by Vincent Massol 28 Sep '08

28 Sep '08

fyi, it's now released. -Vincent Begin forwarded message: > From: Dan Fabulich <dfabulich(a)apache.org> > Date: September 28, 2008 3:48:46 AM CEDT > To: announce(a)maven.apache.org, Maven Users List <users(a)maven.apache.org > > > Cc: Maven Developers List <dev(a)maven.apache.org> > Subject: [ANN] Maven Reactor Plugin 1.0 Released > Reply-To: "Maven Users List" <users(a)maven.apache.org> > > > The Maven team is pleased to announce the release of the Maven > Reactor Plugin, version 1.0. > > This plugin can build a subset of interdependent projects in a > reactor. It should be useful in large reactor builds that include > irrelevant stuff you're not working on. > > http://maven.apache.org/plugins/maven-reactor-plugin/ > > The Reactor plugin is normally run from the command line, like this: > > * reactor:resume resumes a reactor at a certain point (e.g. when it > fails in the middle) > Example: mvn reactor:resume -Dfrom=bar > > * reactor:make builds a project X and all of the reactor projects on > which X depends > Example: mvn reactor:make -Dmake.folders=foo,bar > > * reactor:make-dependents builds a project X and all of the reactor > projects that depend on X (the reverse of reactor:make) > Example: mvn reactor:make-dependents -Dmake.folders=foo,bar > > * reactor:make-scm-changes build all reactor projects that you > personally have changed (according to SCM) and all reactor projects > that depend on your changes > Example: mvn reactor:make-scm-changes > > This is the first release of the Maven Reactor Plugin. > > Enjoy, > > -The Maven team > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe(a)maven.apache.org > For additional commands, e-mail: users-help(a)maven.apache.org >

1 0

[xwiki-devs] Specifications for Testing the new WYSIWYG editor
by Vincent Massol 27 Sep '08

27 Sep '08

Hi, Since we really need to have automated tests for the new WYSIWYG from the onset here are some ideas I'd like to have: 1) It should use Selenium and we need to run it on different browsers (FF2, FF3, IE6, IE7, IE8 minimum). 2) We need to develop a complete DSL for entering data in the editor (typeText, moveCursorLeft, clickBold, insertLink, etc). These commands sent in the test should be independent of the editor technology, which means I should be able to run the same test in the current TinyMCE editor or in the new GWT editor or in any future editor. This is important so that we can capitalize on our editor test suite. Note: The goal is not to run the tests on the Tiny MCE editor (although that would be possible) but more to ensure that our tests are as solid as possible for the future and as easy to write as possible. 3) As a consequence the asserts done in the test should be on the generated XHTML (i.e. including the HTMLCleaner for the GWT editor) since otherwise there would be too many differences between editors. 4) Each editor should have its test suite where it can specify which test to run (since some features are available in the new GWT editor for ex but not in the tinyMCE one) 5) Writing a new test should take less than 5 minutes without even the need to run the test in the editor to prepare it. This means the DSL should be simple and expressive. For example here's an example of a test: testVerifyCanDeleteList() { typeText("a"); selectBulletedList(); moveCursorLeft(); typeBackspace(); assertXHTML("<p>a</p>"); } Note: This test is not taken at random since it currently doesn't pass ;) 6) Tests must be deterministic (i.e each action should verify that the action has worked before continuing. For example a typeText should have a wait on the type text in the page) WDYT? Thanks -Vincent

2 2