xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Ideas/Proposal] Thoughts on the Wiki Import feature for GSOC

by Vincent Massol

Hi (Arun), I've thought a bit and here are some ideas: 1) Have a xwiki-importer module in platform/core/ Note that later on we could move the XAR importer as a submodule in there too. This module will contain all the java code to perform input parsing + import into wiki pages. 2) Have a xwiki-importer application in platform/applications/ This application would provide an "Import" icon in the Admin page. When you click on that icon you would get to a second page with several icons: - Import Application (that's the current XAR import) - Import from Confluence - Import from Mediawiki ... 3) Each "Import from ..." will have its own UI since the import methods differ from wiki to wiki Arun, you need to look at all wikis for which we want to offer an importer for (MediaWiki and Confluence to start with) and see what options they offer: - could be an export in the form of XML files in a zip - could be accessing them through a REST/XMLRPC/other api online For a first version I think we should offer only 1 way of importing and I'd suggest the zip containing XML if that's supported by the wiki. 4) (this is a second step) Write Link parsers for the different wiki syntaxes (since right now we only have XWiki 2.0 link parser). We'll need 1 for mediawiki and 1 for confluence. 5) (this is a third step) Deal with macros. For example confluence offers lots of macros which when imported will not work. We can convert them to XWiki macros that do something similar. We'll need to identify simple macros that we don't have to add them. Of course for macros that we don't have, they wouldn't be converted. 6) We need a Roadmap/planning * Do this in the sandbox for now * Prepare a planning with milestones. * Each milestone shouldn't be longer than 2 weeks. * Make sure you don't slip dates * Always have something that work. This means that after the first milestone you *MUST* have something that can be demonstrated and that is working (even if it's not doing much) * Corollary: always start by doing the integration work first so that you can have a working chain. More specifically, after your first milestone, I should be able to drop the xwiki-import JAR in my xwiki's WEB-INF/lib + import the xwiki- import XAR and be able to click on "Import from Mediawiki" and be able to have the pages imported in xwiki 2.0 syntax (no options for the first version). The first milestone could be 3 weeks since you need to set up the plumbery. Let me know what you think. All: let us know also what you think about this. Guillaume: Let us know if you're ok with the UI ideas above. Thanks -Vincent

15 years, 8 months

[xwiki-devs] XE 1.9 RC1 postponed to Monday 25

by Vincent Massol

Hi, Since it's a bank holiday tomorrow and our release manager is on holidays till Sunday night we're postponing the 1.9RC1 release to next Monday. This means committers can still commit non risky *bug fixes* on the 1.9 branch for the coming few days and thus progress on the work that needs to be done for 1.9RC2. 1.9RC2 release date is maintained to 1st of June. Note that 1.9RC2 == 1.9 final. Thanks -Vincent

15 years, 8 months

[xwiki-devs] [VOTE] Enable XWiki syntax 2.0 by default in 1.9 final

by Vincent Massol

Hi, I'd like to propose that we enable by default the 2.0 syntax in 1.9 final (i.e do this in RC2). Here's my +1 Thanks -Vincent

15 years, 8 months

[xwiki-devs] [Proposal] Choosing a new format for serializing a document's name

by Vincent Massol

Hi, We need to choose a new format for serializing a document name for several reasons: - the current format is ambiguous and doesn't allow too many characters to be entered - it doesn't support nested spaces I'd like to propose the following format: a URL. <wiki>://<space1>/<space2>/.../<spaceN>/<page>?<params>#anchor Examples: * Page * Space/Page * mywiki://Space/Page * mywiki://some/nested/Space/Page * Page?param=value * Page#anchor + the ability to escape chars. For example if the user wants to have the "/" char in a page name he would have: Special~/Page (we can decide what escape char to use) Of course, it'll be the role of the serializer to escape chars as required. Pros of using a URL format: * easy to code since we can reuse the JDK's URL class * URL friendly. It's easy to copy paste the URL of a document into a link. No more needing to translate "." into "/" * it's JCR friendly since JCR also uses "/" for the path to a Node * it's a well known format and users are used to it WDYT? Thanks -Vincent

15 years, 8 months

[xwiki-devs] XWikiAllGroup implicit behavior

by Ludovic Dubost

Hi, As part of the Curriki development, since Curriki is growing big (more than 60000 users), the XWiki.XWikiAllGroup is not scalable and this can lead to bad things. I've proposed a patch to make XWiki.XWikiAllGroup implicit. We have tested it and this seems to work well (see http://jira.xwiki.org/jira/browse/CURRIKI-738 for the patch). The only issue I see is the fact that once you have activated this, the counter of number of users for the group all group in the administration and the ability to edit the group makes no sense. Finally the adding the the AllGroup in registration has not yet been deactivated which would be necessary to make the registration not be impacted by the number of users. The Curriki team would like to see this patch make it in the XWiki Core. WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

15 years, 8 months

Re: [xwiki-devs] [xwiki-notifications] r20119 - platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest

by Vincent Massol

On May 19, 2009, at 7:52 PM, fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2009-05-19 19:52:09 +0200 (Tue, 19 May 2009) > New Revision: 20119 > > Modified: > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/ > ComponentsObjectFactory.java > Log: > [Minor] Use component descriptors in order to check whether a > component has a PER_LOOKUP instantiation strategy. > > Modified: platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/ > rest/ComponentsObjectFactory.java > =================================================================== > --- platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/ > ComponentsObjectFactory.java 2009-05-19 17:47:18 UTC (rev 20118) > +++ platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/ > ComponentsObjectFactory.java 2009-05-19 17:52:09 UTC (rev 20119) > @@ -25,6 +25,7 @@ > import org.restlet.ext.jaxrs.InstantiateException; > import org.restlet.ext.jaxrs.ObjectFactory; > import org.xwiki.component.annotation.InstantiationStrategy; > +import org.xwiki.component.descriptor.ComponentDescriptor; > import org.xwiki.component.descriptor.ComponentInstantiationStrategy; > import org.xwiki.component.manager.ComponentLookupException; > import org.xwiki.component.manager.ComponentManager; > @@ -65,6 +66,8 @@ > XWikiRestComponent component = > (XWikiRestComponent) > componentManager.lookup(XWikiRestComponent.class, clazz.getName()); > > + ComponentDescriptor componentDescriptor = > componentManager.getComponentDescriptor(XWikiRestComponent.class, > clazz.getName()); > + > /* > * Retrieve the releasable component list from the > context. This is used to store component instances that > * need to be released later. > @@ -79,11 +82,8 @@ > } > > /* Only add components that have a per-lookup > instantiation stategy. */ > - InstantiationStrategy is = > component.getClass().getAnnotation(InstantiationStrategy.class); > - if (is != null) { > - if > (is.value().equals(ComponentInstantiationStrategy.PER_LOOKUP)) { > - releasableComponentReferences.add(component); > - } > + > if > (componentDescriptor > .getInstantiationStrategy > ().equals(ComponentInstantiationStrategy.PER_LOOKUP)) { you could write: if (componentDescriptor.getInstantiationStrategy() == ComponentInstantiationStrategy.PER_LOOKUP) -Vincent > > + releasableComponentReferences.add(component); > } > > /*

15 years, 8 months

[xwiki-devs] [Discussion] Officeimporter remote OpenOffice server

by Asiri Rathnayake

Hi Devs, Currently OfficeImporter requires an OpenOffice server to be present in the same computer as XE. I have been searching about adding support for a remote OpenOffice server but the results are not very promising: http://groups.google.com/group/jodconverter/browse_thread/thread/f4f0e8328d… Even though this is the case, I think we can settle on a compromise with the following approach: * We develop a stand-alone servlet (probably under xwiki-tools just like the root-web-app) * The purpose of this servlet is to: 1. Accept incoming office documents 2. Convert them into html (results in multiple files) 3. Zip the results together 4. Stream the zipped content back to the client * And the client would be any xwiki instance that is configured to consume this converter-servlet. This way, multiple XWiki instances would be able to share a central OpenOffice server via the converter-servlet. The downside of this approach is that there has to be a servlet container on the remote computer which is hosting the OpenOffice server. Please let me know what you think about this idea. Thanks. - Asiri

15 years, 8 months

[xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"

by Thomas Mortagne

Hi devs, For 2.0 syntax we make XWikiDocument.display() enclose the result in {{html}}{{/html}} since it's supposed to generate html and that we should not have to use {{html}}{{/html}} in the syntax when we call $doc.display("somefield"). Now the issue is that public api Object and Document get() methods does not return the value but call display. But users (and us) used to access string value using $object.somefield instead of $object.getProperty("somefield").getValue() which is the correct form to access an object field value. Because of this wrong use of display() we have a big change in the api form user point so the question is what do we do ? I can see the following solution: 1) it's not a real change in the API, user should use the right way. It's ok like that. 2) we "optimize" XWikiDocument.display() by generating {{html}}{{/html}} only when it's necessary (if the result really is html) 2.a) if it contains "<" or ">" 2.b) when it's not a BaseStringProperty/NumberProperty/DateProperty since theses properties does not really need to produce HTML 3) we clean the display result in Object/Document.get by removing the {{html}}{{/html}} when the result does not really contains html (more or less the same way to find it than 2)) WDYT ? I'm +1 for 2.a) (I don't like b, i think the generic way is better) since i don't think we can "change" the API even if it's not a real change and this solution is not that much a hack, it makes display() return cleaner anyway. 3) as the advantage of fixing only the problematic API but it's really too crappy IMO

15 years, 8 months

[xwiki-devs] [VOTE] Start migrating our XE XAR to 2.0 syntax for 1.9 final

by Vincent Massol

Hi, Following the mail vote for enabling the 2.0 syntax in 1.9 final we need to decide on our strategy for the XE XAR. I propose that we only support 1 XAR (since I don't think we have the manpower to support 2) and that this XAR is in 2.0 syntax. For 1.9 we would only convert a few pages (listed in http://jira.xwiki.org/jira/browse/XWIKI-3605) and in 2.0 we will continue till we have a full 2.0 syntax XAR. We would also add a warning in the release notes for 1.9 listing the pages that have been converted to 2.0 syntax. Here's my +1 Thanks -Vincent

15 years, 8 months

[xwiki-devs] [ANN] XWiki Office 1.0 Milestone 3 released!

by Florin Ciubotaru

The XWiki development team is pleased to announce the release of XWiki Office 1.0 Milestone 3. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiOffice !** XWiki Office is a XWiki.org project that provides integration between Microsoft Office and XWiki servers. For more information about XOffice go at: - http://xoffice.xwiki.org/xwiki/bin/view/Main/ Main changes from version 1.0 Milestone 2: - Basic XML-RPC support - Opening, editing & publishing pages(XHTML content only) - Downloading, opening, editing & uploading attachments - Viewing the wiki in the Wiki Explorer - Support for multiple encodings - Improved wiki explorer - Inhibited unnecessary Word messages & dialogs - Better sync between Word instances - Better & cleaner output All active XWord M2 clients and snapshot instances will be automatically updated to the latest version. For details about this release see the Release Notes at: - http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXOffice10M3 You can also view the roadmap here: - http://xoffice.xwiki.org/xwiki/bin/view/Main/Roadmap#HVersion10Milestone3 Thanks -The XWiki dev team

15 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs