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

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/

16 years, 5 months

2
2
0 0

[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

16 years, 5 months

2
1
0 0

[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

16 years, 5 months

7
8
0 0

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/";

16 years, 5 months

1
0
0 0

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/

16 years, 5 months

2
1
0 0

[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, 5 months

3
3
0 0

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, 5 months

3
4
0 0

[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, 5 months

1
1
0 0

[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, 5 months

3
4
0 0

[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, 5 months

1
0
0 0

[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, 5 months

2
2
0 0

[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, 5 months

3
6
0 0

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, 5 months

1
0
0 0

[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, 5 months

6
5
0 0

[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, 5 months

2
3
0 0

Re: [xwiki-devs] [xwiki-notifications] r18410 - in platform/web/trunk: standard/src/main/webapp/resources/js/smartclient standard/src/main/webapp/templates wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/plugin/link wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/plugin/link/ui wysiwyg/src/main/resources/com/xpn/xwiki/wysiwyg/public/stylesheets

by Jerome Velociter

Hi lucaa (SVN) wrote: > Author: lucaa > Date: 2009-04-10 10:27:02 +0200 (Fri, 10 Apr 2009) > New Revision: 18410 > > Added: > platform/web/trunk/standard/src/main/webapp/resources/js/smartclient/overwritesc.js I think this file should be under a xwiki/ folder to make it clear its not part of the SC framework. A better place IMO would be resources/js/xwiki/smartclient/overwritesc.js [snip]

16 years, 5 months

1
0
0 0

[xwiki-devs] [Proposal] Default mock implementation for the xwiki-bridge component

by Sergiu Dumitriu

Hi devs, All the components that depend on the model bridge need to provide a mock implementation of the bridge, which has as a main disadvantage the fact that the code is hard to updade (if I change the bridge, why would I look inside the office importer?) We currently have 4 mock implementations. A better approach: Make one mock implementation inside the bridge component, which will be packaged in a test package, and which will be used as a test-time dependency when needed. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 5 months

3
3
0 0

[xwiki-devs] [Gsoc-2009] Class level approach for the Photo Album is added

by Harsha Halgaswatta

Hi marta , all I have added the class level approach for the photo album application [1] , after going through some applications. Please have a look and give me any feedbacks [1] : http://docs.google.com/Doc?id=dhh6gcfm_721hhgxstfk Thanks in advance Harsha

16 years, 5 months

1
0
0 0

[xwiki-devs] [VOTE] How to handle large content inside string properties

by Sergiu Dumitriu

Hi devs, While trying to fix XWIKI-1480, the following question was raised: What to do with large values placed inside a StringProperty? StringProperties are defined to hold at most 255 characters (which are actually bytes in mysql). Some databases automatically ignore this limit (this is the case with hsql, which is the default database for our standalone package), while others throw exceptions when trying to commit the transaction (mysql does this). Currently, we don't handle this exception at all, so it bubbles up to the UI in the form of a stack trace. XWIKI-1480 is about fixing this error. What can be done: 1. Always trim the content to 255 bytes. This is a regression from the point of view of hsql users, which will suddenly notice that their data gets truncated. 2. If the data is larger than 255 bytes, silently ignore this new value, and continue using the previous one. This is also bad, since users won't understand why doesn't the value get saved, and is a regression on hsql. 3. Try to use this value, but if an exception is thrown, truncate the data and commit again. This fixes the regression part, but might still be surprising to users. 4. Continue as before, but catch the exception and display a nice warning message to the user. This looks like the safest approach, but it fails when manipulating data from outside the UI, like scripts and XmlRpc connections. So, what is the best approach? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 5 months

4
5
0 0

[xwiki-devs] TaskCode Skin affects display of boxes (e.g. code-macro in XWiki 2.0 Syntax)

by Bernhard Kämpf

Hello all I observed, that the TasksCode-Panel inserts css style definitions to the html-code. Unfortunately this css defines a .box class style. It seems, that this .box class definition affects display of several objects, e.g. the general Comment Box or the box created by the code-macro (when using XWiki 2.0 Syntax). (the code-macro in 2.0 Syntax actually refers to class="box code", but none of the css defines a box.code-class, so obviously the .box class is used). Regards Bernhard Kaempf PS: As a ugly quick fix I hacked the TasksCode Skin (by altering the name of .box class) PPS2: XWikiUserSheet is not displayed under Syntax2.0

16 years, 5 months

1
0
0 0

[xwiki-devs] [GSoC2009] eBay and Apache Shindig for OpenSocial

by Anamaria Stoica

eBay's new Selling Manager (beta) <http://developer.ebay.com/web20> uses Apache Shindig to integrate OpenSocial !! :) http://google-code-updates.blogspot.com/2009/04/ebays-farhang-kassaei-annou… Anamaria

16 years, 5 months

1
0
0 0

[xwiki-devs] [VOTE] Introduce DocumentAccessBridge::setProperty() method

by Asiri Rathnayake

Hi devs, I need to add some tags into a document via officeimporter. For this I need to have above method implemented in DocumentAccessBridge. The most generic method signature would be: void setProperty(String documentName, String className, int objectNumber, String propertyName, Object value) throws Exception; But for my use case following would be enogh: void setProperty(String documentName, String className, String propertyName, Object value) throws Exception; I'm currently +1 for second signature. WDYT? Note: this method has been implemented in issue: http://jira.xwiki.org/jira/browse/XWIKI-2831 but this patch seems to have lot more other (unnecessary) methods. Thanks. - Asiri

16 years, 5 months

2
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r18354 - in platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest: . resources/attachments

by Sergiu Dumitriu

fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2009-04-08 23:58:20 +0200 (Wed, 08 Apr 2009) > New Revision: 18354 > > Modified: > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/XWikiAuthentication.java > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/resources/attachments/AttachmentsResource.java > Log: > XWIKI-3542: Allow attachment upload in REST API using multipart form data > + @POST > + @Consumes(MediaType.MULTIPART_FORM_DATA) > + public Response addAttachment(@PathParam("wikiName") String wikiName, @PathParam("spaceName") String spaceName, > + @PathParam("pageName") String pageName, Multipart multipart) throws MessagingException, IOException, > + XWikiException > + { Fabio, could you change this to support uploading several files in a single request? This would be very useful. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 5 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r18222 - in platform/core/trunk/xwiki-xml/src: main/java/org/xwiki/xml/internal/html/filter test/java/org/xwiki/xml/internal/html

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2009-04-03 10:43:01 +0200 (Fri, 03 Apr 2009) > New Revision: 18222 > > Modified: > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/html/filter/FontFilter.java > platform/core/trunk/xwiki-xml/src/test/java/org/xwiki/xml/internal/html/DefaultHTMLCleanerTest.java > Log: > XWIKI-3494: Font tag is not cleaned properly. > > * Fixed. > + public FontFilter() > + { > + fontSizeMap = new HashMap<String, String>(); > + fontSizeMap.put("1", "8"); > + fontSizeMap.put("2", "10"); > + fontSizeMap.put("3", "12"); > + fontSizeMap.put("4", "14"); > + fontSizeMap.put("5", "18"); > + fontSizeMap.put("6", "24"); > + fontSizeMap.put("7", "36"); > + } Asiri, using pt as font sizes is not good, because it will not fit well with custom skins. It is better to use relative font sizes, using either em or %, like: font size=1 => font-size: 0.6em; or: font-size: 60%; This way, fonts will be made larger or smaller compared to the current skin's normal font size. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 5 months

2
1
0 0

[xwiki-devs] Thoughts about the attachment and image insert

by Ludovic Dubost

I'm having some thoughts about the attachments and image insert. I just tested the current work on attachment link insert. The more I think about it, the more I believe that images and attachments should be mainly attached to the CURRENT page. It is a nice to have to be able to use images or attachments for other pages (and even less upload to another page). However, when I look at the superbe tree UI, I have the feeling it will actually get in the way of the main usage, which is having the file attached to the current page. Therefore I believe we should have 2 different UIs. One simple and one advanced. The simple one would only manager files or images attached to the current page. The advanced would be the tree one. I understand this is more work, but if you ask me, if we should do only one, then it should be the one with file or images in the current page. WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years, 5 months

5
8
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