xwiki-devs March 2012

xwiki-devs@xwiki.org

38 participants
87 discussions

[xwiki-devs] GSOC 2012

by savitha sundaramurthy

Dear Team XWiki I'm Savitha doing my MS in Computer science at Arizona State University. I'm really excited to contribute to open source community through XWiki GSOC 2012. I'm interested in the project *SOLR search component*. I have worked in lot of Java Projects and have a good standing in it. I've downloaded and built the Xwiki source code as per the instructions. Right now I'm going through the documentation of SOLR and trying to play around with XWiki Enterprise . Looking forward to this opportunity. -- Thanks, Savitha

13 years

[xwiki-devs] XWiki chat

by Fabio Mancinelli

Hi everybody, one of the research projects we are involved in is about realtime collaboration. One of the aspects we wanted to investigate was the integration of a chat system within XWiki. I've been working on this lately and I've built a prototype that uses an embedded XMPP server for handling all the communication. I still have to cleanup a bit the code before committing it, but I took a video of how things work. You can find it here: http://youtu.be/0Gwtpu3iVwo (it's FullHD, so make sure to change the video quality and to switch to fullscreen) There are several things we need to address (authentication is one of them), but I think we could have a functional extension pretty soon. It's 1:30am right now, so I will give you more details in a next mail :) Enjoy. Thanks, Fabio

13 years

[xwiki-devs] [PROPOSAL] Change component role from Class to Type

by Thomas Mortagne

Hi devs, I recently modified component manager internals and changed the role used as key in the map from Class to Type so that it properly make a difference between Provider<Toto> and Provider<Titi> without the need to generate a special hint. For the one not aware of what Type is lets say it's what Class is extending. Among other things Type is also extended by ParameterizedType which is interesting here because it basically contain a Class with it's generic parameters (it also indicate if the type in included in another one but we don't care in our case ;)). To summarize: * Provider is a Class * Provider<String> is ParameterizedType and both are Type That said I would like to change the whole ComponentManager and related descriptors APIs to use Type as role instead of Class. = What it bring What it means is that it makes possible to cleanly represent a Provider in which the generic type is meaningful right in the ComponentDescriptor (right now the generic type is extract from the implementation class when the provider is registered which is pretty crappy) and simplify a lot the current implementation. But it also mean we could use this new "feature" for other components. For example right now we have things like: @Component public class DefaultStringDocumentReferenceResolver implements DocumentReferenceResolver<String> and @Component @Named("default/reference") public class DefaultReferenceDocumentReferenceResolver implements DocumentReferenceResolver<EntityReference> and injected by @Inject DocumentReferenceResolver<String> resolver; and @Inject @Named("default/reference") DocumentReferenceResolver<EntityReference> resolver; Having Type used as role means that we could have: @Inject DocumentReferenceResolver<String> resolver; and @Inject DocumentReferenceResolver<EntityReference> resolver; = What it breaks So what's the catch ? Basically it would break any code that currently programmatically register or unregister Provider since It would remove the current hack to discover the Provider parameter (assuming that the ComponentDescriptor now provide the complete role). But that's OK IMO given that Provider support is very recent and I doubt it's a common use case. We would obviously keep and deprecate all the existing APIs based on Class which are pretty easy to implement since Class extends Type. Even if removing them would not cause any issue when you build it's not binary compatible since it's not the same method signature. So WDYT ? Here is my +1 and since we are starting a new major version it sounds a good occasion so introduce such change. -- Thomas Mortagne

13 years

[xwiki-devs] [Proposal] Supported Databases Strategy

by Vincent Massol

Hi devs, In the same spirit as what we have done for Browsers (see http://xwiki.markmail.org/thread/pn45a7qaefuplpye ) here's a proposal for Databases since we don't have a clear strategy ATM. I propose that by "supporting" we mean: - issues created for these DBs in jira are not closed as won't fix and we make a best effort to fix them - we include these DBs in our tests (be them automated or manual) - when we create new features or modify existing features we make a best effort to verify that they work on the supported list of DBs Proposal: * HSQLDB: only support the version bundled in the standalone zip * MySQL: We officially support the last major version, i.e. 5.0+ ATM * PostgreSQL: We officially support the last major version, i.e. 9.0+ ATM * Oracle: We officially support the last major version, i.e. 11g ATM * DB2: We don't officially support it. This means that we don't test against it, we don't ensure that new feature work on it but if someone raises an issue in jira and it's easy to fix (or if someone provides a patch) then we fix it. * Derby: Same as DB2 * Microsoft SQL Server: Same as DB2 * H2: Same as DB2 for the moment (it would change if we decide to replace HSQLDB by H2 one day) * Others: Same as DB2 I also propose that in the Release notes for each version of XWiki we mention the list of DBs we have tested against and that we "support". Here's my +1 Thanks -Vincent

13 years

[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

13 years

[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

13 years

[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

13 years

[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

13 years

[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

13 years

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

13 years

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2012