xwiki-devs April 2009

xwiki-devs@xwiki.org

52 participants
137 discussions

Re: [xwiki-devs] [xwiki-notifications] r18649 - in xoffice/trunk/xword: XWikiLib XWord

by Sergiu Dumitriu

fciubotaru (SVN) wrote: > Author: fciubotaru > Date: 2009-04-14 19:28:28 +0200 (Tue, 14 Apr 2009) > New Revision: 18649 > > Modified: > xoffice/trunk/xword/XWikiLib/XWikiLib.csproj > xoffice/trunk/xword/XWord/AddinActions.cs > xoffice/trunk/xword/XWord/XWikiAddIn.cs > Log: > XOFFICE-74 Navigation Pane does not auto-refresh the tree view when creating a new page > Patch submited by Teofil Achirei, reviewed by Florin Ciubotaru > public string currentPageFullName = ""; > + > /// <summary> > + /// Specifies if the current page was published on the server. > + /// It does not specify if the last modifications were saved, but > + /// if the local document has a coresponding wiki page. It's FALSE > + /// until first saving to wiki. > + /// </summary> Shouldn't properties start with uppercase? I thought that's the convention. > + public bool currentPagePublished = false; > + /// <summary> -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 8 months

[xwiki-devs] inheritance or new datatype ?

by Benoît Benoît

Hi devs, It is possible to define two XWiki classes with a relationship of inheritance? Example: I have MyDocumentClass and MyHeaderClass, it is possible to say all properties of MyHeaderClass are properties of MyDocumentClass ? Maybe I should prefer composition to inheritance ;-) So, can I define a new datatype (like Number, String, TextArea, …), and create a propertie of type MyHeaderClass in the definition of MyDocumentClass ? Thanks, Benoît

15 years, 8 months

[xwiki-devs] [Proposal] New XE 2.0 Proposal

by Vincent Massol

Hi, I had already proposed a strategy for XE 2.0 in this thread: http://tinyurl.com/dacg4q Namely the idea was to release 1.9 final on the 1st of June and promote it as 2.0 on the 15th of June. Several persons have raised some objection privately to me and thus I'd like to make a new proposal: * We still release 1.9 for the 1st of June * We consider the 2.0 release as a normal release that we release early September: - 2.0 M1: 22 June 2009 - 2.0 M2: 13 July 2009 - 2.0 M3: 3 Aug 2009 - 2.0 RC1: 17 Aug 2009 - 2.0 RC2/Final: 31 Aug 2009 * During the 2.0 development period we continue fixing bugs and stabilizing the platform: - wysiwyg, rendering, office import - search w/ lucene plugin - known outstanding bugs * We add a new skin * We continue adding UI improvements Note that we must be careful not to overload ourselves since almost everyone will be a mentor for the GSOC and we'll have a lot of students to mentor during the summer. That'll probably slow us down by half during the GSOC period. Here's my +1 Thanks -Vincent

15 years, 8 months

Re: [xwiki-devs] [xwiki-notifications] r18667 - platform/web/trunk/standard/src/main/webapp/resources/js/smartclient

by Vincent Massol

On Apr 15, 2009, at 11:06 AM, jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-04-15 11:06:06 +0200 (Wed, 15 Apr 2009) > New Revision: 18667 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/ > smartclient/initsc.js > Log: > XWIKI-3583 : Smartclient skin fail to load in specific environments > > Fixed. > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/ > smartclient/initsc.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/ > smartclient/initsc.js 2009-04-15 08:55:43 UTC (rev 18666) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/ > smartclient/initsc.js 2009-04-15 09:06:06 UTC (rev 18667) > @@ -1 +1,5 @@ > -var isomorphicDir = "$xwiki.getSkinFile('js/smartclient/')"; > +// > +// TODO : When XWIKI-3582 will be fixed we'd better use the line > above. s/above/below/ You might also add that the reason getSkinFile should be used is that it allows overriding js files in skins. Thanks -Vincent > > +// var isomorphicDir = "$xwiki.getSkinFile('js/smartclient/')"; > +// > +var isomorphicDir = "${request.getContextPath()}/resources/js/ > smartclient/";

15 years, 8 months

Re: [xwiki-devs] [xwiki-notifications] r18646 - in xoffice/trunk/xword: Wiki/src/main/resources/MSOffice XWikiLib/Clients XWikiLib/XWiki

by Sergiu Dumitriu

fciubotaru (SVN) wrote: > Author: fciubotaru > Date: 2009-04-14 18:57:01 +0200 (Tue, 14 Apr 2009) > New Revision: 18646 > > Added: > xoffice/trunk/xword/XWikiLib/XWiki/XWikiURLs.cs > Removed: > xoffice/trunk/xword/XWikiLib/XWiki/XWikiURLFactory.cs > Modified: > xoffice/trunk/xword/Wiki/src/main/resources/MSOffice/GetEncodingService.xml > xoffice/trunk/xword/XWikiLib/Clients/XWikiHTTPClient.cs > Log: > XOFFICE-39 Save and send data using the encoding of the wiki. > [FIFUP] - Corrected badly named property and added alias for System.Text namespace This is still GetEncoding... > + public static String GetEncoding > + { > + get { return getEncoding; } > + set { getEncoding = value; } > + } > + } > +} -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 8 months

[xwiki-devs] [VOTE] Expose getXWikiPreference(String name, String fallback, String defaultValue) in XWiki API

by Marius Dumitru Florea

Hi devs, I propose to make a wrapper for this method: XWiki#getXWikiPreference(String prefname, String fallback_param, String default_value, XWikiContext context) in api.XWiki. I'm going to allow the users to enable or disable WYSIWYG plugins from within XWikiPreferences with a fallback on xwiki.cfg. I need this asap because I have selenium tests for plugins that are disabled by default and I want to be able to enable the plugins before running the tests. Here's my +1. Thanks, Marius

15 years, 8 months

Re: [xwiki-devs] [xwiki-notifications] r18638 - in xoffice/trunk/xword: Wiki/src/main/resources/MSOffice XWikiLib XWikiLib/Clients XWikiLib/XWiki XWord

by Sergiu Dumitriu

fciubotaru (SVN) wrote: > Author: fciubotaru > Date: 2009-04-13 21:19:15 +0200 (Mon, 13 Apr 2009) > New Revision: 18638 > > Added: > xoffice/trunk/xword/Wiki/src/main/resources/MSOffice/GetEncodingService.xml > xoffice/trunk/xword/XWikiLib/Clients/InvalidEncodingNameException.cs > Modified: > xoffice/trunk/xword/XWikiLib/Clients/IXWikiClient.cs > xoffice/trunk/xword/XWikiLib/Clients/XWikiHTTPClient.cs > xoffice/trunk/xword/XWikiLib/Clients/XWikiXMLRPCClient.cs > xoffice/trunk/xword/XWikiLib/XWiki/XWikiURLFactory.cs > xoffice/trunk/xword/XWikiLib/XWikiLib.csproj > xoffice/trunk/xword/XWord/AddinActions.cs > Log: > XOFFICE-39 Save and send data using the encoding of the wiki. > Patch submitted by Cristina Scheau, reviewed by Florin Ciubotaru. > > Added: xoffice/trunk/xword/Wiki/src/main/resources/MSOffice/GetEncodingService.xml > =================================================================== > --- xoffice/trunk/xword/Wiki/src/main/resources/MSOffice/GetEncodingService.xml (rev 0) > +++ xoffice/trunk/xword/Wiki/src/main/resources/MSOffice/GetEncodingService.xml 2009-04-13 19:19:15 UTC (rev 18638) > @@ -0,0 +1,61 @@ > +<?xml version="1.0" encoding="ISO-8859-15"?> > + > +<xwikidoc> > +<web>MSOffice</web> > +<name>GetEncodingService</name> > +<language></language> > +<defaultLanguage>en</defaultLanguage> > +<translation>0</translation> > +<parent></parent> > +<creator>XWiki.Admin</creator> > +<author>XWiki.Admin</author> > +<customClass></customClass> > +<contentAuthor>XWiki.Admin</contentAuthor> > +<creationDate>1239491696000</creationDate> > +<date>1239493018000</date> > +<contentUpdateDate>1239493018000</contentUpdateDate> > +<version>2.1</version> Normally we set the document version to 1.1... > +<title>GetEncodingsService</title> > +<template></template> > +<defaultTemplate></defaultTemplate> > +<validationScript></validationScript> > +<comment></comment> > +<minorEdit>false</minorEdit> > +<syntaxId>xwiki/1.0</syntaxId> > +<hidden>false</hidden> ... and we remove the tag object when committing wiki documents. > +<object> > +<class> > +<name>XWiki.TagClass</name> > +<customClass></customClass> > +<customMapping></customMapping> > +<defaultViewSheet></defaultViewSheet> > +<defaultEditSheet></defaultEditSheet> > +<defaultWeb></defaultWeb> > +<nameField></nameField> > +<validationScript></validationScript> > +<tags> > +<cache>0</cache> > +<displayType>input</displayType> > +<multiSelect>1</multiSelect> > +<name>tags</name> > +<number>1</number> > +<prettyName>Tags</prettyName> > +<relationalStorage>1</relationalStorage> > +<separator> </separator> > +<separators> ,|</separators> > +<size>30</size> > +<unmodifiable>0</unmodifiable> > +<values></values> > +<classType>com.xpn.xwiki.objects.classes.StaticListClass</classType> > +</tags> > +</class> > +<name>MSOffice.GetEncodingService</name> > +<number>0</number> > +<className>XWiki.TagClass</className> > +<guid>9fd947e4-3ebe-41b0-ba90-2cd80b3c7df3</guid> > +<property> > +<tags/> > +</property> > +</object> > +<content>$xwiki.getEncoding()</content> > +</xwikidoc> > \ No newline at end of file > > Added: xoffice/trunk/xword/XWikiLib/Clients/InvalidEncodingNameException.cs > =================================================================== > --- xoffice/trunk/xword/XWikiLib/Clients/InvalidEncodingNameException.cs (rev 0) > +++ xoffice/trunk/xword/XWikiLib/Clients/InvalidEncodingNameException.cs 2009-04-13 19:19:15 UTC (rev 18638) > @@ -0,0 +1,11 @@ Shouldn't there be a license header in here? I've looked, and it seems that most XWord source files don't have such a header, which is wrong. > +using System; > +using System.Collections.Generic; > +using System.Linq; > +using System.Text; > + > +namespace XWiki.Clients > +{ > + class InvalidEncodingNameException : Exception > + { > + } > +} > > Modified: xoffice/trunk/xword/XWikiLib/XWiki/XWikiURLFactory.cs > =================================================================== > --- xoffice/trunk/xword/XWikiLib/XWiki/XWikiURLFactory.cs 2009-04-13 18:25:16 UTC (rev 18637) > +++ xoffice/trunk/xword/XWikiLib/XWiki/XWikiURLFactory.cs 2009-04-13 19:19:15 UTC (rev 18638) > @@ -16,6 +16,7 @@ > static String wikiStructureURL = "/xwiki/bin/view/MSOffice/StructureService?xpage=plain"; > static String attachmentServiceURL = "/xwiki/bin/view/MSOffice/AttachmentService?xpage=plain"; > static String protectedPagesURL = "/xwiki/bin/view/MSOffice/ProtectedPages?xpage=plain"; > + static String getEncoding = "/xwiki/bin/view/MSOffice/GetEncodingService?xpage=plain"; I don't like this. URLs are pretty configurable, and this hardcoding makes it impossible for XWord to work with a non-default installation of XWiki. There should be a configurable prefix, which is used to construct the final URLs. I've also looked at this class as a whole, and it doesn't look like a Factory. Using the wrong name for a thing is bad, since somebody new to the code will waste important time trying to figure out why he doesn't see the factory in there. If this class will change in the future (once the communication mechanism is replaced) to behave like a factory, then you should write a class comment stating that although it doesn't look like a factory yet, it will soon be one. > /// <summary> > /// Gets or sets the URL of the service that handles attachments. > @@ -72,5 +73,15 @@ > get { return protectedPagesURL; } > set { protectedPagesURL = value; } > } > + > + /// <summary> > + /// Gets the encoding of the wiki. > + /// </summary> > + public static String GetEncoding > + { > + get { return getEncoding; } Can you set a Get* member? Weird... > + set { getEncoding = value; } > + } > + > } > } -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 8 months

[xwiki-devs] Poll Application Modified (Suggestion Field Added)

by Chathura Prabuddha

> > Hai... As I discussed with *Sergiu, *I had added the suggestion field to the poll application. Please look the attachment. Importance of suggestion field to poll application: Using this people can have a chance to raise their opinion. ex: A company is having a poll to decide whether they are going to play soccer match on Sunday (Yes/No) By using the suggestion field people who don't like both of the options can suggest to going on a trip instead of that. Changes Made: PollSuggestionClass: Added PollSheet:Modified PollViewSheet:Modified PollEditSheet:Modified Please give me a feedback about the relevant modification that I have to do. Thank you. -- ~ Chathura Prabuddha Ganegoda~ Undergraduate, Department of Computer Science & Engineering, University of Moratuwa, Sri Lanka.

15 years, 8 months

[xwiki-devs] terminology rumble: Applications vs. Extensions vs. Plugins

by Jerome Velociter

Hey, Yesterday, Vincent introduced a "Modules" section on code.xwiki.org to host XWiki components documentation. From that we had a conversation on IRC about terminology of categories on code.xwiki.org. My observation was that we have some applications that are not really such since they do not offer features to users, but only to developers. Take the date picker application (http://code.xwiki.org/xwiki/bin/view/Applications/DatePickerApplication) : it is not self-standing, this is just for developers that needs a date picker in their apps. I proposed we add an "Extensions" category that would host Skin eXtensions (JSX and SSX) and applications such as the datepicker would fit in there. But as Vincent remarked, we already have an extension category for "an application or script that integrates or interacts with XWiki". In the end, I'll come here with Vincent's idea of merging such extensions with plugins, and then have the following categories : * Plugins: A plugin is everything that brings new functionality to the wiki, but that does not necessarily expose it to end users. There will be two main kinds of plugins: Front-end plugins (that will mostly come under the form of SX), as the date picker will be for example, and Back-end plugins, which can be of various form, such as an old fashioned xwiki plugin (grand'ma style), or a xwiki component with a velocity bridge, etc. To sum up, plugins bring *functionalities to developers*. * Applications: An application will stay what it is today : something an administrator can install on its wiki and that provides functionality to end-users, directly visible/exploitable without the need of more programming. This mean a SX that do such is an application, for instance this is how the Ratings application (http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-application-ratings/) is made. To sum up, applications bring *functionalities to the end users*. Conclusions: Skin eXtensions will remain only a technical term to designate what they are as platform feature. This is for us, the knowledgeable gurus ; on code.xwiki.org we will offer only plugins and applications. As for icons to represent those two ideas (both on code.xwiki.org and in the future in XE) - since this is what matters in the end, icons :) - I propose we use application.gif for Applications and plugin.gif for Plugins from the silk set. Pretty straightforward, eh ;) WDYT ? Jerome.

15 years, 8 months

[xwiki-devs] XWiki Enterprise 1.8.1 and XWiki Enterprise Manager 1.6.1 Released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.8.1 and XWiki Enterprise Manager 1.6.1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This release contains 118 big bugfixes and enhancements. Most of the modifications are targeting the general replacement of old 1.0 code and content by 2.0 syntax and architecture and the stabilization of XWiki. Summary of changes since XWiki Enterprise 1.8 : * Many WYSIWYG bugs fixed and improvements * Many 2.0 syntax bugs fixed * Many 1.0 to 2.0 conversion bugs fixed * Several XMLRPC and REST, LDAP, Office importer and Wiki Explorer bugs fixed and improvements * Many bug fixes in many other places For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise181 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM161 Thanks -The XWiki dev team

15 years, 8 months

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2009