xwiki-devs April 2009

xwiki-devs@xwiki.org

52 participants
137 discussions

[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

15 years, 8 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

15 years, 8 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/

15 years, 8 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/

15 years, 8 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

15 years, 8 months

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]

15 years, 8 months

[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/

15 years, 8 months

[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

15 years, 8 months

[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/

15 years, 8 months

[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

15 years, 8 months

← Newer
1
...
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