xwiki-devs March 2008

xwiki-devs@xwiki.org

52 participants
193 discussions

by Fabio Mancinelli

Hi everybody. following the post I did some time ago, I've reworked the XWiki XML RPC implementation. The previous XML RPC code was rather messy and contained a lot of duplicated code (basically the server side was re- implementing the same domain model already available in the Swizzle client-side jar). At first I managed to cut it down by basically removing all the duplicated code and linking directly to the Swizzle jar. Then I started working on object manipulation and I basically ended up with a complete rewrite. The new implementation is then based on two components: 1) The domain model classes and the XML RPC client 2) The server side implementation of the API (that is an extension of the Confluence one and uses the same domain model defined in 1) Overall we have the following "features": 1) The new implementation, on the server side, makes use of the XWiki Api wrapper (com.xpn.api.XWiki) instead of directly using the low level objects. Though I am not an expert of the XWiki internals, I think this is good for handling rights management (which is transparently done by the wrapper) 2) The implementation looks more robust and simple. 3) On the client side we still have interoperability with confluence and with the previous versions of XWiki. There are, however, two potential "bugs": 1) The client side jar requires Java 5.0. Infact it uses reflection and annotations to handle the "magic" of XML RPC communication (see MapObject.java). 2) We are basically giving up on Swizzle. The first "bug" can be easily solved, but this would lead to a less elegant and more bloated solution. The second "bug" is maybe political. Anyway if we want to go the Swizzle way, I also have a cut-down implementation that still uses swizzle (though I will need to patch the official swizzle-distribution for adding XWiki specific features, and in this is actually like having our own client) The current implementation is not feature complete (though XEclipse would already work fine with it and object edition could also be implemented) In the attachments you will find the current version of the implementation so you can review it and discuss future directions or issues: org.xwiki.xmlrpc.tar.gz is the "client side" jar that will be used by clients like XEclipse. com.xpn.xwiki.xmlrpc3.tar.gz is the package that would, in case, become part of XWiki. WDYT? Cheers, Fabio

16 years, 7 months

[xwiki-devs] DB2 pure xml

by Michael Oliver

Has anyone looked into DB2 pure xml for XWiki? http://www.ibm.com/developerworks/db2/library/techarticle/dm-0707singh/ and http://www.ibm.com/developerworks/edu/dm-dw-dm-0606leung-i.html Points to what I believe is strong support for the XWiki data model. I helped write the DB2 Viper store for the Jakarta Slide project and in that implementation we went from 40 tables to shred objects down to 4, so given XWiki's bent on xml it seems likely there would be similar gains in simplicity. Ollie <http://www.corenttech.com> On Demand Solutions On Demand Michael Oliver Chief Technology Officer Corent Technology <http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=3600+W+Florida+Ave&csz=Hemet %2C+CA+92545&country=us> 3600 W Florida Ave #340 Hemet, CA 92545 <mailto:moliver@corenttech.com> moliver(a)corenttech.com <http://www.corenttech.com> http://www.corenttech.com AIM: moliver(a)corenttech.com tel: fax: mobile: Skype ID: <http://www.plaxo.com/click_to_call?src=jj_signature&To=949-547-5700&Email=m oliver(a)corenttech.com> 949-547-5700 7029740341 <http://www.plaxo.com/click_to_call?src=jj_signature&To=949-547-5700&Email=m oliver(a)corenttech.com> 949-547-5700 MikeOliverAZ <https://www.plaxo.com/add_me?u=55837372229&src=client_sig_212_1_banner_join &invite=1> Want to always have my latest info? <http://www.plaxo.com/signature?src=client_sig_212_1_banner_sig> Want a signature like this? View <http://corenttech.ning.com/xn/detail/u_25igigalsj1dt> my page on Corent Technology View my page <http://linkedinspin.ning.com/xn/detail/u_25igigalsj1dt> on CMU SEI LinkedIn SPIN

16 years, 7 months

[xwiki-devs] [Proposal] XE 1.4 roadmap + release dates

by Vincent Massol

Hi, I've published the XE 1.4 general roadmap directions on http://www.xwiki.org/xwiki/bin/view/Main/Roadmap In addition here's a proposal for the release dates: * 1.4M1: 28th of March 2008 * 1.4M2: 18th of April 2008 * 1.4RC1: 25th of April 2008 * 1.4RC2: 2nd of May 2008 * 1.5 Final: 6th of May 2008 I'm entering those into JIRA Ok with everyone? Thanks -Vincent

16 years, 7 months

[xwiki-devs] Java version?

by Kamna Jain

Can somebody tell me what version of JAVA is being used to develop XWiki? Thanks

16 years, 7 months

[xwiki-devs] Building the source for XWiki Enterprise 1.3

by Marco K.

Hi all, I downloaded XWiki Enterprise 1.3 RC1 some weeks ago and brought it to run with MySql 4 and Tomcat 5.0.28. Now, I want to do the same for the new version 1.3, but I want to build this version from source. Is there a way to get the complete source of version 1.3? (For Building - and especially for my understanding) And how can I compare the differences of the source code of two released versions (e.g. XWiki Enterprise 1.2 and 1.3), so that I can review the consequences of changing a release in the future? Thanks a lot and best Regards, Marco P.S. I'm new to this list. Please apologize, if this question is asked before.

16 years, 7 months

[xwiki-devs] XWiki and Eclipse debugging

by Thomas Mortagne

Hi committers, I don't know the only one who do that to debug XWiki on Eclipse I'm creating web project mirror of the product web I'm working on (for example XEM) and use "j2ee module dependencies" property to dynamically link xwiki-core and plugins. This way when modifying something in plugin it's automatically built and published without the need to rebuild all XEM to get a complete distribution package with all necessary dependencies included. I think it's pretty similar to what I seen for some of you with IntelliJ IDEA. The "problem" here is that Eclipse automatically add META-INF/MANIFEST.MF file in the first source directory of web project linked projects it can find : in our case it's always src/main/java (at least in core/plugins/components cases). In this case Eclipse does not generate this file at build time like maven do. Considering that we never add META-INF in src/main/java but in src/main/resources for a maven project I always added it to svn:ignore in the past. As I had a chat with Vincent who is not agree with this way to do I'm wondering what you think of that ? -- Thomas Mortagne

16 years, 7 months

[xwiki-devs] why hasn't the class deletion been implemented?

by Pascal Voitot

This might seem stupid but what are the limitations in class/object deletion? br Pascal

16 years, 7 months

Re: [xwiki-devs] [xwiki-notifications] r8601 - xwiki-platform/xwiki-plugins/trunk/spacemanager/src/main/java xwiki-platform/xwiki-plugins/trunk/swizzle/src/main/java xwiki-products/xwiki-enterprise-manager/trunk/distribution-test/selenium-tests xwiki-products/xwiki-enterprise-manager/trunk/distribution-test/xmlrpc-tests

by Vincent Massol

On Mar 18, 2008, at 3:22 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-03-18 15:22:42 +0100 (Tue, 18 Mar 2008) > New Revision: 8601 > > Modified: > xwiki-platform/xwiki-plugins/trunk/spacemanager/src/main/java/ > xwiki-platform/xwiki-plugins/trunk/swizzle/src/main/java/ > xwiki-products/xwiki-enterprise-manager/trunk/distribution-test/ > selenium-tests/ > xwiki-products/xwiki-enterprise-manager/trunk/distribution-test/ > xmlrpc-tests/ > Log: > Add Eclipse settings to svn:ignore > > > Property changes on: xwiki-platform/xwiki-plugins/trunk/spacemanager/ > src/main/java > ___________________________________________________________________ > Name: svn:ignore > + META-INF > > > > Property changes on: xwiki-platform/xwiki-plugins/trunk/swizzle/src/ > main/java > ___________________________________________________________________ > Name: svn:ignore > + META-INF META-INF should definitely not be added. Can you rollback? Thanks -Vincent

16 years, 7 months

[xwiki-devs] [Proposal] Improve Wiki Administration

by Jean-Vincent Drean

Hi XWikiers, We'd like to refactor the wiki & space administration for XE 1.4. Layout drafts and full proposal are available here : http://dev.xwiki.org/xwiki/bin/view/Design/ImproveWikiAdministration Summary : * Display the administration features in wiki pages, in view mode (ie : move code from the admin templates to wiki pages) * Merge the current XWiki.WebHome items with the current Administration features in the new UI * Merge the import / export features in the same page * Put the Panels list and PanelWizard in the new UI Tech : * new XWiki.WebHome : direct links (with big icons) to admin categories (a la Windows control panel) * A main administration sheet : XWiki.AdministrationSheet (may be with cascading admin sheets beyond) * Inclusion of XWiki.AdministrationSheet in XWikiPreferences (global prefs) * Inclusion of XWiki.AdministrationSheet in all WebPreferences (quick access to space admin) Questions : * Do we add an "Administration" entry in the top menu bar ? With 2 dropdown items : ** current space administration ** wiki administration * Do we really need the "big icons" page (since all the categories are available from the left column) ? wdyt ? Thanks, JV.

16 years, 7 months

[xwiki-devs] New Observation component: Usage scenarios

by Sergiu Dumitriu

Hi, How do you feel about the next usage scenarios for the observation component? A. Simple observing of changes This is the most common usage of the old notification mechanism. It allows a listener to see when something gets changed. It receives as the source the changed document, from which it can get the original document (there's a doc.getOriginalDocument() method for this). For the moment, the data argument is the context, as it is still a vital object for most of the code, and it has to be passed around all the time. The event will hold the type of change, like adding a new document, deleting, or just saving a new version. In the future I'd like to increase the granularity, to make this "change" a set of basic changes, to be able to say that (object added, attachment removed, content changed) is what happened to the document (see http://jira.xwiki.org/jira/browse/XE-213 too). With this event, a listener can then update some data indexer, like the Lucene plugin does, or send the new documents/attachments to a repository, or send a mail with the new code, or ping on IRC. B. Simple observing of actions This is also implemented in the old notification mechanism. It allows a listener to monitor actions. It receives as the source the affected document, and as the additional data the same context, as it is needed. The event holds the action name, and I'd like to add the full URL, too, as other important information might be in there. I don't know if sending the complete request object is a good idea, but I think we should be able to obtain it somehow. With this event, a listener can update some statistics, refresh some caches or cleanup some indexes, send an attachment to another repository (like SVN), or, based on the URL, it can be used to take some action, like if the action was "createspace" and the "notify=admins" parameter was given in the request, then the observer can send the notifications, without polluting the application code with the checks and mail sending calls. C. Precondition/Postcondition enforcing The previous two use cases allow a simple ping that something has already happened. (Actually, the listeners can also change the passed document, as the actual object is sent.) But I'd like to be able to write a listener that can say "this is not allowed, please stop this action", or "these changes are not OK, don't save this document". So, a precondition can be that "/save/" cannot be performed between 6PM and 7AM, which would be a needed feature in some companies, or that "/view/" cannot be performed on the "SectionA" space from the IP addresses like 192.168.2.*, which belongs to the SectionB users (these are action events). And a postcondition can be that the XWiki.XWikiPreferences can only be updated by changing XWikiGlobalRights objects, other types of changes can only be performed by a superadmin only, or that adding some content that looks like spam is not allowed (these are document events). So, on top of the previous use cases, I'd like to add a "phase" to the events, which indicates if the event is sent before or after the change (or we can just add new events), and a new type of exception thrown by the listeners, which is not ignored. Right now, if a listener throws an exception, it is ignored. This exception, when received by the code that sends the notification, should stop the normal processing and display "action not allowed" + ex.getMessage to the user. D. Rendering hooks While working on the SkinExtensions and trying to write a better #toc macro, I was faced with the problem that there's no way a plugin can change the rendered content at the end. Yes, it can alter it line by line, and in theory there is an endRenderingHook sent with the content, but that is actually buggy, as an empty string is sent instead of the content, and the result is discarded. Still, even if fixed, this is sent only for *rendered* content, not *parsed* content. My initial idea was to change the PluginInterface by adding two new methods that will be called before and after the content was generated, but that is a bad idea, since the PluginInterface is already too big and has too many types of methods. And since the new rendering component is not yet available, I thought that we can also use events for this. So, instead of writing new methods in the PluginInterface, we can add other type of events, which gets sent in the parsing/rendering process. That way, we don't need to have a plugin that implements all these methods, and adding a new feature will require just sending a new type of event, instead of changing an interface (which is dangerous). The source would be an object holding the string, which can be modified by the listeners. Other information could be the content document, if there is one, the rendering/parsing context, anything else? E. Other generic events Like FlushCacheEvent, StartupEvent, ShutdownEvent, VirtualInitEvent, VirtualShutdownEvent (sent when a wiki is deleted by the WikiManagerEvent), Application[Added/Enabled/Disabled/Removed]Event (sent by the ApplicationManager), Space[Added/Removed]Event (sent by the SpaceManagerPlugin), etc. Comments, please? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 7 months

← Newer
1
...
8
9
10
11
12
13
14
...
20
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 March 2008