xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Re: [xwiki-devs] Poll/Survey Application - GSoC 2012

by Ecaterina Moraru (Valica)

Hi Rauf, First of all the discussions related to GSOC projects is best if they are public: other people could be interested in the subject, multiple mentors/community could respond to your questions. On Sat, Mar 31, 2012 at 11:57, Rauf Butt <raufbutt(a)gmail.com> wrote: > Dear Caty, > > Thanks for your response. After initial study of XWiki, below are my > findings > > 1. The database schema of XWiki is based on SQL and can be used with any > Sql based database but by default is MySql. > 2. There is an application to create polls at > http://extensions.xwiki.org/xwiki/bin/view/Extension/Polls+Application but > in this project, we need to create a widget. May be to embed the existing > poll application into a widget? > Regarding the exact details of this project idea, Ludovic would be best person to answer the questions. IMO could be the first objective to integrate the existing Polls application as a widget/gadget that could be integrated inside our Dashboard. See http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard+Macro in order to find out more about how to use gadgets inside XWiki. The only difference between the Dashboard and the Polls application is that the Dashboard is already bundled with XWiki Enterprise, while the Polls Application is just a community extension. So the first step in reusing that code would be to analyze how much work would be to integrate the Polls code into the official bundled code, if it's the right solution, how much work is needed to combine Polls with AppWithinMinutes / Dashboard. 3. To create Survey, we would be using the available application: > http://extensions.xwiki.org/xwiki/bin/view/Extension/App+Within+Minutes+App…. > The demos show how to create applications with this extension. > > The idea behind AppWithinMinutes is to empower users to easily create applications. I think Ludovic wants to give users the ability to easily create Polls/Surveys, spread them (maybe by having them as gadget inside the Main.Dashboard) and analyze them at the end of the poll. > The project requirements include to modify the presentation (GUI) for this > survey and to display the survey results. > > Please correct me if there is some misunderstanding. > Should be correct. Thanks, Caty > > Kind Regards, > Rauf > > > > On 23 March 2012 11:35, Ecaterina Moraru (Valica) <h> wrote: > >> Hi Rauf, >> >> You should play with >> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/App+Within+Minutes+App… >> >> also install from extensions >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Polls+Application >> >> For the development documentation see >> http://dev.xwiki.org/xwiki/bin/view/Main/WebHome >> http://platform.xwiki.org/xwiki/bin/view/DevGuide/WebHome >> >> Thanks, >> Caty >> >> On Wed, Mar 21, 2012 at 03:11, Rauf Butt <raufbutt(a)gmail.com> wrote: >> >> > Dear Team XWiki, >> > >> > >> > I am very excited to contribute in open source community through the >> > platform of GSoC 2012. Last year, I contributed "Debugger Visualizers" >> to >> > MonoDevelop which had successfully become a part of Mono Develop. >> > >> > >> > >> > I have seen project ideas for GSoC 2012 at >> > http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome. I am >> > interested in "*Poll/Survey Application*". The reason for my interest is >> > that I have good working experience of HTML, Javascript, Java and >> related >> > technologies. I also checked out XWiki to start understanding it. >> > >> > >> > >> > My understanding of the requirements is as follows: >> > >> > >> > >> > 1. Create a Poll widget to include within a web page. >> > >> > 2. Show Poll results within the Poll widget. >> > >> > 3. Use AppWithinMinutes XWiki to create surveys. >> > >> > 4. Develop the look and feel of such surveys (GUI). >> > >> > 5. At the end of survey, show the results of survey. >> > >> > >> > >> > Have you got a template for the survey GUI or we need to brain storm on >> > this? >> > >> > What database/file storage would be used to store Poll/Survey results? >> > >> > >> > Your kind feedback would help me in better recognising the core project >> > requirements and develop a good proposal. >> > >> > >> > Regards, >> > >> > >> > >> > Rauf >> > >> > Regent's College London >> > _______________________________________________ >> > 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 >> > >

12 years, 9 months

[xwiki-devs] Ideas for GSoC 2012

by Gianluca Sabena

Dear all, Some ideas for GSoC 2012: - Native Ace code editor support I think the future is to code online in the browser, I would like to see Ace Editor http://ace.ajax.org/ integrated in Xwiki as a native editor (not only for some objects), as an alternative to the wysiwyg, text and htmlarea editors for pages. The editor must support html, javascript, velocity and java syntax. The use case is: be able to write velocity ad groovy code in pages with a gui editor. - Node.js extension for real time editor I think in order to enhance collaboration we need a real time editor. I would like to see node.js integrated in Xwiki. In order to keep the architecture simpler I guess we could think to a "editing session". Use case: - three users wont to modify a page - they open a node.js session with the page content - work there - save the page back - we could use restful api to allow node.js to communicate with xwiki - Spreadsheet support I guess xwiki leaks spreadsheet support. This could be great for budgeting and control, in order to reduce attached excel files and move to a real collaboration over data. The Sheetserve community edition could be a source of inspiration http://extentech.com/estore/product_detail.jsp?showdetails=true&product_id=… (PS: Why don't move to Google groups for a better and simpler mailing- list management?) Thank you, Gianluca Sabena - - - - - - - - - - - - - - - - - - - www.intertesto.com - - - - - - - - - - - - - - - - - - - gianluca.sabena(a)intertesto.com skype: gianluca.sabena

12 years, 9 months

Re: [xwiki-devs] GSoC 2012

by sasinda rukshan

Hi all, I am Sasinda Rukshan from University of Moratuwa Sri Lanka. I created a proposal for the Google Android XWiki Connector. link : http://dl.dropbox.com/u/30342197/x%20wiki.pdf (failed to attach it to the mail and send as the mail bounced back alerting the file is too big. : 603KB) Thank you. Sasinda Rukshan. On Sun, Apr 1, 2012 at 2:55 PM, sasinda rukshan <sasindarukshan(a)gmail.com>wrote: > Hi, > > I am Sasinda Rukshan from University of Moratuwa Sri Lanka. > I have attached here with a proposal for the Google Android XWiki > Connector. > > Thank You. > > Sasinda Rukshan. >

12 years, 9 months

[xwiki-devs] Using MacroTransformationContext outside of Macro execution

by Grüner Heinrich

Hi, I want to parse XWiki Syntax in a independent thread (not via xwiki default transformation workflow). how is it possible to intantiate a valid MacroTransformationContext? This Context is needed to call the contentParser. I tried this: MacroTransformationContext mc=new MacroTransformationContext(new TransformationContext()); mc.setSyntax(Syntax.XWIKI_2_0); contentParser.parse(ts.getContent(),mc,true,true); but it threw the following Exception: org.xwiki.rendering.macro.MacroExecutionException: Failed to parse content [ == Werner == * test ] at org.xwiki.rendering.internal.macro.DefaultMacroContentParser.parseXDOM(DefaultMacroContentParser.java:122) at org.xwiki.rendering.internal.macro.DefaultMacroContentParser.parse(DefaultMacroContentParser.java:77) at org.centauron.xwiki.XWikiConnector.getCodeSnipsFromPage(XWikiConnector.java:117) at org.centauron.xwiki.XWikiConnector.getCodeSnipsFromPage(XWikiConnector.java:105) ... Any suggestions? Thanks, Stefan.

12 years, 9 months

[xwiki-devs] [VOTE] Changing our deprecation strategy

by Vincent Massol

Hi devs, I'd like to change our deprecation strategy. Here's what we are currently supposed to use (we voted it a long time ago): http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HDepreca… " In addition our rule is to keep @deprecated methods/classes for 2 final releases after the version where they were first added has been released as final. For example if a method is deprecated in, say XE 1.3M2 then the method will be removed in 1.6M1 or after. Of course any major new release can deprecate anything. For example a XWiki 2.0 release is allowed to break backward compatibility (obviously we need to be careful to offer a migration path for users of previous major versions). " Issues: * This seems a bit harsh to me for some of our users/devs in the community. * We're not following which proves to me it's not a good rule * It doesn't say anything about Scripting APIs which require a greater stability in order not to break all wiki pages Definition of a Scripting API: * a Script Service (that's the new way of providing script apis) * a class in the "api" package in xwiki-platform-oldcore (this is the old way of providing script apis) Thus I'd like to propose this new rule: * Deprecated methods can only be removed in the next Release Cycle. For example something deprecated in version N.x can be removed in version N+1.y where x and y can be anything. This is logical since N+1 means a new major release and it's common to understand that major releases have no guarantee of API compatibility (See http://en.wikipedia.org/wiki/Software_versioning for example). * For scripting APIs we can remove deprecated API only after 4 Release Cycles. For example since we're in 4.x this means we can remove deprecated APIs from 0.x releases. And when we start 5.x we will be able to remove deprecated scripting apis deprecated in 1.x. Here's my +1 Thanks -Vincent

12 years, 9 months

[xwiki-devs] [ANN] Legacy modules are now only built when the "ci" profile is active

by Vincent Massol

Hi devs, I've made the following change today: * Legacy modules are not built nor packaged anymore by default when you build commons, platform and enterprise. * They are still built and packaged when the ci profile is activated and thus Jenkins still generates and run tests with legacy modules active (as before) This allows: * To speed up the developer builds (on my machine I win 2 minutes by not building commons and platform legacy modules) * Developers run without legacy modules by default which mean they can discover when we have wiki pages still using deprecated apis that have been moved to legacy Next step (that will require a vote) will be to provide a package without legacy modules for end users (details to be discussed too). Thanks -Vincent

12 years, 9 months

[xwiki-devs] [VOTE] Temporary make sure a BaseObject cannot target a class coming from another wiki

by Thomas Mortagne

Hi devs, we have an important inconsistency that we ignored since a long time and that is producing http://jira.xwiki.org/browse/XWIKI-7628. The main issue is that the storage save document containing object linked explicitly to another wiki without complaining which mean that user continue using API wrongly without really knowing it's wrong. And now we have lots of code badly using object class related API and contently creating object with absolute class references. Until now it was OK even if a mess and it's still not visible. But that's mostly luck... until we start copying documents from one wiki to another starting with 4.0 branch. What changed is that the unique identifier of the object in the database is "properly" generated by using it's reference and since a class reference in a BaseObject contain a wiki it's now taken into account. The old id generator used to use the deprecated BaseCollection#getClassName which is forced absolute for retro-compatibility reason even if it was actually possible before to put absolutely anything as class reference. So right now we have two issues: * store save invalid document without complaining * many code is wrongly using BaseObject and XWikiDocument API regarding class references mostly because you don't really see it right away when you don't use it properly. Even ObjectAddAction is wrong, a lot of code that was using setClassName has been badly converted to fix deprecated method code by resolving what was passed to setClassName into an absolute reference which is very wrong and not the behavior of setClassName. Here is what we propose with Denis: * 4.x (or until class coming from another wiki is supported but I doubt this is going to happen anytime soon with this storage): ** throw an exception in the storage when saving a document containing objects coming from another wiki ** to temporary limit breakage while we fix wrong code and help us find this wrong code, modify BaseCollection#setXClassReference to force it to remove the wiki from the passed reference and log a warning about a bad usage * 5.0: remove the bandage from BaseCollection#setXClassReference WDYT ? Here is my +1 -- Thomas Mortagne

12 years, 9 months

[xwiki-devs] Questions about Blog Example

by du du

Hi, all I am studying the BlogClass, BlogPostClass, I checked the Blog.BlogCode, there are alot of velocity scripts, I can see the search documents from db, but could not find any code related to insert document records into database, so how is the document created from blog saved into database? please point me to the script code in the Blog.BlogCode. Thanks Dave

12 years, 9 months

[xwiki-devs] [VOTE] Merge experimental xwiki-platform-security on master

by Denis Gervalle

Hi all, As you have probably notice, I have recently committed an feature-security-authorization branch on platform. I am working on this for a while now and it was the first step to share the outcome of this large refactoring of the initial work done early last year by Andreas. Since the code was not quality compliant with platform but the general structure Andreas has build seems to me well appropriate, I have progressively refactor its code to better fit our real needs. Here is what I have been done: 1) Split in to module api and bridge to allow breaking the currently unavoidable dependency on oldcore. Now only bridge depends on oldcore, and the api does not depends on bridge. As mush as possible has been written in the api (still some code to migrate), and some temporary internal bridge are used to access oldcore stuffs since augmenting the existing document-bridge does not seems appropriate IMO. 2) The initial enumeration of rights as been replaced by a Right class, which could be seen has a pseudo enum, but could be augmented with new rights. To register a new Right, you have to provide a RightDescription to the AuthorizationManager. The description will define the default state, the tie resolution policy, the inheritance policy, the list of entity types for which the right is applicable, the implied rights and if the right could be allowed in read-only mode. So new defined Right will benefit the whole logic of the AuthorizationManager and currently existing one could be declaratively defined. 3) Large renaming to better distinguish stuffs, clarify comments and prepare for future. I have voluntarily not taken existing names to clearly split the old and the new api. In brief, the new right service is now named AuthorizationManager. Internally, it manipulates SecurityReference (as well as UserSecurityReference and GroupSecurityReference, to represent entities, user and group), SecurityRule (representing a right object) and SecurityAccess (representing an access level in the old nomenclature), which are store in a SecurityCache using SecurityRuleEntry (a set of rules) and SecurityAccessEntry (the access of a given user). The AuthorizationManager delegate cache management to a SecurityCacheLoader which loads rules using a SecurityRuleLoader ; and delegate itself the computing of the access for a given user and a set of rules to an AuthorizationSettler. This last one could be overridden to provide specific decision that could not be done in declarative mode. 4) Refactoring was necessary to improve consistency and reduce complexity, and simplify as much as possible; while extending the limitations to allow more rights to be registered. This work has been a little bit opposed to the optimization done by Andreas, in particular on memory usage. But optimization is often the enemy of clean code. 5) Improvement were necessary to better mimic the existing implementation in some peculiar but necessary rules to stay compatible with current working wiki. I tend to reduce as much as possible what is not done declaratively, but there are still some special cases, like delete for creators, deny for other user on explicit allow and admin for wiki owner that are settle by the authorization settler. My implementation should be almost compatible with the old one, except for groups that are currently not checked from the entity wiki, but only from the user wiki. This needs some more refactoring for which I feel inconfortable with, some I'd like to share first. 6) The AuthorizationManager interface has been simplified, providing 2 methods for either checking or verifying an access right (the checking methods throws while the verifying one return a boolean), and one to register a new right. The existing RightService could be bridged on the new implementation using the XWikiCachingRightService class in xwiki.cfg and the new API could be used side-by-side with the old implementation as well. What should still really need to be improved is the unit testing, currently some tests are still awful and incomplete. I already refactor some of them, to provide a better coverage of essential part of the code: the security cache and the default authorization settler. Obviously, any help is welcomed. Since I already have an existing wiki using this implementation successfully and using it for creating new rights for extensions, I would like to merge this new implementation as experimental in platform to have it available for anyone who need it or want to test it, and for you to use in your new experimental development as well. Providing it in platform will encourage it to be finalized and replace the existing implementation. Here is my +1 for the merge on 4.x, WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

12 years, 9 months

[xwiki-devs] [discussion] Polishing the merge between Annotations and Comments

by Sorin Burjan

Hello everybody, I have started testing and playing a little bit with our new features, the "merge between Annotations and Comments". I am very happy about this new feature, since this offers more flexibility and power. However, this is the initial commit and it still requires polishing in order to be ultra cool. Here are some of my suggestions after I tried to impersonate a "non technical end-user": 1) After adding an Annotation, user wants to add a reply by hovering over the yellow icon and clicking on the "Reply" button. This will move the caret at the bottom of the page, in the Comments Tab. It is a little bit confusing for the end users, which would expect an input text area to appear in the Annotation box, instead of being moved to the bottom of the page. 2) User wants to see the full thread of an annotation. He/she will hover over the yellow icon, and only the first/initial annotation will be visible. If there is at least one reply to that annotation, the user will see a link with "See thread". Clicking on the link, user will be sent in the Comments tab at the bottom of the page. An idea is to be able to see the whole thread related to that annotation in the same place, without having to be moved to the bottom of the page. Now a problem might be if the thread is really large. 3) User wants to delete the whole thread (maybe he/she wants to delete the annotation + all the threads). Clicking on the x button, only the first/actual displayed annotation will be deleted, leaving the rest of the thread/replies on the page at the bottom. IMO this would create confusion among end users and leave mess in the page objects, because users will not understand the context of the remaining comments. This behavior actually comes from Comments feature, which is keeping the replies even if the level 1 comment is deleted. 4) Clicking on the "See Thread" link, will move the user to the bottom of the page, and will highlight with yellow color the Author and Content of the first annotation only. IMO this is not very suggestive, the highlight could be useful only as a delimitation of the "starting" point of the thread, but by highlighting the content too is confusing for end users. This behavior comes from the Permalink behavior of Comments feature. 5) If we say that Annotations are merged with Comments, we can decide if we still keep them visually separated. When adding a new Annotation, in the Comments tab, you can see a small yellow icon denoting that this is an annotation. If user replies to that annotation, the second/nested annotation will be treated as a regular comment. This means only level 1 annotations are marked with the yellow sign, replies or ordinary comments aren't. This seems a little inconsistent IMO. This is not a vote, but if we decide on polishing one of these things, I will create the corresponding JIRA issues. WDYT ? Regards, Sorin B.

12 years, 9 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