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

[xwiki-devs] Translation status and improvements

by Ludovic Dubost

I've improved slightly the translation app at http://l10n.xwiki.org It now supports sorting per the translation keys both for the output (the file will be nicer looking) and when translating, which will make it easier to translate keys that correspond to the same module together. In terms of status the great news is that we have the following language completed: - English (obviously) - French - German - Romanian Translators might want to have a look at the "outdated" translations. These are the already translated keys that have in the mean time changed in the english language. Outdated translations are available from the OutDated link of your language. Review is also important. It gives a second chance to check translations. Also an already translated key that has been changed and not reviewed will not be taken into account until it is reviewed. Review is accessible from the Review link of your language. In any case I'm really happy with what we have achieve. We now have 4 complete languages and we can keep track of the changes. We'll make sure this hard work is going to make it in 1.8 final release. Thanks to all for the contribution and we welcome other volunteers to tackle the other languages. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years, 6 months

1
0
0 0

[xwiki-devs] [VOTE] Refactoring of the image/link xwiki syntax 2.0 to be more generic

by Vincent Massol

Hi devs, Someone on the list asked how create a link and an image pointing to a relative reference (that he got using one of XWiki's API since they all return relative URL). We currently don't have a good solution for this and I'd like to propose a solution. For links ======= Make the usage of a prefix that specifies what comes next a generic feature. We have the following needs: * link to a URL * link to a relative path * link to a document * link to a mailto * link to an attachment I propose the following syntax: [[label>>prefix:value]] where prefix = one of http:, path:, doc:, mailto:, attach: In addition I propose that when there's no prefix or if the prefix is an unknown prefix then to consider that the reference is a reference to a document (equivalent to doc:). Pros: * Generic * Ability to add more prefixes later on (for ex ftp:) * Ability to have virtual wikis which have "reserved" names such as "doc", "http", "ftp", "mailto", etc since you can write [[doc:doc:Space.Page]] * Ability to write shorthand for documents in the text, such as: "This is a link doc:Space.Page" * Ability to reference relative paths and write stuff such as {{velocity}}[[label>>path:$xwiki.getURL(something)]]{{/velocity}} For images ========= * Similar to links add the ability to add prefixes in a generic way. We have the following needs: * image where the source is at a URL * image where the source is at a relative path * image where the source is in a document I propose the following syntax: image:prefix:value where prefix = one of http:, path:, attach: Note that we already support image:http://... so the proposal here is simply to make it generic. In addition I propose that when there's no prefix or if the prefix is unknown then to consider that the image is to be found in a document (equivalent to attach:). Same pros as above. Here's my +1 WDYT? Thanks -Vincent

16 years, 6 months

5
8
0 0

[xwiki-devs] About GSoc 2009 project Ideas for XWiki...

by usw wickramasinghe

Hi, I'm an Computer Science Undergraduate who is currently undergoing training and engaged n the field of Open Source SOA products n development. I've recently done project work in the area of WS Security (WS [Web Services] Policy derivation from SOAP messages n some OSGI component implementatons around that..) and have fair knowlege on WS security implementations. Also also have an good understanding in Apache Axis2 Engine and been working on Apache Axis2 Engine developing Ruby Services deployment using JRuby frame work.. I would pretty much like to participate in a XWiki GSoc project for 2009 as i see this as a great opportunity to expand my understanding in this field and as a great learning experience. I had a look at previous 2008 xWiki Gsoc Ideas,Devs list issues and some jiras and i gained interest in doing some work in xWiki Core. I was particularly interested in ideas such as SAML Authentication (Reported @ xWiki JIRA by Sergiu Dumitriu<http://jira.xwiki.org/jira/browse/XWIKI-402>) , Support for AJAX Calls (Reported @ xWiki JIRA by Sergiu Dumitriu <http://jira.xwiki.org/jira/browse/XWIKI-641> ) , Xwiki Web Services integration , and would like to know whether aforementioned work (/proposals) are still available. However i would also be open to any other ideas that will be put forward by XWiki org and would like to hear about that too. BTW i still don't know whether this is too early or not to ask for project ideas n stuff ,but am certainly hoping to work with you guys if all goes well .I'm still new to XWiki engine and it's aspects but i am willing to, learn and have a good run on xWiki. Your feedback regarding this is very much appreciated..Thnx in advance . Regards, Udayanga Shaminda Wickramasinghe

16 years, 6 months

3
5
0 0

[xwiki-devs] [ANN] XWiki Enterprise 1.8 Release Candidate 2 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.8 RC 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the second Release Candidate for the 1.8 version. Changes from 1.8RC1: Main changes: * new "useravatar" macro for 2.0 syntax * Improvements on 1.0->2.0 syntaxes convertion * Add ability to configure xwiki to use the XWiki Syntax 2.0 as default when creating new pages * Bugs fixed in XWiki 2.0 syntax rendering. * Upgrade to groovy 1.6 final. * Update french translations * Update german translations * Update spanish translation Important bug fixes: * XWIKI-3228 - Error while saving xwiki 2.0 documents containing anchor links * XWIKI-3242 - Entering an empty link makes the rendering blow up * XWIKI-3252 - Cannot view documents in other languages than the default when in multilingual mode and when using XWiki Syntax 2.0 For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise18RC2 Note that general goals for XWiki Enterprise 1.8 are: * Office Importer * New Blog * REST API * Finish new rendering/syntax * Finish new WYSIWYG * French XE * MediaWiki import Thanks -The XWiki dev team

16 years, 6 months

1
0
0 0

Re: [xwiki-devs] xwiki-enterprise-web sources

by walido

hi i was wondering if is it possible to have the sources of xwiki entreprise as netbeans project or eclipse project (the links to the svn ae dead) i can't get any of the links to the repositories please could you help on this one i really need the sources of xwiki thank you very much -- View this message in context: http://n2.nabble.com/xwiki-enterprise-web-sources-tp2414508p2428141.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years, 6 months

2
2
0 0

[xwiki-devs] [Proposal] Adding a WikiAccessBridge

by Dan Miron

Hi guys, Proposal: create a new bridge called WikiAccessBridge whose purpose is, for now, to get the temporary directory's location. Reason: in my ChartMacro I need a temporary folder for storing images, and then sending them to the output. I'm thinking of providing two methods: File getTemporaryDirectory() - to get the directory as a File, thus having the ability to write files within it URL getAttachmentURL(String fileName) - to get a newly created file as a web URL (e.g: http://localhost/my_newly_created_temporary_file.png) I plan to put the specifications of the bridge within org.xwiki.bridge and the implementation within com.xpn.xwiki WDYT? Tnx, Dan

16 years, 6 months

3
4
0 0

Re: [xwiki-devs] [xwiki-notifications] r17211 - in platform/web/trunk/standard/src/main/webapp/resources/js/xwiki: . xwikiexplorer

by Sergiu Dumitriu

jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-03-03 23:40:14 +0100 (Tue, 03 Mar 2009) > New Revision: 17211 > > Added: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwikiexplorer/ > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwikiexplorer/xwikiexplorer.js > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js > Log: > XWIKI-3287 : Provide a tree widget allowing to browse a XWiki farm (wikis>spaces>pages>attachments) > > First version of XWikiExplorer widget. > +constants: { > + /** > + * Current wiki. > + */ > + currentWiki: "$context.getDatabase()", > > + /** > + * Main wiki. > + */ > + mainWiki: "$context.getMainWikiName()", This could make the file hard to cache in multiwiki mode using paths as identifiers, since the JS will have the same address for all wikis. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 6 months

2
2
0 0

Re: [xwiki-devs] [Issue] Closed: (XWIKI-3287) Provide a tree widget allowing to browse a XWiki farm (wikis>spaces>pages>attachments)

by Sergiu Dumitriu

Jean-Vincent Drean (JIRA) wrote: > > Jean-Vincent Drean closed XWIKI-3287. > ------------------------------------- > > Assignee: Jean-Vincent Drean > Fix Version/s: 1.8 RC2 > 1.9 M1 > Resolution: Fixed > > First version commited on both trunk and 1.8 branch. > > To see the tree in action you can paste the following code in a new page: > > {noformat} > #if($request.input) > $response.setContentType('text/xml') > #set($input = $request.input.toLowerCase()) > <?xml version="1.0" ?> > <results type="8"> HQL injection. > #foreach($item in $xwiki.searchDocuments(" where lower(doc.fullName) like '%${input}%'", 8, 0)) > <rs id="${velocityCount}" info="">$item</rs> > #end > </results> > #else Too many lines the user has to write. We should have a helper script file that autoloads the rest of them. > ## Smartclient > $xwiki.jsfx.use("js/smartclient/initsc.js", true) > $xwiki.jsfx.use("js/smartclient/modules/ISC_Core.js") > $xwiki.jsfx.use("js/smartclient/modules/ISC_Foundation.js") > $xwiki.jsfx.use("js/smartclient/modules/ISC_Containers.js") > $xwiki.jsfx.use("js/smartclient/modules/ISC_Grids.js") > $xwiki.jsfx.use("js/smartclient/modules/ISC_Forms.js") > $xwiki.jsfx.use("js/smartclient/modules/ISC_DataBinding.js") > $xwiki.jsfx.use("js/smartclient/skins/Enterprise/load_skin.js") > ## XWikiExplorer > $xwiki.jsfx.use("js/xwiki/xwikiexplorer/xwikiexplorer.js", true) > ## Suggest > $xwiki.ssfx.use("js/xwiki/suggest/ajaxSuggest.css") > $xwiki.jsfx.use("js/xwiki/suggest/ajaxSuggest.js") > ## > {pre}## > <script> > var blacklistedSpaces = { > #foreach($space in $blacklistedSpaces) > $space : true, > #end > }; > XWiki.xwikiExplorer.create({ > width:600, > height:300, > displayAttachments:true, > displayLinks:true, > blacklistedSpaces:blacklistedSpaces > }); > </script> > {/pre}## > #end > #set($docextras = []) > {noformat} -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 6 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r17211 - in platform/web/trunk/standard/src/main/webapp/resources/js/xwiki: . xwikiexplorer

by Sergiu Dumitriu

jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-03-03 23:40:14 +0100 (Tue, 03 Mar 2009) > New Revision: 17211 > > Added: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwikiexplorer/ > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwikiexplorer/xwikiexplorer.js > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js > Log: > XWIKI-3287 : Provide a tree widget allowing to browse a XWiki farm (wikis>spaces>pages>attachments) > > First version of XWikiExplorer widget. > > > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js 2009-03-03 22:27:35 UTC (rev 17210) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js 2009-03-03 22:40:14 UTC (rev 17211) > - * Add click listeners on all rendering errors (new rendering engine) to let users expands error messages to read technical information. > + * Build a resource object from a wiki resource descriptor (aka fullName). > + * > + * Examples of resource objects: ---- > + * { wiki: "xwiki", space: "Main", prefixedSpace: "xwiki:Main", > + * fullName: "Main.WebHome", prefixedFullName: "xwiki:Main.WebHome", > + * name: "WebHome", attachment: "" } > + * { wiki: "xwiki", space: "Main", prefixedSpace: "xwiki:Main", > + * fullName: "Main.WebHome", prefixedFullName: "xwiki:Main.WebHome", > + * name: "WebHome", attachment: "" } ---- These two are identical. > + * { wiki: "xwiki", space: "Main", prefixedSpace: "xwiki:Main", > + * fullName: "Main.WebHome", prefixedFullName: "xwiki:Main.WebHome", > + * name: "WebHome", attachment: "attach.zip" } > + * > + * @param fullName fullName of the resource to create (examples: xwiki:Main.WebHome, xwiki:Main.WebHome@Archive.tgz). > + * @return the newly created resource object. > */ Why did this one disappear? > -document.observe("dom:loaded", function() { > - $$('[class="xwikirenderingerror"]').each(function(error) { > - if(error.nextSibling.innerHTML !== "" > - && error.nextSibling.hasClassName("xwikirenderingerrordescription")) { > - error.style.cursor="pointer"; > - error.title = "$msg.get('platform.core.rendering.error.readTechnicalInfomation')"; > - Event.observe(error, "click", function(event){ > - toggleClass(event.element().nextSibling,'hidden'); > - }); > - } > - }); > -}); This method is a bit too long, suggesting refactoring. Also, we don't use tabs... > +getResource : function(fullName) { > + var resource = { > + wiki : "", > + space : "", > + prefixedSpace : "", > + fullName : fullName, > + prefixedFullName : "", > + name : "", > + attachment : "", > + anchor: "" > + }; > > + // Extract wiki and set prefixedFullName. > + if (fullName.contains(this.constants.wikiSpaceSeparator)) { > + resource.wiki = fullName.substring(0, fullName.indexOf(this.constants.wikiSpaceSeparator)); > + // Remove wiki from fullName. > + resource.fullName = fullName.substring(fullName.indexOf(this.constants.wikiSpaceSeparator) + 1, fullName.length); > + resource.prefixedFullName = fullName; > + } else if (fullName.contains(this.constants.spacePageSeparator)) { > + // Fallback on current wiki. > + resource.wiki = this.constants.currentWiki; > + resource.prefixedFullName = resource.wiki + this.constants.wikiSpaceSeparator + fullName; > + } > + > + // Extract attachment and remove it from fullName and prefixedFullName if any. > + if (resource.fullName.contains(this.constants.pageAttachmentSeparator)) { > + resource.fullName = resource.fullName.substring(0, resource.fullName.indexOf(this.constants.pageAttachmentSeparator)); > + resource.prefixedFullName = resource.prefixedFullName.substring(0, resource.prefixedFullName.indexOf(this.constants.pageAttachmentSeparator)); > + } > + > + // Extract anchor and remove it from fullName and prefixedFullName if any. > + if (resource.fullName.contains(this.constants.anchorSeparator)) { > + resource.anchor = resource.fullName.substring(resource.fullName.indexOf(this.constants.anchorSeparator) + 1, resource.fullName.length); > + resource.fullName = resource.fullName.substring(0, resource.fullName.indexOf(this.constants.anchorSeparator)); > + resource.prefixedFullName = resource.prefixedFullName.substring(0, resource.prefixedFullName.indexOf(this.constants.anchorSeparator)); > + } > + > + // Extract space and page name. > + if (fullName.contains(this.constants.spacePageSeparator)) { > + // Space > + resource.space = fullName.substring(fullName.indexOf(this.constants.wikiSpaceSeparator) + 1, fullName.indexOf(this.constants.spacePageSeparator)); > + resource.prefixedSpace = resource.wiki + this.constants.wikiSpaceSeparator + resource.space; > + if (fullName.length - fullName.indexOf(this.constants.spacePageSeparator) > 0) { > + if (!fullName.contains(this.constants.pageAttachmentSeparator)) { > + // Page name. > + resource.name = fullName.substring(fullName.indexOf(this.constants.spacePageSeparator) + 1, fullName.length); > + } else { > + // Page name. > + resource.name = fullName.substring(fullName.indexOf(this.constants.spacePageSeparator) + 1, fullName.indexOf(this.constants.pageAttachmentSeparator)); > + if (fullName.length - fullName.indexOf(this.constants.pageAttachmentSeparator) > 0) { > + // Attachment name. > + resource.attachment = fullName.substring(fullName.indexOf(this.constants.pageAttachmentSeparator) + 1, fullName.length); > + } > + } > + > + } > + } > + > + return resource; > +} > +}; > + > /** > * Hide the fieldset inside the given form. > * > > Added: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwikiexplorer/xwikiexplorer.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwikiexplorer/xwikiexplorer.js (rev 0) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwikiexplorer/xwikiexplorer.js 2009-03-03 22:40:14 UTC (rev 17211) > @@ -0,0 +1,742 @@ Our standard header notice would be nice... > +/** > + * XWiki Explorer widget for smartClient. > + */ > + > +if (typeof XWiki == "undefined") { > + alert("ERROR: xwikiexplorer.js depends on xwiki.js"); Just alert? This is critical, the rest of the code should be on an else, or throw an error instead. > +} > + > +XWiki.xwikiExplorer = { > + > + /** > + * Base URI for XWiki REST service. > + */ > + baseRestURI : XWiki.constants.contextPath + "/rest/", > + It would be nice to have these URLs valid in the future. > + /** > + * REST children relationship. > + */ > + restChildrenRel: "http://www.xwiki.org/rel/children", > + > + /** > + * REST children relationship. > + */ > + restParentRel: "http://www.xwiki.org/rel/parent", > + > + /** > + * REST attachments relationship. > + */ > + restAttachmentsRel: "http://www.xwiki.org/rel/attachments", > + > + /** > + * REST home relationship. > + */ > + restHomeRel: "http://www.xwiki.org/rel/home", > + > + /** > + * A set of callbacks fired by several smartClient classes (callback handlers are injected by XWiki.smartClient). > + */ > + callbacks : { > + // XWikiExplorerResultTree.dataArrived More unwanted tabs here: > + dataArrived : new Array(), > + // DataSource.transformResponse > + transformResponse : new Array() > + }, > + > + /** > + * Create a SmartClient class extending isc.ResultTree to allow: > + * Dynamic DS instantiation. > + * Custom icon per entry type without having any icon field in the REST response. > + */ > + createXWikiExplorerResultTreeClass : function() { > + > + /* > + * XWikiExplorerResultTree class overriding default ResultTree class. > + * Used by xwikiExplorer DataSources. > + */ > + isc.ClassFactory.defineClass("XWikiExplorerResultTree", isc.ResultTree); > + isc.XWikiExplorerResultTree.addMethods({ > + > + /** > + * Override isc.ResultTree.getChildDataSource > + */ > + getChildDataSource : function (node, nodeDS) { > + // look for explicitly specified child type > + var childDSName = node[this.childTypeProperty]; It is a good practice to always use {} around blocks, even if it's just one line. > + if (childDSName != null) > + return isc.DS.get(childDSName); -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 6 months

1
0
0 0

[xwiki-devs] [VOTE] Release XE 1.8RC2

by Thomas Mortagne

Hi devs, I would like to release XE 1.8RC2, it's mainly a bufixing/improvement release as will be the RC3 before 1.8 final. Here is my +1. -- Thomas Mortagne

16 years, 6 months

9
9
0 0

[xwiki-devs] [ANN] XWiki Office 1.0 Milestone 1 Released!

by Florin Ciubotaru

The XWiki development team is pleased to announce the release of XWiki Office 1.0 Milestone 1. 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. Here is a list of features: - Create wiki pages using Word - Edit existing pages in Word - Download and edit attachments - Attach files to the wiki - Browse the wiki using the Wiki Explorer For more information about XOffice go at: - http://xoffice.xwiki.org/xwiki/bin/view/Main/ For details about this release see the Release Notes at: - http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXOffice10M1 Thanks -The XWiki dev team

16 years, 6 months

4
3
0 0

[xwiki-devs] Help us improve the XWiki.org website

by Emilie Ogez

Hello, XWiki.org has to meet your expectations. We're looking forward listening what you have to say about our website and how we could improve it. We'd be dazzled if you agreed to take the time to answer the questions listed below. A summary of the answers will be posted on XWiki.org as soon as they have been processed. Thanks for your time! Regards. Emilie Ogez Marketing & Communication Manager

16 years, 6 months

1
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r17187 - manager/trunk/web

by Sergiu Dumitriu

jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-03-03 14:29:04 +0100 (Tue, 03 Mar 2009) > New Revision: 17187 > > Modified: > manager/trunk/web/pom.xml > Log: > XATAG-1 : Create initial version of the tag application > > Added tag plugin to XEM xwiki.cfg > > > > Modified: manager/trunk/web/pom.xml > =================================================================== > --- manager/trunk/web/pom.xml 2009-03-03 11:45:01 UTC (rev 17186) > +++ manager/trunk/web/pom.xml 2009-03-03 13:29:04 UTC (rev 17187) > @@ -109,7 +109,8 @@ > com.xpn.xwiki.plugin.watchlist.WatchListPlugin,\ > com.xpn.xwiki.plugin.wikimanager.WikiManagerPlugin,\ > com.xpn.xwiki.plugin.applicationmanager.ApplicationManagerPlugin,\ > - com.xpn.xwiki.wysiwyg.server.plugin.WysiwygPlugin > + com.xpn.xwiki.wysiwyg.server.plugin.WysiwygPlugin,\ > + com.xpn.xwiki.plugin.tag.TagPlugin Don't use tabs... -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 6 months

1
0
0 0

[xwiki-devs] Getting your feedback about the satisfaction survey

by Emilie Ogez

Hello I have started to list questions that could be part of the satisfaction survey about the XWiki products : http://dev.xwiki.org/xwiki/bin/view/Drafts/SatisfactionSurveyProducts I propose to get first feedback about XWiki Enterprise and XWiki Enterprise Manager. So, I have made two different forms. But: 1. maybe, one form can be sufficient. 2. the questions in each form can be different. Again, I'd like your feedback about it/them. Thanks in advance for your help and your time. Emilie

16 years, 6 months

2
1
0 0

[xwiki-devs] [PROPOSAL / IDEA] Upgrade OfficeImporter to jodconverter-3.0-beta-1 and integrate openoffice server management functions in XWiki UI

by Asiri Rathnayake

Hi Devs, =INTRO= A new version of jodconverter has been released ( http://code.google.com/p/jodconverter/) which, among several other enhancements includes support for automating openoffice server process management. Even though the jodconverter API has changed slightly, upgrading officeimporter to use this new version of jodconverter does not require that much of an effort and it will allow us to control the oo server instance pretty easily. With this new version jodconverter, all we have to do is configure the path to the OO server installation (and few more options) within our web.xml (or similar) file. Apart from that, starting / stopping the oo server process can be done in java. Optionally, we can configure following two parameters as well: 1. Maximum number of simulataneous conversion tasks to be handled by a single oo server instance. 2. Task execution timeout. =UI= To integrate oo server management functions in XE UI we can create an admin page for officeimporter like XWiki.OfficeImporterAdmin and link to it from XWiki.AdminSheet. As a start, I have created the this mockup ui: http://i39.tinypic.com/6tlli9.png. Please help me improve this UI :) =IMPLEMENTATION= I can see two different designs that would work: 1. Add the required method signatures (see below) to OfficeImporter component interface. 2. Introduce a separate component for managing the OpenOffice server instance. In any case, following methods (API) will have to be added: 1. startOoServer(); // start 2. stopOoServer(); // stop 3. getOoServerStatus(); // get current state (running / stopped / error) 4. getOoServerPath(); // Returns the location of oo server installation to be displayed on admin UI 5. getOoServerProfilePath(); // Each oo server installation is associated with a profile, this parameter also need to be configured in web.xml Since OpenOffice server is used only by officeimporter, adding those methods to OfficeImporter interface seems ok to me. WDYT? Thanks. - Asiri

16 years, 6 months

2
1
0 0

[xwiki-devs] [Vote] Add a GettingStarted space to XE's default XAR

by Guillaume Lerouge

Hi there, I'd like to send a vote on my proposal. Full discussion is here: http://n2.nabble.com/-Proposal----Adding-a-%22Getting-Started%22-space-in-t… If the vote is passed, I'll provide a patch with the pages in XML format. I'd like this guide to be included in XE 1.8 - if that's still possible. Since it doesn't impact anything core (it' very superficial from a tech PoW) I think it could be ok. WDYT? Here's my public commitment: I promise I will maintain and update this guide in the future ;-) Thanks, Guillaume PS: here's my +1 -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/

16 years, 6 months

4
8
0 0

[xwiki-devs] [Rendering] Should we move to non meaningful spaces?

by Vincent Massol

Hi, This is our last chance to change this behavior. We've found several places where having meaningful spaces are counter-productive: * in table cells since we can't align table anymore. For example: |= column1 |= column2 | this is some para | second column | hello | world (not sure this will be rendered nicely in mail but you see what I mean) * in scripts since having meaningful spaces prevents us from aligning velocity or groovy scripts. For ex we can't write: #if (....) #if (...) do something # end #end To see a better example have a look at http://tinyurl.com/ahz669 What I think users real want are meaningful new lines but I see cons overweighting pros for having meaningful white spaces. Thus I'm think we should strip whitespaces at beginning and end of lines including for line breaks. I'm slightly less sure for multiple spaces between words but even there I think we could strip them have users use {{{ }}} to put a non breaking space for ex (or introduce a {{space/}} macro or another special syntax although I'd rather we don't introduce a new syntax). WDYT? Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

16 years, 6 months

4
5
0 0

[xwiki-devs] [Proposal] Ignore first and last NewLine in Macros?

by Vincent Massol

Hi, The question arise whether we want to ignore first and last NL in macros in order to have the following be the same: {{macro}}content{{/macro}} {{macro}} content {{/macro}} For ex, most users will probably not expect that the following will generate 1 empty line: {{velocity}} content {{/velocity}} WDYT? Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

16 years, 6 months

5
4
0 0

Re: [xwiki-devs] [xwiki-notifications] r17078 - in platform/core/trunk/xwiki-officeimporter/src: main/java/org/xwiki/officeimporter/filter test/java/org/xwiki/officeimporter/internal/cleaner

by Vincent Massol

Hi Asiri, On Feb 27, 2009, at 12:32 PM, asiri (SVN) wrote: > Author: asiri > Date: 2009-02-27 12:32:21 +0100 (Fri, 27 Feb 2009) > New Revision: 17078 > > Added: > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/AbstractHTMLCleaningTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/ > EmptyLineParagraphOpenOfficeCleaningTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/ImageOpenOfficeCleaningTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/InvalidTagOpenOfficeCleaningTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/LineBreakOpenOfficeCleaningTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/LinkOpenOfficeCleaningTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/ListOpenOfficeCleaningTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/MiscWysiwygCleaningTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/ > RedundantTagOpenOfficeCleaningTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/TableOpenOfficeCleaningTest.java > Removed: > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/AbstractHTMLCleanerTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/OpenOfficeHTMLCleanerTest.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/WysiwygHTMLCleanerTest.java > Modified: > platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/filter/LineBreakFilter.java > Log: > XWIKI-3265: Restructure officeimporter test cases + write more tests > > * Completed. [snip] > +public class InvalidTagOpenOfficeCleaningTest extends > AbstractHTMLCleaningTest > +{ > + /** > + * {@code <style>} tags should be stripped from html content. > + */ > + public void testStyleTagRemoving() > + { > + String html = > + "<html><head><title>Title</title>" + "<style type= > \"text/css\">h1 {color:red} p {color:blue} </style>" > + + "</head><body>" + footer; > + Document doc = openOfficeHTMLCleaner.clean(new > StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("style"); > + assertEquals(0, nodes.getLength()); > + } > + > + /** > + * {@code <style>} tags should be stripped from html content. copy paste, should be <script>. > + */ > + public void testScriptTagRemoving() > + { > + String html = header + "<script type=\"text/javascript > \">document.write(\"Hello World!\")</script>" + footer; > + Document doc = openOfficeHTMLCleaner.clean(new > StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("script"); > + assertEquals(0, nodes.getLength()); > + } > +} > [snip] > + /** > + * {@code <br/>} elements placed next to paragraph elements > should be converted to {@code<div > + * class="wikikmodel-emptyline"/>} elements. > + */ > + public void testLineBreaksNextToParagraphElements() > + { > + checkLineBreakReplacements("<br/><br/><p>para</p>", 0, 2); > + checkLineBreakReplacements("<p>para</p><br/><br/>", 0, 2); > + checkLineBreakReplacements("<p>para</p><br/><br/><p>para</ > p>", 0, 2); > + } Shouldn't this be done by the default HTML Cleaner? Same for the other tests in this category. > + /** > + * The html generated by open office server includes anchors of > the form {@code<a name="table1"><h1>Sheet 2: > + * <em>Hello</em></h1></a>} and the default html cleaner > converts them to {@code <a name="table1"/><h1><a > + * name="table1">Sheet 1: <em>Hello</em></a></h1>} this is > because of the close-before-copy-inside > + * behaviour of default html cleaner. Thus the additional (copy- > inside) anchor needs to be ripped off. This looks like a bug in the default HTML cleaner no? > + /** > + * If there are leading spaces within the content of a list > item ({@code<li/>}) they should be trimmed. > + */ > + public void testListItemContentLeadingSpaceTrimming() > + { > + String html = header + "<ol><li> Test</li></ol>" + footer; > + Document doc = openOfficeHTMLCleaner.clean(new > StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("li"); > + Node listContent = nodes.item(0).getFirstChild(); > + assertEquals(Node.TEXT_NODE, listContent.getNodeType()); > + assertEquals("Test", listContent.getNodeValue()); > + } Shouldn't this be done in the default HTML cleaner? Actually I think this is already done in the XHTML parser by the whitespace XML filter. If not then it's a bug of the whitespace filter. For all bugs please refer to the jira issue in the javadoc and explain that the code will be removed once the bug is fixed. > + > + /** > + * If there is a leading paragraph inside a list item, it > should be replaced with it's content. > + */ > + public void testListItemContentIsolatedParagraphCleaning() > + { > + String html = header + "<ol><li><p>Test</p></li></ol>" + > footer; > + Document doc = openOfficeHTMLCleaner.clean(new > StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("li"); > + Node listContent = nodes.item(0).getFirstChild(); > + assertEquals(Node.TEXT_NODE, listContent.getNodeType()); > + assertEquals("Test", listContent.getNodeValue()); > + } > +} This should be handled by a combination of both XHTML parser and Wiki Syntax Renderer and/or by the default HTML cleaner. > + /** > + * Test cleaning of html paragraphs brearing namespaces. > + */ > + public void testParagraphsWithNamespaces() > + { > + String html = header + "<w:p>paragraph</w:p>" + footer; > + Document doc = > + wysiwygHTMLCleaner.clean(new StringReader(html), > Collections.singletonMap(HTMLCleaner.NAMESPACES_AWARE, > + "false")); > + NodeList nodes = doc.getElementsByTagName("p"); > + assertEquals(1, nodes.getLength()); > + } hmmm... I think this needs to be reviewed and we need to check if the wikimodel XHTML parser supports namespaces. > + > + /** > + * The source of the images in copy pasted html content should > be replaces with 'Missing.png' since they can't be > + * uploaded automatically. > + */ > + public void testImageFiltering() > + { > + String html = header + "<img src=\"file://path/to/local/image.png > \"/>" + footer; > + Document doc = wysiwygHTMLCleaner.clean(new > StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("img"); > + assertEquals(1, nodes.getLength()); > + Element image = (Element) nodes.item(0); > + Node startComment = image.getPreviousSibling(); > + Node stopComment = image.getNextSibling(); > + assertEquals(Node.COMMENT_NODE, startComment.getNodeType()); > + > assertTrue > (startComment.getNodeValue().equals("startimage:Missing.png")); It should be lowercase "missing.png". So this means a missing.png image need to be present in all skins? Has this been discussed and is everyone aware of this? > + /** > + * Test filtering of those tags which doesn't have any > attributes set. > + */ > + public void testFilterIfZeroAttributes() > + { > + String htmlTemplate = header + "<p>Test%sRedundant > %sFiltering</p>" + footer; > + String[] filterIfZeroAttributesTags = new String[] {"span", > "div"}; > + for (String tag : filterIfZeroAttributesTags) { > + String startTag = "<" + tag + ">"; > + String endTag = "</" + tag + ">"; > + String html = String.format(htmlTemplate, startTag, > endTag); > + Document doc = openOfficeHTMLCleaner.clean(new > StringReader(html)); > + NodeList nodes = doc.getElementsByTagName(tag); > + assertEquals(0, nodes.getLength()); > + } > + } Shouldn't this be done in the default HTML cleaner? > + > + /** > + * Test filtering of those tags which doesn't have any textual > content in them. > + */ > + public void testFilterIfNoContent() > + { > + String htmlTemplate = header + "<p>Test%sRedundant%s%s > %sFiltering</p>" + footer; > + String[] filterIfNoContentTags = > + new String[] {"em", "strong", "dfn", "code", "samp", > "kbd", "var", "cite", "abbr", "acronym", "address", > + "blockquote", "q", "pre", "h1", "h2", "h3", "h4", "h5", > "h6"}; > + for (String tag : filterIfNoContentTags) { > + String startTag = "<" + tag + ">"; > + String endTag = "</" + tag + ">"; > + String html = String.format(htmlTemplate, startTag, > endTag, startTag, endTag); > + Document doc = openOfficeHTMLCleaner.clean(new > StringReader(html)); > + NodeList nodes = doc.getElementsByTagName(tag); > + assertEquals(1, nodes.getLength()); > + } > + } > +} Shouldn't this be done in the default HTML cleaner? > + /** > + * An isolated paragraph inside a table cell item should be > replaced with paragraph's content. > + */ > + public void testTableCellItemIsolatedParagraphCleaning() > + { > + String html = header + "<table><tr><td><p>Test</p></td></ > tr></table>" + footer; > + Document doc = openOfficeHTMLCleaner.clean(new > StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("td"); > + Node cellContent = nodes.item(0).getFirstChild(); > + assertEquals(Node.TEXT_NODE, cellContent.getNodeType()); > + assertEquals("Test", cellContent.getNodeValue()); > + } Isn't this already tested above? In any case shouldn't this be moved out of the importer? Same for other tests in the same category. > + /** > + * If multiple paragraphs are found inside a table cell item, > they should be wrapped in an embedded document. > + */ > + public void testTableCellItemMultipleParagraphWrapping() > + { > + assertEquals(true, > checkEmbeddedDocumentGeneration("<table><tr><td><p>Test</p><p>Test</ > p></td></tr></table>", > + "td")); > + } This looks like a bug in the XHTML parser. Same for other tests in the same category. > + > + /** > + * Empty rows should be removed. > + */ > + public void testEmptyRowRemoving() > + { > + String html = header + "<table><tbody><tr><td>cell</td></ > tr><tr></tr></tbody></table>" + footer; > + Document doc = openOfficeHTMLCleaner.clean(new > StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("tr"); > + assertEquals(1, nodes.getLength()); > + } Shouldn't this be done in the default HTML cleaner? Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

16 years, 6 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r17100 - in platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel: . src/main/java/org/xwiki/rendering/internal/parser/wikimodel

by Thomas Mortagne

On Sat, Feb 28, 2009 at 17:57, SVN vmassol <platform-notifications(a)xwiki.org> wrote: > Author: vmassol > Date: 2009-02-28 17:57:59 +0100 (Sat, 28 Feb 2009) > New Revision: 17100 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/internal/parser/wikimodel/AbstractWikiModelParser.java > Log: > * Started adding setter for setter injection and to allow using the bean without a component manager that does the injection automatically. > * Fixed checkstyle errors > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/pom.xml 2009-02-27 22:57:31 UTC (rev 17099) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/pom.xml 2009-02-28 16:57:59 UTC (rev 17100) > @@ -43,4 +43,25 @@ > <version>${pom.version}</version> > </dependency> > </dependencies> > + <build> > + <plugins> > + <plugin> > +  > + <groupId>org.apache.maven.plugins</groupId> > + <artifactId>maven-checkstyle-plugin</artifactId> > + <dependencies> > + <dependency> > + <groupId>com.xpn.xwiki.platform.tools</groupId> > + <artifactId>xwiki-verification-resources</artifactId> > + <version>${platform.tool.verification.version}</version> > + </dependency> > + </dependencies> I think the <dependencies> part is not needed here since it's already defined in XWiki root pom.xml > + <configuration> > + <includes> > + **/AbstractWikiModelParser.java > + </includes> > + </configuration> > + </plugin> > + </plugins> > + </build> > </project> > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/internal/parser/wikimodel/AbstractWikiModelParser.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/internal/parser/wikimodel/AbstractWikiModelParser.java 2009-02-27 22:57:31 UTC (rev 17099) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/internal/parser/wikimodel/AbstractWikiModelParser.java 2009-02-28 16:57:59 UTC (rev 17100) > @@ -21,7 +21,6 @@ > > import org.xwiki.component.logging.AbstractLogEnabled; > import org.xwiki.rendering.block.XDOM; > -import org.xwiki.rendering.internal.parser.wikimodel.XDOMGeneratorListener; > import org.xwiki.rendering.parser.ImageParser; > import org.xwiki.rendering.parser.Parser; > import org.xwiki.rendering.parser.LinkParser; > @@ -31,30 +30,47 @@ > import java.io.Reader; > > /** > + * Common code for all WikiModel-based parsers. > + * > * @version $Id$ > * @since 1.5M2 > */ > public abstract class AbstractWikiModelParser extends AbstractLogEnabled implements Parser > { > + /** > + * @see #setLinkParser(LinkParser) > + */ > protected LinkParser linkParser; > > + /** > + * @see #setImageParser(ImageParser) > + */ > protected ImageParser imageParser; > - > + > + /** > + * @return the WikiModel parser instance to use to parse input content. > + * @throws ParseException when there's a problem creating an instance of the parser to use > + */ > public abstract IWikiParser createWikiModelParser() throws ParseException; > > /** > - * @return the parser to use for the link labels, since wikimodel does not support wiki syntax in links and they > - * need to be handled in the XDOMGeneratorListener. By default, the link label parser is the same one as the > - * source parser (this), but you should overwrite this method if you need to use a special parser. > + * @return the syntax parser to use for parsing link labels, since wikimodel does not support wiki syntax > + * in links and they need to be handled in the XDOMGeneratorListener. By default, the link label > + * parser is the same one as the source parser (this), but you should overwrite this method if you > + * need to use a special parser. > * @see XDOMGeneratorListener#XDOMGeneratorListener(Parser, LinkParser, ImageParser) > * @see http://code.google.com/p/wikimodel/issues/detail?id=87 > * TODO: Remove this method when the parser will not need to be passed to the XDOMGeneratorListener anymore. > */ > - public Parser getLinkLabelParser() > + protected Parser getLinkLabelParser() > { > return this; > } > > + /** > + * {@inheritDoc} > + * @see Parser#parse(Reader) > + */ > public XDOM parse(Reader source) throws ParseException > { > IWikiParser parser = createWikiModelParser(); > @@ -70,4 +86,26 @@ > } > return listener.getXDOM(); > } > + > + /** > + * Sets the parser to use when parsing links. We need to parse links to transform a link reference passed as a raw > + * string by WikiModel into a {@link org.xwiki.rendering.listener.Link} object. > + * > + * @param linkParser the link parser to use > + */ > + public void setLinkParser(LinkParser linkParser) > + { > + this.linkParser = linkParser; > + } > + > + /** > + * Sets the parser to use when parsing image references (eg "Space.Doc(a)image.png" in XWiki Syntax 2.0). > + * We transform a raw image reference into a {@link org.xwiki.rendering.listener.Image} object. > + * > + * @param imageParser the image parser to use > + */ > + public void setImageParser(ImageParser imageParser) > + { > + this.imageParser = imageParser; > + } > } > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > -- Thomas Mortagne

16 years, 6 months

1
0
0 0

[xwiki-devs] [Proposal] Splitting xwiki-core-url into 2 modules

by Vincent Massol

Hi, In order to implement http://jira.xwiki.org/jira/browse/ XTSHAREDTESTS-12 I need to solve a cyclic dependency it creates: org.xwiki.platform:xwiki-core-url --> com.xpn.xwiki.platform.tools:xwiki-shared-tests --> org.xwiki.platform:xwiki-core-container-api --> org.xwiki.platform:xwiki-core-url I don't see a good solution other than spliting xwiki-core-url into 2 modules (in order to solve the cyclic dep) assumptions: - we need Container in shared tests as otherwise it's going to be a pain for all tests - using reflection in shared tests would mean making sure to have deps on container api in all tests modules - modifying url module to not use shared tests is a bit of a pain and not right IMO - moving XWikiURL to Container API doens't seem right either- - removing Request.getURL() is not right either and it's used in xwiki- action anyway It could be a good idea anyway to separate all modules into 2: api + implementation. However for practical reasons I don't think we'll do that, it's too much of a pain and will result in too many jars. So it's a bit strange to do it for xwiki-url and not for others but again I don't see solutions right now.... If nobody shouts I'd like to commit the url module split quickly (since I have it done and it's blocking me on some other issue). Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

16 years, 6 months

3
2
0 0

[xwiki-devs] [Proposal] JIRA Fix for strategy

by Vincent Massol

Hi, I'd like to clarify the strategy I'd like to propose that we use for JIRA fix for values since we haven't been very consistent about this in the past. Proposed rules: * We put all "fix for" for all places the commits have been done. If the commit has been done on 3 locations then we need 3 fix for values. For ex right now if you commit on trunk + in 1.8 branch you need fix for for *both* 1.8RC2 and 1.9M1. * In the release notes on xwiki.org we only put issues that haven't been already released in past versions. So when 1.9 M1 release notes are written you should exclude 1.8RC2 issues since they would have been released already (1.8RC2 is planned before 1.9M1). WDYT? If we agree can everyone check his jira issues and correct the fix for values? Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

16 years, 6 months

6
7
0 0

[xwiki-devs] [Idea] Switch to annotations for plexus component configuration?

by Vincent Massol

Hi, Here's an idea: use annotations to remove the need for components.xml files. Example: http://svn.apache.org/repos/asf/maven/components/trunk/maven-project/src/ma… Pros: * always correct * simpler maintenance Cons: * small tie with plexus. However the annotations are in small jar file by themselves and are only required at build time and not runtime. I'm not sure yet. WDYT? Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

16 years, 6 months

2
1
0 0

[xwiki-devs] Adding a feedback survey on XWiki.org

by Emilie Ogez

Good suggestions Ecaterina. Thanks. Date: Fri, 27 Feb 2009 13:23:43 +0200 From: Ecaterina Valica <valicac(a)gmail.com> Subject: Re: [xwiki-devs] [Proposal] Adding a feedback survey on XWiki.org To: XWiki Developers <devs(a)xwiki.org> Message-ID: <a7bce70e0902270323v4956de1dvf84cb777590a4810(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 hi. I have some suggestions: 1. You need numbering - you don't have a clear separation between questions. (1, 2, ... ) 2. 5 - "exceptional" - the word is a bit to much. Also the word "dazzled". 3. You need to decide if you want to write everywhere in the survey "Web site" or "website" - I'd recommend website ( http://en.wikipedia.org/wiki/Website). 4. "Are you satisfied with the quantity/quality of *information*?" - what information? Is too general. you could specify -> "the information on our site regarding ... " 5. I'd suggest replacing "*the* website" with "*our *website" to show that is not an ordinary website, that you care :) for the website Emilie - great work - I really want to see the results for the survey

16 years, 6 months

1
0
0 0

[xwiki-devs] [Proposal] Adding a feedback survey on XWiki products

by Emilie Ogez

Arf... Thanks Vincent. Here is the new link: http://dev.xwiki.org/xwiki/bin/view/Drafts/SatisfactionSurveyProducts Date: Fri, 27 Feb 2009 13:19:48 +0100 > From: Vincent Massol <vincent(a)massol.net> > Subject: Re: [xwiki-devs] [Proposal] Adding a feedback survey on XWiki > products > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <026485EA-AFD9-49E5-90F3-98475D5E1A05(a)massol.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 27, 2009, at 12:33 PM, Emilie Ogez wrote: > > >> Hello, >> >> I have started to list questions that could be part of the >> satisfaction >> survey about the XWiki products : >> http://intranet.xpertnet.biz/xwiki/bin/view/XWikiOrgWebsite/XWikiOrgWebsite >> > > People don't have access to that web site... > You can use the draft space on dev.xwiki.org > http://dev.xwiki.org/xwiki/bin/view/Drafts/ > > >> I propose to get first feedback about XWiki Enterprise and XWiki >> Enterprise Manager. So, I have made two different forms. But: >> 1) maybe, one form can be sufficient. >> 2) the questions in each form can be different. >> >> Again, I'd like your feedback about it/them. >> >> Thanks in advance for your help and your time. >> >> Emilie >> > > Thanks > -Vincent > http://xwiki.com > http://xwiki.org > http://massol.net > > > > > > > > > ------------------------------ > > Message: 5 > Date: Fri, 27 Feb 2009 13:35:52 +0100 > From: Vincent Massol <vincent(a)massol.net> > Subject: [xwiki-devs] [VOTE] New XE 1.8 Release dates > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <AE34089C-A97B-47A3-A8E4-91909B33DED4(a)massol.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Hi, > > New proposed dates that take into account the lag in the WYSIWYG dev > for the 1.8 final release. > > * 1.8 RC2 - Stays on 2nd of March > * 1.8 RC3 - 12th of March > * 1.8 final - 16th March > > It would be time boxed, ie we release on the 12th whatever we have > finished on the 11th night. This should allow us to finish most of the > new WYSIWYG stuff. Let us know on the wysiwyg side if anything is at > risk as you progress. > > Here's my +1 > > Thanks > -Vincent > http://xwiki.com > http://xwiki.org > http://massol.net > > > > > > > > > ------------------------------ > > Message: 6 > Date: Fri, 27 Feb 2009 14:59:09 +0200 > From: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> > Subject: Re: [xwiki-devs] [VOTE] New XE 1.8 Release dates > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <49A7E39D.2010702(a)xwiki.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > +1. I'm almost done with macro editing. Macro insertion (browsing > available macros mainly) is next. I'm confident we'll have macro support > ready by 11th March. I might even have time to fix some bugs (there are > 10 assigned to me right now). > > Thanks, > Marius > > Vincent Massol wrote: > >> Hi, >> >> New proposed dates that take into account the lag in the WYSIWYG dev >> for the 1.8 final release. >> >> * 1.8 RC2 - Stays on 2nd of March >> * 1.8 RC3 - 12th of March >> * 1.8 final - 16th March >> >> It would be time boxed, ie we release on the 12th whatever we have >> finished on the 11th night. This should allow us to finish most of the >> new WYSIWYG stuff. Let us know on the wysiwyg side if anything is at >> risk as you progress. >> >> Here's my +1 >> >> Thanks >> -Vincent >> http://xwiki.com >> http://xwiki.org >> http://massol.net

16 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs