xwiki-devs December 2009

xwiki-devs@xwiki.org

32 participants
100 discussions

[xwiki-devs] [Idea] A generic document converter (xwiki-office-converter) on top of xwiki-officeimporter

by Asiri Rathnayake

Hi Devs & Users, With the new refactoring of officeimporter module, it's possible to implement a generic office document converter on top of xwiki-officeimporter. By a "document converter" I meant an xwiki application where you can upload a .doc file and get it converted to a .pdf, .odt etc. Supported formats will be those mentioned in http://artofsolving.com/opensource/jodconverter/guide/supportedformats and few more Office2007 formats. Would this application be a good addition to XWiki? Thanks. - Asiri PS: It would take about 2-3 days to fully implement and test the application.

14 years, 9 months

[xwiki-devs] [Fwd: [Obo-discuss] CFP: The Future of the Web for Collaborative Science (FWCS 2010) at WWW'10]

by Your EPEC Network ICT Team

They are not using XWiki... yet! Cheers, Ricardo -------- Original Message -------- Subject: [Obo-discuss] CFP: The Future of the Web for Collaborative Science (FWCS 2010) at WWW'10 Date: Fri, 11 Dec 2009 16:10:54 +0000 From: Jun Zhao <jun.zhao(a)zoo.ox.ac.uk> Reply-To: obo-discuss(a)lists.sourceforge.net To: undisclosed-recipients:; [apologies for cross-posting] ================================================================================================= CALL FOR PAPERS - International Workshop on The Future of the Web for Collaborative Science 2010 ================================================================================================= The First International Workshop on The Future of the Web for Collaborative Science (http://esw.w3.org/topic/HCLS/WWW2010/Workshop), co-located with WWW'10, April 27 or 28 2010, Raleigh, NC, USA --------------------------------------------------- INTRODUCTION The Web was originally invented with the physics community in mind, but rapidly expanded to include other scientific disciplines, in particular the health care and life sciences. By the mid 1990s the Web was already being used to share data by biomedical professionals and bioinformaticians. The Web continues to be immensely important to these fields, however use cases have expanded considerably. Researchers are now looking to share extremely large data sets on the Web, extract insights from vast numbers of papers cross sub-disciplines, and use social networking tools to aggregate data and engage in scientific discussion. Furthermore, individuals are beginning to store their medical records online, and some are sharing their genetic makeup in a bid to find others with a similar profile. These use cases are pushing the boundaries of what is currently possible with the Web. This half-day workshop will present how scientists are currently using the Web, and discuss the functionality that is required to make the Web an ideal platform for both cutting edge scientific collaboration and for managing health care related data. The goals of this workshop are the following: * Foster innovation in applying the latest web technologies to collaborative HCLS * Explore HCLS specific requirements for collaborating on the web, e.g. trust, privacy, intellectual property, knowledge management, and the scale and diversity of data * Learn about the latest developments in data modeling, tools and technologies for web-based collaborative science * Bridge communication and knowledge transfer between the HCLS and web communities --------------------------------------------------- TOPICS FOR PAPER SUBMISSION We would encourage submission of papers covering the following topics: * Web 2.0 applications for large, heterogeneous and complex data sets * Models for collaborative scientific annotations * Tools and applications for aggregating information across web sites * Provenance, attribution, trust, and intellectual property * Policy for data access, sharing, and anonymization We seek three kinds of submissions: * Full technical papers: up to 10 pages * Short technical and position papers: up to 5 pages * Demo description: up to 2 pages --------------------------------------------------- SUBMISSIONS Submitted papers will be refereed by at least three members the Program Committee. Accepted papers will be published on the workshop web site. All submissions must be formatted using the WWW2010 templates (http://www2010.org/www/authors/submissions/formatting-guidelines/). The address for the online submission system will be published shortly. --------------------------------------------------- IMPORTANT DATES: * Submission deadline- February 15, 2010 * Notification of acceptance - March 8, 2010 * Camera-ready version - March 22, 2010 * Workshop date - April 27 or 28, 2010 --------------------------------------------------- Workshop Chairs Jun Zhao, Oxford University Kei Cheung, Yale University M. Scott Marshall, Leiden University Medical Center / University of Amsterdam Eric Prud'hommeaux, W3C Susie Stephens, Johnson & Johnson Pharmaceutical Research & Development --------------------------------------------------- Programme Committee * Christopher Baker, University of New Brunswick * John Breslin, GUI Galway * Simon Buckingham Shum, Open University * Annamaria Carusi, Oxford University * Helen Chen, Agfa Healthcare * Paolo Ciccarese, Harvard University * Tim Clark, Harvard Medical School * Anita de Waard, Elsevier * Michel Dumontier, Carleton University * Lee Feigenbaum, Cambridge Semantics * Timo Hannay, Nature * William Hayes, BiogenIdec * Ivan Herman, W3C * Vipul Kashyap, Cigna * Nikesh Kotecha, Stanford University * Phil Lord, University of Newcastle * Robin McEntire, Merck * Parsa Mirhaji, University of Texas * Mark Musen, Stanford University * Vit Novacek, DERI * Alex Passant, DERI * Elgar Pichler, AstraZeneca * Rosalind Reid, Harvard University * Patrick Ruch, University of Applied Sciences Geneva * Daniel Rubin, Stanford * Matthias Samwald, DERI, Ireland // Konrad Lorenz Institute for Evolution and Cognition Research, Austria * Susanna Sansone, EBI * Nigam Shah, Stanford University * Amit Sheth, Wright State University ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Obo-discuss mailing list Obo-discuss(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/obo-discuss

14 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r25956 - in platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki: api doc

by Asiri Rathnayake

Hi Sergiu, > /** > - * @return can current user restore this document from recycle bin > + * Check if the current user has the right to restore the document. > + * > + * @return {@code true} if the current user can restore this document, > {@code false} otherwise > * @throws XWikiException if any error > */ > - public boolean canUndelete() throws XWikiException > + public boolean canUndelete() > { > This looks like a public API change. You have introduced a checkstyle error (unused @throws tag) which I fixed since the build was failing. Not sure if the change of the API is a big deal or not in this case. - Asiri

14 years, 9 months

[xwiki-devs] [VOTE] URLs and encoding

by Sergiu Dumitriu

Hi devs, The short version: Should we always use UTF-8 for encoding and decoding URLs, regardless of the wiki encoding, for better compliance with web standards? The long version: By definition, URLs can only contain ASCII characters, everything else must be converted to their corresponding bytes and escaped as %XY escapes. The problem is that "their corresponding bytes" implies a charset + encoding, and no specification *enforces* a specific pair, although it is *recommended* to use Unicode + UTF8, to comply with the modern tendency of the web in general. Traditionally, XWiki has been using the same encoding as the configured global wiki encoding for the URLs, which means that before 1.9, when we switched to UTF8 as the default wiki encoding, all URLs were using the ISO-8859-1 encoding. Since the switch to UTF-8, URLs are also using the UTF-8 encoding by default, although the wiki encoding can be changed. Now, since 2.1, a bugfix accidentally changed the behavior, so that parsing back URLs always uses the UTF-8 encoding, even though composing URLs continues to use the wiki encoding. This is a bug, which prevents changing the encoding to anything other than UTF-8, and it should be fixed. Now, we have two options: 1. Reintroduce the old behavior, so that URLs always use the wiki encoding. This is a direct bugfix. 2. Also change the encoding part, so that UTF-8 is always used. This is an improvement, going towards better compliance with web standards. Personally I think that the second option is the better one, but it requires a vote, since it has a few drawbacks. Advantages: + better compliance with web standards, since UTF-8 is the recommended encoding for URLs (although not imposed) + support for a wider range of document names, since UTF-8 allows full-unicode document names, while ISO-8859-1 limits names to latin1 characters + better support from browsers, since entering accented characters directly in the address bar encodes the URL sent to the server using UTF-8, and decoding the URL also assumes UTF-8; this means that a document named "é" will be printed as .../view/Main/%E9 and will have to be entered the same way in the address bar when ISO-8859-1 is used, and as .../view/Main/é when UTF-8 is used Drawbacks: - by default Tomcat uses ISO-8859-1 as the encoding for URLs, so the Tomcat configuration will have to be changed as in http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Encoding#HTomcat - some existing bookmarks will not work anymore once the encoding is changed +1 for option 2 from me, -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r25938 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/util

by Vincent Massol

Hi Sergiu, On Dec 26, 2009, at 6:48 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-12-26 18:48:37 +0100 (Sat, 26 Dec 2009) > New Revision: 25938 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/util/ > Util.java > Log: > XWIKI-4704: Always use UTF-8 for URL encoding > Done. Could we have some comments below to explain why we're using UTF8 with some link pointing to the RFC you mentioned? I think it would help remember it for the future. Thanks -Vincent > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > util/Util.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/util/ > Util.java 2009-12-26 00:29:36 UTC (rev 25937) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/util/ > Util.java 2009-12-26 17:48:37 UTC (rev 25938) > @@ -29,8 +29,6 @@ > import java.io.Reader; > import java.io.StreamTokenizer; > import java.io.StringReader; > -import java.net.URLDecoder; > -import java.net.URLEncoder; > import java.util.ArrayList; > import java.util.Date; > import java.util.HashMap; > @@ -46,6 +44,7 @@ > import javax.xml.parsers.DocumentBuilderFactory; > import javax.xml.parsers.ParserConfigurationException; > > +import org.apache.commons.httpclient.util.URIUtil; > import org.apache.commons.io.FileUtils; > import org.apache.commons.io.IOUtils; > import org.apache.commons.lang.ArrayUtils; > @@ -67,7 +66,6 @@ > import org.xml.sax.SAXException; > import org.xwiki.container.Container; > > -import com.novell.ldap.util.Base64; > import com.xpn.xwiki.XWikiContext; > import com.xpn.xwiki.XWikiException; > import com.xpn.xwiki.monitor.api.MonitorPlugin; > @@ -759,7 +757,7 @@ > public static String encodeURI(String text, XWikiContext context) > { > try { > - return URLEncoder.encode(text, > context.getWiki().getEncoding()); > + return URIUtil.encodeWithinQuery(text); > } catch (Exception e) { > return text; > } > @@ -775,17 +773,7 @@ > public static String decodeURI(String text, XWikiContext context) > { > try { > - // Make sure + is considered as a space > - String result = text.replaceAll("\\+", " "); > - > - // It seems Internet Explorer can send us back UTF-8 > - // instead of ISO-8859-1 for URLs > - if (Base64.isValidUTF8(result.getBytes(), false)) { > - result = new String(result.getBytes(), "UTF-8"); > - } > - > - // Still need to decode URLs > - return URLDecoder.decode(result, > context.getWiki().getEncoding()); > + return URIUtil.decode(text); > } catch (Exception e) { > return text; > }

14 years, 9 months

[xwiki-devs] [Proposal][Model] String representation for Entity References: Escapes + breakages

by Vincent Massol

Hi, Since I'm writing the new Model part for Entity References (document and attachment for now but we can imagine objects and object properties later on). I'd like to propose 2 things: * A syntax for escaping special characters in references * Some changes to the supported reference syntax Escapes ======= I'd like to propose using the backslash (i.e. \ ) character. For example: "a page name with \: some \. special \@ characters" Rationale: * it's a well known char for escapes, all devs know about it * using "~" would be confusing with the wiki syntax Known issue: * when in the velocity macro you need to be careful to use a double escape since \ is the velocity char for escaping. Ex: {{velocity}} [[label>>special\\@page-name]] {{/velocity}} Breakages ========= Since we'll know have a generic factory/serializer for all entity types we need to make the syntax more consistent. This means that the following syntax will not work anymore: * ex: "wiki:page". This would be interpreted as a document with a page of "page" and a space of "wiki:" * When using the "default" factory, only default values would be used (right now it's a mix between current doc values and default values). Suggested defaults: "xwiki" for Wiki, "XWiki" for space, "WebHome" for page and "" for attachment name. Note that one idea is to make these defaults configurable in the xwiki config file * It's hard to know for sure but we certainly have various other inconsistencies that exist now when using special reserved chars in references We have 2 options here: * Make XE 2.2 not backward compatible for some references. Advertise it in the release notes and explain to users how they should change their names if they use "exotic" names * Create an automatic converter, for example as a database migrator that would read all documents in the wiki, call getLinks() on each document, send the links to the old parser (would need to extract it somewhere and ensure it behaves as now) and send the link to the new parser and compare. If there's a difference, escape the char and save. This would also need to be done for document parent references, the backlink table and all object properties that allow wiki syntax or velocity. Note that it wouldn't fix any generated name (using velocity for ex). The automatic converter option is really hard to do so I'm leaning more towards the first solution. That would need to be properly handled since it could potentially cause quite a few broken links. WDYT? Thanks -Vincent

14 years, 9 months

[xwiki-devs] Merry Christmas and Happy New Year 2010

by Vincent Massol

Hi everyone, Just a quick note to wish everyone in the XWiki project very happy festivities and a happy next year for 2010. The XWiki project has seen exciting times in 2009 as described on: http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiIn2009 Let's all make 2010 even better :) Take care, -Vincent

14 years, 9 months

[xwiki-devs] An idea about XE upgrade.

by Zhaolin Feng

In current implementation, for a successful upgrade, I have to carefully export: 1. All the pages that I've created 2. All the user profile pages. 3. *.WebPreferences, XWiki.XWikiPreferences. 4. XWiki.XWikiAllGroup, XWiki.AdminGroup and pray, these pages are compatible with a new version of XE. As I see, the main headache is that the information about user, group, preferences spreads in a lot of pages. Why isn't there a central database to store them, so updating will be much simpler? -- -- Zhaolin Feng -- www.mapbar.com -- Currahee! We stand alone together!

14 years, 9 months

[xwiki-devs] [VOTE] new UI for import

by Jerome Velociter

Hi all, Caty made some cool proposals based on the work I've started on a new import UI ( http://jira.xwiki.org/jira/browse/XWIKI-4692 ). You can check them out here : http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ImporterProposal My preference goes for A. I like C too. Which one do you prefer? Thanks, Jerome.

14 years, 9 months

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.1.1 Released

by Jean-Vincent Drean

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.1.1 Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Important bug fixes since 2.1: * XWIKI-4575 : Horizontal ruler breaks the display of the WYSIWYG menu bar and toolbox * XWIKI-4681 : Attachments deletion has no effect before a restart * XWIKI-4679 : Can't select the macro after inserting it (WYSIWYG) * XWIKI-4688 : Macro disappears after editing its properties (WYSIWYG) For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise211 http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM211 Thanks -The XWiki dev team

14 years, 9 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2009