xwiki-devs June 2007

xwiki-devs@xwiki.org

31 participants
65 discussions

Votes and oppinions on Google Docs integration specifics

by Radu Danciu

Cheers guys! During my research of the way Google does stuff with their Gdata Protocol, I've come across some decisions that have to be made (more like priorities - what should work first and what to improve later). First off - means of authentication. In order to use gdata, you need a google account (gmail counts as one). As an alternative, you can, upon invitation, view a document without having to log in (as stated here<http://docs.google.com/support/bin/answer.py?answer=47597&topic=9378>). That would be a good way of interaction with visitors who don't have editing permissions (as of yet I've not found a way to send invitations using the API, but there should be one... I hope). Then comes the account part: - A wiki can request that each editor use his own account to edit. That would mean: - + being able to collaboratively edit documents (the service allows for multi-user edit) <still requires invitation> - - require a download to my account, edit, send back to wiki kind of work flow (much like download to desktop, edit, upload) !! I might be wrong on this, needs further research since there is the collaborative side of things !! - more + / - to come (if anybody can think of other things to list here, please do) - Any one wiki instance admin can create a google account and use it as a generic wiki acount. That would mean: - - not being able to edit collaboratively (might not even be able to edit different documents at the same time - not sure if Google allows multiple log-ins per account) - + edit in place - - limit of 200 spreadsheets / 5000 documents or images per account (would be ok for a small to medium sized wiki, but a larger one would seriously suffer especially when it comes to spreadsheets) - more + / - to come (again, any ideas are welcome additions to the general picture) I'd like to take this occasion to ask you, the devs (and users) of xwiki what you would like to see from Google Docs Integration (prioritize). I'd really appreciate knowing what the expectations are. Also, any upsides or downsides to the issue of authentication are welcome into discussion . Another issue is the fact that the gdata api provided by google will have to be integrated into the xwiki trunk (I'd like to know how this should be done). If possible, take some time to read the references bellow and others related, and comment upon what should be done and how. Thank you for your time and patience, Radu Danciu References: http://docs.google.com/support/bin/answer.py?answer=47597&topic=9378<http://docs.google.com/support/bin/answer.py?answer=47597&topic=9378><http://docs.google.com/support/bin/answer.py?answer=47597&topic=9378> http://docs.google.com/support/spreadsheets/bin/answer.py?answer=37603 http://docs.google.com/support/bin/answer.py?answer=37560&topic=8613 http://code.google.com/apis/gdata/client-java.html http://en.wikipedia.org/wiki/Google_Docs_&_Spreadsheets

18 years

Building xwiki+gdata

by Radu Danciu

I'm running into the following build error upon trying to ant standalone the xwiki trunk along with gdata jars and my classes for google docs: [javac] /tmp/clover50747.tmp/src50748.tmp/com/xpn/xwiki/gwt/api/client/GdataAttachmentListInteraction.java:10: generics are not supported in -source 1.4 [javac] (try -source 1.5 to enable generics) [javac] private Map<String, ListEntry> entriesCached; [javac] ^ [javac] 1 error Sergiu hinted that it's because of Java 1.4 (Gdata needs at least 1.5). How do I get over this? Also, what modifications should i make to pom.xml in order to add some jars to the project? (gdata api jars - originally sources, that have to be built into jars) Thanks for your time, Radu Danciu

18 years

Query

by evelyne24＠gmail.com

Hello, I have problems making a query to retrieve from the database all the objects that are from a certain class (e.g "TryClass") and of a certain type as well (e.g "StaticListClass"). Can anyone give me a hint please? Thank you very much. Evelina Slatineanu

18 years

Testing Ideas for XWiki

by Vincent Massol

Hi, Here's a list Catalin and I came up with while brainstorming about ideas around testing for XWiki. Please feel free to comment, argue, suggest new ideas, etc. 0) Agree that we want to have our functional tests written in Java. Vs using Selenium IDE only Pros: - DSL -> easy to write and low maintenance (if a UI changes it's fixed in one place) - ability to write more complex tests with branch control (if, loop, etc) - ability to write tests easily (try creating a test that types some content in our Tiny MCE editor and you'll understand that part ;-)) - run automatically as part of our build/CI Cons: - require a minimal knowledge of Java. Thus it's going to prevent us from having non technical people write functional tests for us. I'm currently 100% convinced that our Java choice is right but I know Ludovic isn't fully convinced which is why I'm listing this point here to see what others think. 1) Finish setting up our Java functional test fwk. Goals: - make it as easy as possible to use. - make it low maintenance (ie tests shouldn't fail often and if some UI is changed it should be very easy to fix the tests) Tasks: - Continue improving our DSL for testing. Specifically add the ability to test over several skins and create one DSL per skin. - Add DSL methods for asserting the rendered HTML (cf Catalin's tests in http://jira.xwiki.org/jira/browse/XWIKI-1207) 2) Add clover support in the build to assert Test Coverage (TC) We need this to evaluate easily what we are not testing. It should report on both unit and functional tests execution. Note: This is easy to do with the nice Clover plugin for m2 ;-) (I'm the author of that plugin) 3) Add functional tests to cover 30% of the code under test. This is a first milestone that we should aim towards. For this we need to have 2) to see where we stand. Our target goal should be in the range of 60-70% TC. For my past experience this is a good ballpark figure and having this results in: a) well tested code and confidence something new doesn't break what exists. This is very interesting for us in the 1.x time frame as we don't want to add regressions to 1.0. But also it gives us greater confidence for redesigning internal parts of XWiki for implementing the 2.0 architecture b) the ability to release in production at each release (provided new features get tests added when they're added) 4) Explore in-VM testing The idea is to have several VM (Virtual Machines) running different OSes for example (Windows, linux, Mac) and a combination of Databases (Oracle, MySQL, PostGre). You run the XWiki maven build in them so that the tests get executed in VM. This allows 2 things: a) test for different environment. For example this tests our start/ stop scripts, our database setups b) this allows more complex tests to be written like: virtual wikis c) this allows to implement hard to write tests like the "add attachment" one. For this you need the attachment to be on your file system. With a VM you control the full setup of the VM and you can restore the VM at each run 5) create a test plan listing tests to be written We need this written in JIRA. This goes with 3). 6) Explore using Reality QA This is a nice tool/service created by Patrick Lightbody (who's a friend). See http://www.realityqa.com/screencasts/realitycheck_tutorial/ RealityCheck.htm to see it in action. Right now the main issue is that it won't run selenium tests written in Java but Patrick says it's coming: http://community.realityqa.com/thread.jspa?threadID=1010 The other thing that could be nice is the ability to upload our app inside their VM: http://community.realityqa.com/thread/1011 (but we can host our VMs to start with). What Reality QA buys us is the ability to run all our tests on all platforms/browsers. 7) Improve the maven build For example: - ability to run the app on a defined port so that it doesn't interfere with an already running xwiki instance - stop the container when a test fails 8) Finish setting up our CI tool Tests are pretty useless without CI. I'm working on setting up TeamCity. I'm having some issues that I'm debugging with jetbrains (at first glance seems caused by ObjectWeb SVN). Catalin will work on some of these points as part of GSOC (http://www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ FunctionalTestSuite). We haven't decided yet which points he'll work on but at least he'll do/help on the following: 1, 3 and 5. 3 and 5 being the most important items. WDYT about all these? Thanks -Vincent

18 years

Re: [xwiki-commits] r3571 - in xwiki/trunk/application-test: . src/test/it/com/xpn/xwiki/it/framework

by Vincent Massol

On Jun 8, 2007, at 9:34 AM, Catalin Hritcu wrote: > Author: hritcu > Date: 2007-06-08 09:34:30 +0200 (Fri, 08 Jun 2007) > New Revision: 3571 > > Modified: > xwiki/trunk/application-test/pom.xml > xwiki/trunk/application-test/src/test/it/com/xpn/xwiki/it/ > framework/AbstractXWikiTestCase.java > xwiki/trunk/application-test/src/test/it/com/xpn/xwiki/it/ > framework/AlbatrossSkinExecutor.java > Log: > Removed dependency on XMLUnit. Just to explain: I've agreed with Catalin to remove it because the code we get is HTML (not XHTML) and xmlunit requires valid XML so the combo wasn't working that great. It's also simpler just to use Selenium's internal xpath feature. -Vincent

18 years

An unorthodox way of developing with Xwiki

by François Déchelle

Hi, I'm currently working on the development of a portal based on Xwiki, and may be what I am using to deploy groovy code could be helpfull. You can find the code at: https://protactinium.pps.jussieu.fr:12345/websvn/listing.php?repname=EDOS&p… The whole stuff is based on autotools (automake/autoconf) and curl. The very simple configure script builds a property file that stores the Xwiki server name, port, username, password. There are then bash scripts that use 'curl' for login in, uploading and downloading Xwiki pages. The pages are stored as plain text files with .xwiki extension. I edit the pages using emacs and groovy-mode (syntax coloring, indentation, parenthesis checking...). The groovy-mode Emacs lisp file can be found on http://groovy.codehaus.org/Emacs+Plugin Once the pages edited and saved in emacs, I upload them in Xwiki using 'make upload' and test them using firefox. This can of course be done directly from Emacs with M-compile. Thanks to the fact that automake/autoconf support running configure in a different directory than the sources (i.e. the Xwiki documents), I can deploy simultaneously on 2 Xwikis, one running localy where I test the code, and another one running a more stable version. This is done by creating 2 'build' directories and running configure with --srcdir=SRCDIR argument. I know it is not in any case the standard way of developing in Xwiki, but I find it helpfull. If it can be of any help... A question now: is it possible to define Xwiki classes the same way? Right now, I define my classes using the web interface, but if I am curious to know if it is possible to do it textually? François

18 years

Tooltip usage.

by Arnaud Thimel

I'm trying to use tooltips. Since the bug http://jira.xwiki.org/jira/browse/XWIKI-977 has been closed, I thought I can use it but I can't get it work. I have this code in my page : $xwiki.addTooltipJS() $xwiki.addTooltip("htmlText", "tooltip") The generated HTML code is like this : <script type="text/javascript" src="/xwiki/skins/albatross/ajax/wzToolTip.js"></script><p class="paragraph" /> <span class="tooltip_span" onmouseover="this.WIDTH='300'; return escape('tooltip');">htmlText</span><p class="paragraph" /> Am I doing something wrongly ? Thanks, Arno.

18 years

Retrieve data for multiple select

by evelyne24＠gmail.com

Hello, How can I make a query to retrieve data if the user has chosen "Multiple Select"? Until now I only made queries using StringProperty, but Sergiu told me that with multiple select, data are kept on separate rows, so I tried StringListProperty and ListProperty but with no success. Anyone, an ideea, please? Thank you.

18 years

Empty dates & imports.

by Arnaud Thimel

Hi all, I have a problem with imports. I have some objects that I need to export that contains empty dates. The property "emptyIsToday" is set to "0" and the field value is empty. Exported file is like : Field declaration : [...] <dateDetection> <name>dateDetection</name> <prettyName>Date de détection</prettyName> <unmodifiable>0</unmodifiable> <size>10</size> <dateFormat>dd/MM/yyyy</dateFormat> <emptyIsToday>0</emptyIsToday> <customDisplay></customDisplay> <validationRegExp></validationRegExp> <tooltip>format (jj/mm/aaaa)</tooltip> <number>4</number> <validationMessage></validationMessage> <classType>com.xpn.xwiki.objects.classes.DateClass</classType> </dateDetection> [...] Value : [...] <property> <dateDetection></dateDetection> </property> [...] So all seems normal in exported file. Then when I do my import and go to see the object, it is valued with the current's date : Date de détection: 06/06/2007 Any idea or suggestion ? Regards, -- Arnaud Thimel Société Code Lutin - http://www.codelutin.com

18 years

GSoC : IDE Editor Integration

by tharindu jayasuriya

Hi all, I'm working on developing a plug-in for eclipse that would allow XWiki to integrate seamlessly with the development environment (as part of GSoC2007). I have investigated TimTam which is a similar plug-in. The major issue i need to clarify is what sort of integration would be necessary, displaying XWiki pages within a browser widget inside eclipse environment seems quite straight forward, but this would simply mean that I have eliminated the requirement for an external browser. On the other hand TimTam provides a tree navigation function which is quite handy; is it possible to have this kind of a functionality with XWiki ? or else, is there a better way to do this ? The related JIRA issue is, http://jira.xwiki.org/jira/browse/XWIKI-1323 Regards, - Tharindu.

18 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2007