xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[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

16 years, 2 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/

16 years, 2 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.

16 years, 2 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.

16 years, 2 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

16 years, 2 months

[xwiki-devs] [Proposal][New Model] Using a new Model API extending the JCR API

by Vincent Massol

Hi, I've started working on our new model again (see http://dev.xwiki.org/xwiki/bin/view/Design/XWikiModel20 for a reminder of what this is about). Right now I'm leaning towards having a typed API but that extends the JCR API. For example: public interface Server extends Repository { /** * @return the list of all wiki names inside this Server */ List<String> getWikiNames(); Wiki getWiki(String wikiName); Wiki createWiki(String wikiName); void addWiki(Wiki wiki); void removeWiki(String wikiName); } or public interface Document extends Node { /** * @return the list of object definitions defined inside this document */ List<ObjectDefinition> getObjectDefinitions(); List<Object> getObjects(); List<Attachment> getAttachments(); void setContent(String content); } As you can see these 2 interfaces extend the JCR interfaces (Repository and Node) which means you either use the typed APIs they expose of the underlying JCR API. For example you could write: $doc.setProperty("xwiki:content", "my new content"); <-- JCR API $doc.save() <-- JCR API or $doc.setContent("my new content"); <-- typed API $doc.save() <-- JCR API This means we'll be tied to the JCR API but I don't see this as a bad thing since this API is a generic document-oriented repository API and doesn't impose any implementation. The alternative would be to use our own API and copy 90% of the existing JCR API and then do the mapping in the implementing classes. Let me know what you think. I'll be committing some interfaces soon at http://svn.xwiki.org/svnroot/xwiki/sandbox/components/xwiki-model/ If you don't agree let me know quickly so that we can discuss it and come to an agreement. On a different but related topic I'm also interested in getting your feedback on the interface names I have created (ObjectDefinition instead of Class, Server for a wiki farm, etc). Thanks -Vincent

16 years, 2 months

[xwiki-devs] [Gsoc - 2009] XWIKI-3337 Jira Issue

by Tharindu Madushanka

Hi, I am interested in solving this Jira issue and I have been working on it. Its about displaying a warning to user when creating a user with a user name that already exists. Issue occurs when adding users from admin account. Below are the given steps to generate it Administration -> 'Users' -> Add New User -> Try creating user with same user name -> Nothing happens (or warning) Adding a user from register button displays warning and uses warnings defined in registerinline.vm called from register.vm template. I have started looking at the xwiki-core code, specifically com.xpn.xwiki.web. What I found is as follows when adding a user with same user name, when creating a new user from RegisterAction class -> xwiki.createUser(true,"edit",context) returns -3 indicating user already exists. And when adding from Administration panel I found it calls a template 'registeruser?ajax=1.vm' that is not in /templates folder. There fore, can you suggest me some steps to display a warning to user, when adding users from Administration panel. It uses Ajax to display 'add new user' UI. Here I am not clear on what template is being called and what to look for the next step. I have just stuck with this. I thought of sending a mail, I would get some points to continue with. Thank you, *H.T.M. Gamage ** *Student,* * Faculty of Information Technology, University of Moratuwa, SriLanka. Mobile: +94 (71) 5518852 Blog : tharindufit.wordpress.com

16 years, 2 months

Re: [xwiki-devs] [xwiki-notifications] r18452 - in platform: skins/trunk/albatross/src/main/resources/albatross skins/trunk/albatross/src/main/resources/albatross/js skins/trunk/albatross/src/main/resources/albatross/js/xwiki skins/trunk/albatross/src/main/resources/albatross/js/xwiki/panelwizard skins/trunk/toucan/src/main/resources/toucan web/trunk/standard/src/main/webapp/resources/js/xwiki/panelwizard

by Sergiu Dumitriu

jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-04-10 18:13:31 +0200 (Fri, 10 Apr 2009) > New Revision: 18452 > > Added: > platform/skins/trunk/albatross/src/main/resources/albatross/js/ > platform/skins/trunk/albatross/src/main/resources/albatross/js/xwiki/ > platform/skins/trunk/albatross/src/main/resources/albatross/js/xwiki/panelwizard/ > platform/skins/trunk/albatross/src/main/resources/albatross/js/xwiki/panelwizard/panelWizard.js > Removed: > platform/skins/trunk/toucan/src/main/resources/toucan/ajax/ > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/panelwizard/panelWizard.js > Log: > XWIKI-3566 : PanelWizard layout manager doesn't allow to change the layout This affected only albatross files, so the issue should be in XSALBATROSS and not in XWIKI -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 2 months

[xwiki-devs] [Proposal] Double-click to edit a page

by Guillaume Lerouge

Hi devs, I'd like to propose adding a new feature for XWiki: double-click to edit a page. *PROS* - It makes page edition real fast and easy from anywhere on the page - 45 wikis have it: http://www.wikimatrix.org/search.php?sid=395 *CONS* - "Users may find this feature irritating, particularly if they are in the habit of double-clicking to select a word (normal browser behaviour)" (from http://www.wikimatrix.org/wiki/feature:Double-Click%20Edit ) - Potential JS side effects? *IMPLEMENTATION IDEAS* - Make the feature configurable through a setting on the user profile: - The same way an user can choose between simple & advanced mode, he could activate/deactivate double-click to edit - It could be added pretty easily to xwiki.js: - $(’xwikimaincontainer’).observe("dblclick", function() {window.location="$doc.getURL(’edit’)"}) *EXAMPLE* You can see a test implementation on this page (double-click anywhere on the page to edit it): http://incubator.myxwiki.org/xwiki/bin/view/Grid/Test If the user setting part isn't too hard to do, it would be worth keeping the feature in mind as a XWiki UX improvement. WDYT? Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/

16 years, 2 months

[xwiki-devs] [Proposal] XWikiXmlRpcClient.searchRegexPageId()

by Venkatesh Nandakumar

Hi devs, I was discussing with Sergiu, relating to http://jira.xwiki.org/jira/browse/XECLIPSE-106 The bug is that when XEclipse is connected to a large wiki, of the order of 5000+ pages, and when ContentAssist is triggered from the editor (using Ctrl+Space, with cursor inside [] tag), it enters a very large loop, and hence is very slow. I found out that :- 1) http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core-xmlrpc-parent/xwik… <http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core-xmlrpc-parent/xwik…> Searches for the the content as well as page id. Therefore, as XWikiXmlRpcClient.search("WebHome", 10) returns :- Blog.WebHome Main.RssFeeds Main.WebHome Panels.PanelWizard Panels.WebHome ... etc which is not what I require. 2) http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core-xmlrpc-parent/xwik…<http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core-xmlrpc-parent/xwik…> is being used in the current implementation(1.4+). This first fetches all the PageIds of the wiki. And then, on the client's end, XEclipse searches for the match with String.startsWith For XWiki Versions less than 1.4, there is a nested for-loop implementation using getSpaces() and getPages(), which is even worse. This is very slow, and large amount of data transfer is required over the network. So, with the backing of Sergiu and Florin :), I propose a new XML-RPC function List<SearchResult> searchRegexPageId(String regex, Integer maxResults, Boolean includeContent) The function is pretty much self-explanatory, with only the PageId's that match regex are being returned, and includeContent checks if Content is to be included for the search. I really don't know if this function would be of use anywhere else but for this application. It would be good to know. Venkatesh Nandakumar Department of Electronics & Computer Engineering Indian Institute of Technology Roorkee

16 years, 2 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