xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] How to get the page references in javascript

by 许凌志(Jamesxu)

Hi, how can I get the current edit page's details information in javascript like, its space and its page name. Here I found that I can parse the url of the current edit pages, like /xwiki/bin/edit/Main/Newpage?editor=wiki Is there any other better ways for me to get them? -- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University

13 years, 5 months

[xwiki-devs] The plan of GSoC project "Auto-completion in content editors" (7.25 - 7.31)

by 许凌志(Jamesxu)

Hi, Last week I have done following things: 1. Refine the suggest lucene service, and a query "media", which have two options: "xml" and "json", each gives the xml and json results. 2. Thanks Eduard, Marius and Sergiu, with their help, I finnally find the right search queries of suggest lucene service to get right suggestion results. 3. The autosuggestion can use the real datas from xwiki now. In this week, I am going to do the following things: 1. Implement the whole context for link suggestion, include "attach:", "@", "." and "||".( I have done some designations, but still want to discuss with mentors) 2. Consider to implement the ctrl+space to re-open the suggestion box according to the different contexts of link suggestion.(after the 1 is finished) -- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University

13 years, 5 months

[xwiki-devs] The plan of GSoC project "Auto-completion in content editors" (8.8 - 8.14)

by 许凌志(Jamesxu)

Hi, Last week I have done following things: 1. Refine the codes according to the code review of Marius. 2. Add the shortcut for identifying the context of link, and re-generate the suggestions, as Marius's suggestion, the shortcut should be ctrl+space, but I found it the ctrl+space is not working in most of my OS systems, if I change to other shortcuts, like ctrl+any key except 'space', everything will be fine, I search the problem in google, I found the same thing happens in eclipse, I tested it, the ctrl+space is not working in eclipse either. I think the reason might be the shortcut is used for changing text input, like change the the english input method to chinese input method. Unfortunately, there is no good solutions found in google. So, I change the shortcut to ctrl+enter(return). I think another solution is that I make the shortcut configurable. In this week, I will do the following things； 1.Add the default suggestions for sub-trigger "attach:", "." and "@". 2.Refine the suggestion box according to Marius' suggestions in the reply for the mail "The plan of GSoC project "Auto-completion in content editors" (8.1 - 8.7)". 3.Add the relative references for link generation. -- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University

13 years, 5 months

[xwiki-devs] The plan of GSoC project "Auto-completion in content editors" (8.1 - 8.7)

by 许凌志(Jamesxu)

Hi, Last week I have done following things: 1. Implemented the sub-triggers 'attach:', '@', '.' for link autosuggestion. I record a video(see:http://youtu.be/7lXeORkI6Ns) of how to use this triggers under link suggestion context. But still have some problems: a. I didn't implement the trigger for attribute "||", because the suggestion trigger type and behaviour are a bit different from the others, for example, when you type "||" the attributes of the link will be shown, and when user select one, then type '="' the value should be suggested to user, and if user want to add second attributes to the link, he can type "space" key and then the suggestion for available attributes should also be shown. The process are a bit complex, and the cost of implementation is high compare to the utility of the functions. So I decide to abandon this sub-triggers and focus on the trigger "attach:", "@" and "." only which are more useful when user add or edit links. b. Not full tested, I test most cases I can think of, and ask my classmates to use this function and gave me some feedback, I did found some bugs, and fixed them, but I am not very sure some unexcepted bugs will come up c. I didn't implement the default suggestions for "attach:", "." and "@" sub-triggers, I need to discuss with mentor this week. 2. Thanks Marius and Sergiu, with their help, I find all the server side search service for getting the suggestions of the link sub-triggers. 3. Thanks Marius, with his help, I can refine the default Panels.Recent Modified page to get the recent modified pages and attachmens as the default suggestions for link trigger "[[". In this week, I am going to do the following things: 1. Implement the default suggestions for sub-triggers "attach:", "." and "@". 2. Implement the ctrl+space to re-open the suggestion box according to the different contexts of link suggestion. -- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University

13 years, 5 months

[xwiki-devs] [Discussion] XEM Workspaces feature integration issues

by Eduard Moraru

Hi devs, As part of the process of integrating the Workspaces feature into XEM, I have identified certain problematic integration points. == Context== For those that don't know about the Workspaces feature, here's an initial design page that can still be considered relevant with respect to the current prototype http://dev.xwiki.org/xwiki/bin/view/Design/Workspaces Technically, workspaces are subwikis that can be created by any user (not just admins), that handle only global users (don`t allow local users) and that manage 3 types of workspace/subwiki membership (1. open, 2. on request with admin validation and 3. only on invite). The main wiki contains the workspaces application and is the entry-point from where you can create/browse workspaces. Of course, since it's part of the Wiki3.0 research project ( https://wiki30.xwikisas.com ), the main focus is the user and social interactions. The current prototype ( https://github.com/xwiki-contrib/wiki30 and issue tracker http://jira.xwiki.org/jira/browse/WIKITHREEDOTO ) was built as a forked XEM distribution that comes with 2 features (workspaces and real-time editor). == Issues == For the integration of the Workspaces feature (as a XEM extension), the following problems restrict the Workspace feature from overriding certain XWiki elements while extending them: I) Main Wiki level (for the Workspace Manager Application) 1) Extend XWiki.GroupSheet and templates/getgroupmembers.vm - Add 'follow' action to the group's livetable - Add 'comment'(About) and 'tags' columns to the group's livetable 2) Extend XWiki.XWikiUserSheet - Add 'Workspaces' tab with list of joined workspaces and possibility to list their activity. 3) Extend XWiki.SearchSuggestConfig - Show Workspaces in search suggestions without affecting existing ones. 4) Extend menuview.vm - Show 'Workspace' entry in the 'Add' menu - Show 'Workspace Directory' entry in the 'Wiki' menu - Show 'Main Wiki' entry in the 'Wiki' menu II) Workspace level (for the workspace template) 1) Extend Main.Dashboard - Add new widgets(Workspace Information, Top active users, List of available Apps) without affecting the existing ones. -- There should be a clear difference between Gadgets (contain just the code and are reusable), Dashboard descriptor (for taking care of which gadgets to include and how to do the layout) and the Dashboard macro. To add some gadgets in a dashboard from an application, you should only have to override the dashboard descriptor but not also the existing gadgets. 2) Extend XWiki.AdminSheet - Add 'Workspace' sections in the 'Configuration' category - Replace the section 'Users' from 'Users & Groups' category with a 'Workspace Users' section 3) Customize templates/rightsUI.vm - Hide scope selector for Users in rights UI and use global users as default There is always the option of doing all of the above trough JSX, but that is a far from perfect solution. The general topic of these issues is that applications should be allowed to better extend XWiki and should not be confined to only the "content" section of a wiki page. In particular, almost all of these issues require their own thread and can be considered part of bigger problems, but I think it's a good start to list them here and see what discussions come out of them. The goal is to be able to install Workspace Manager on top of XEM without partially overriding certain pages or touching templates so that the upgrade of the underlying XEM is not affected. Any feedback on these issues is greatly appreciated. Thanks, Eduard

13 years, 5 months

[xwiki-devs] [Discussion] Some things that could be integrate in XE/XEM as a result of Wiki3.0

by Eduard Moraru

Hi devs, Based on my previous mail [1], I`ve isolated a small list of stand-alone elements that could be integrated into XE/XEM as a result of the work done on the Wiki3.0 research project: = XE = 1. Add 'Follow' button in GroupSheet's livetable - already done [3][4], needs a final review 1.1 Add 'About' and 'tags' columns in the GroupSheet's livetable. 2. Group Manager/Inviter (invite users to a group) - needs refactoring in order to extract it as an individual feature. = XEM= 3. Wiki descriptor editing from subwiki administration section - needs a bit of refactoring to make wiki descriptor editing and then reuse it for workspace descriptor editing. 4. Main wiki link in the top menu, under the 'Wiki' section to be able to go to the main wiki. I`d like to have your opinion on whether they are desired features to be integrated into XE/XEM. Note: Don`t forget to check out the demo instance [5] I`ve set up at http://wiki30-demo.xwiki.com to get a better view over the work done and, maybe suggest other things that could be reused. Thanks, Eduard ----------------- References: [1] http://xwiki.markmail.org/thread/3cbms22ctbqi4yqp [2] https://wiki30.xwikisas.com/ [3] https://github.com/xwiki/xwiki-platform/pull/14 [4] http://jira.xwiki.org/jira/browse/XWIKI-6770 [5] http://xwiki.markmail.org/thread/xngjqbq6e76owd37

13 years, 5 months

[xwiki-devs] XWiki on Cassandra

by Caleb James DeLisle

I have an instance of XWiki finally running on Cassandra. http://kk.l.to:8080/xwikiOnCassandra/ Cassandra is a "NoSQL" database, unlike a traditional SQL database it cannot do advanced queries but it can store data in a more flexible way eg: each row is like a hashtable where additional "columns" can be added at will. The most important feature of Cassandra is that multiple Cassandra nodes can be connected together into potentially very large "swarms" of nodes which reside in different racks or even data centers continents apart, yet all of them represent the same database. Cassandra was developed by Facebook and their swarm was said to be over 200 nodes strong. In it's application with XWiki, each node can have an XWiki engine sitting on top of it and users can be directed to the geographically closest node or to the node which is most likely to have a cache of the page which they are looking for. Where a traditional cluster is a group of XWiki engines sitting atop a single MySQL engine, this allows for a group of XWiki engines to sit atop a group of Cassandra engines in a potentially very scalable way. In a cloud setting, one would either buy access to a provided NoSQL store such as Google's BigTable or they would setup a number of XWiki/Cassandra stacks in a less managed cloud such as Rackspace's or Amazon's. How it works: XWiki objects in the traditional Hibernate based storage engine are persisted by breaking them up into properties which are then joined again when the object is loaded. A user object which has a name and an age will occupy a row in each of three tables, the xwikiobjects table, the xwikistrings table, and the xwikiintegers table. The object's metadata will be in the xwikiobjects table while the name will be in a row in the xwikistrings table and the age, a number, will go in the xwikiintegers table. The NoSQL/Datanucleus based storage engine does this differently, the same object only occupies space in the XWikiDocument table where it takes advantage of Cassandra's flexibility by simply adding a new column for each property. NOTE: this is not fully implemented yet, objects are still stored serialized. What works * Document storage * Classes and Objects * Attachments * Links and Locks * Basic querying with JDOQL What doesn't work * Querying inside of objects * JPQL/XWQL queries * Document history * Permissions (requires unimplemented queries) * The feature you want I am interested in what the community thinks is the first priority, I can work on performance which will likely lead to patches being merged into master which will benefit everyone or I can work on more features which will benefit people who want to use XWiki as a traditional application wiki but use it on top of Cassandra. You can reply here or add comments to the wiki ;) Caleb

13 years, 5 months

[xwiki-devs] Restlet upgrade / Breaking APIs

by Jerome Velociter

Hello devs, I finally found a way to work with an issue in our REST annotation API that prevented to upgrade to Restlet 2.0.8 (see http://jira.xwiki.org/jira/browse/XWIKI-6632). The upgrade introduces some non-backward compatible change in 5 classes in the REST server module. Mostly Restlet plumbing (that probably should have been in an internal package in the first place). You can see the incriminated classes here : https://github.com/jvelo/xwiki-platform/commit/ebda7e5792839a89164f9fa27c15… If anyone here knows of any reason why this classes should not be broken, let them speak now, or forever hold their peace. Peace, Jerome

13 years, 5 months

[xwiki-devs] [Discussion] Defining Sheets

by Marius Dumitru Florea

Hi devs, A prerequisite for Application Within Minutes [1] is to be able to specify the sheet that will be used to display a document without touching the content of that document [2]. This can be done in multiple ways, depending on how we define the notion of a sheet. (1) Class sheets vs. document sheets A class sheet displays an object of a particular type and is specified in the definition of that type. This means that when you create or edit a class, i.e. a type of object, you can specify which sheet should be used to display the instances of that class. Pro: Documents don't have to specify a sheet. Con: We have to determine which sheet to use in case there are multiple objects attached to a document. A document sheet displays a document of a particular type and is specified at document level because the document type, unlike the xclass, does not exist actually. The document type is inferred from the type of objects the document has, or from its content, or, why not, from the type of attachments it has. Pro: Doesn't have the class sheet con. Con: Each document has to specify which sheet to use. Class sheets are enough for Application Within Minutes because the wizard will create a single class (with a sheet) and so the application items will have only one object that specifies a sheet. (2) Separate sheets per action? The current practice is to define a single (class) sheet which either checks for the current action in its code or uses doc.display method whose output is action specific. How often did you had the need to write separate sheets per action (e.g. create, view, edit, search, changes)? (3) Which actions require a sheet? If we're talking about class sheets then the list of actions that target an object and which require a sheet is limited. Currently we have "view" and "edit", but Ludovic proposed also "create", "search" and "changes". If we're talking about document sheets then we can have custom actions and so we need an extensible mechanism to map actions to sheets. (4) Sheet parameters? If we're talking about class sheets then they only need to specify how an object is displayed. Document sheets on the other hand may need to control elements like: * which tabs (comments, annotations, attachments, etc.), if any, are displayed * show title field in edit mode * the side panels * the form buttons WDYT? Thanks, Marius [1] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes [2] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…

13 years, 5 months

Re: [xwiki-devs] Need help on creating virtual xwiki using API

by Eduard Moraru

Hi Karamjit, WikiManager plugin requires admin rights for handling subwikis. See http://jira.xwiki.org/jira/browse/XEM-113 for details and a workaround. Thanks, Eduard On Jul 31, 2011 5:08 PM, "Karamjit Singh" <karamjitmult(a)gmail.com> wrote: > > Yes. I have installed it already. I am getting bellow error message > " you donot have create wiki rights" > > Looks like a permission issue. Any idea how to set user in wikicontext? > On Jul 31, 2011 7:23 PM, "Eduard Moraru" <enygma2002(a)gmail.com> wrote: > > Hi Karamjit, > > > > On Sun, Jul 31, 2011 at 2:13 PM, Karamjit Singh <karamjitmult(a)gmail.com > >wrote: > > > >> Hi Team, > >> > >> I am not able to create virtual xwiki through the XwikiManagerPluginAPI. > I > >> have developed just sample restful web service. Below is the code which I > >> am > >> using to create virtual xwiki :- > >> > >> @Component("org.sisgma.xwiki.rest.HelloWorldResource") > >> @Path("/hello/") > >> public class HelloWorldResource extends XWikiResource { > >> public HelloWorldResource(){ > >> } > >> @GET > >> public String get(@DefaultValue("world") String myresourcename) throws > >> XWikiException, QueryException { > >> XWikiContext ctx = Utils.getXWikiContext(componentManager); > >> try { > >> WikiManagerPluginApi aoi = > >> > >> > (WikiManagerPluginApi)ctx.getWiki().getPluginApi(WikiManagerPlugin.PLUGIN_NAME, > >> ctx); > >> ctx.setDoc(new XWikiDocument(new DocumentReference("jaspreet", "space", > >> "page"))); > >> System.out.println("_____________********* deleting xwiki"); > >> aoi.deleteWiki("neenu", true); > >> aoi.deleteWiki("neenu1", true); > >> aoi.deleteWiki("karam", true); > >> System.out.println("_____________********* deleted xwikies"); > >> System.out.println("_____________********* Creating new xwiki"); > >> aoi.createNewWiki("jaspreet", "templatexe", > null,aoi.createWikiDocument(), > >> true); > >> > > > > Did you install the default template "templatexe"? > > > > > >> } catch (XWikiException e) { > >> e.printStackTrace(); > >> } > >> System.out.println("_____________********* " +ctx); > >> System.out.println("_____________"+ctx); > >> return "Hello " + myresourcename; > >> } > >> } > >> > >> Above code is not working. Virtual xwiki is not being created using the > >> API. > >> > > > > You should share the stack trace of the exception that is thrown. > > > > Thanks, > > Eduard > > > > > >> It is very urgent. Please help. > >> > >> Thanks > >> Karamjit. > >> _______________________________________________ > >> devs mailing list > >> devs(a)xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

13 years, 5 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