xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Discussion] Gadgets in XWiki

by Anca Luca

Hi devs, Following the implementation of gadgets we'd need to discuss the approach of implementing xwiki as an open social container (also see http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HXWikiasOpenSo… for the discussion). There are 2 approaches that can be used: Short story: Option A): open social gadgets are imported as xwiki macros (one macro for each imported gadget), the xwiki dashboard works with macros as gadgets, to publish the xwiki macros as gadgets we provide an automatic transformation of xwiki macros in open social gadgets XML definition Option B): dashboard accepts a single macro inside, the {{gadget}} macro, which will specify a reference to the gadget to display (URL to XML if it's open social, page reference if it's xwiki gadget) and the parameters, there would be a mechanism to automatically publish these xwiki pages as gadgets (to be used either by this {{gadget}} macro or by other containers). Long story (also discussing possible approaches for subproblems, and also containing some pros & cons): Option A) See http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HProposalA-Gad… Option B) See http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HProposalB-All… WDYT? Do you think there are other possible approaches that should be added to this list before the vote? What do you think would be more suitable? Some usage scenarios are documented at http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HScenarios . Please, if you feel the list is not complete, contribute your usecases. Thanks, Anca

14 years, 6 months

[xwiki-devs] [Proposal] Portlet Integration - Client Side

by Marius Dumitru Florea

Hi devs, In order to integrate XWiki in a portal ( http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration ) we need to change a bit the front end to: * ensure XWiki's HTML element IDs are unique within the portal page * ensure XWiki's stylesheets doesn't affect other portlets and the portal page itself * ensure XWiki content is not affected by stylesheets of other portlets or the portal page itself We could do the following: (1) "Mark" IDs and class names whenever they are used in JavaScript code, both in-line and stand-alone, using two identify functions: id(String) and className(String). This is required because identifying automatically IDs and class names in JavaScript code is not always possible. (2) Automatically rewrite IDs and class names in CSS and HTML (except in-line JavaScript) and "marked" IDs and class names in both in-line and stand-alone JavaScript code before the response for each of the resources (page included) reaches the client. This can be easily done in the XWiki portlet bridge ( http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ ). Final IDs and class names will include the portlet identifier and the XWiki namespace (e.g. a simple 'x' prefix). (3) Split XWiki's stylesheets (e.g. colibri.css) in two: (a) general rules, including skin reset (b) XWiki specific rules (i.e. with selectors including class names or IDs) and import only (b) in portlet mode. WDYT? Thanks, Marius

14 years, 6 months

[xwiki-devs] [ANN] XWiki Enterprise 2.4 Release Candidate 1 Released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.4 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download First and hopefully last release candidate of the XWiki Enterprise 2.4 version. This is mostly a bugfixing release before the 2.4 final. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise24RC1 Thanks - The XWiki dev team

14 years, 6 months

Re: [xwiki-devs] [xwiki-notifications] r29813 - platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table

by Sergiu Dumitriu

On 06/30/2010 10:28 AM, vmassol (SVN) wrote: > Author: vmassol > Date: 2010-06-30 10:28:11 +0200 (Wed, 30 Jun 2010) > New Revision: 29813 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > Log: > XWIKI-5316: Send a livetable event when the livetable has finished displaying/updating the rows > > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-06-30 00:07:16 UTC (rev 29812) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-06-30 08:28:11 UTC (rev 29813) > @@ -285,6 +285,14 @@ > } > } > if (this.paginator) this.paginator.refreshPagination(); > + > + // Let code know displaying is finished > + // 1. Named event (for code interested by that table only) > + document.fire("xwiki:livetable:" + self.domNodeName + ":displayComplete") > + // 2. Generic event (for code potentially interested in any livetable) > + document.fire("xwiki:livetable:displayComplete", { > + "tableId" : self.domNodeName > + }); You should also send an event on the livetable root element as well. > }, > > /** > @@ -386,6 +394,14 @@ > } > > if (this.paginator) this.paginator.refreshPagination(); > + > + // Let code know displaying is finished > + // 1. Named event (for code interested by that table only) > + document.fire("xwiki:livetable:" + self.domNodeName + ":displayComplete") > + // 2. Generic event (for code potentially interested in any livetable) > + document.fire("xwiki:livetable:displayComplete", { > + "tableId" : self.domNodeName > + }); > }, > > /** -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 6 months

Re: [xwiki-devs] [xwiki-notifications] r30025 - platform/core/trunk/xwiki-observation/xwiki-observation-remote

by Sergiu Dumitriu

On 07/06/2010 04:20 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-07-06 16:20:58 +0200 (Tue, 06 Jul 2010) > New Revision: 30025 > > Modified: > platform/core/trunk/xwiki-observation/xwiki-observation-remote/pom.xml > Log: > XWIKI-4917: Upgrade to jgroups 2.8 > Add comment > > Modified: platform/core/trunk/xwiki-observation/xwiki-observation-remote/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-observation/xwiki-observation-remote/pom.xml 2010-07-06 13:41:04 UTC (rev 30024) > +++ platform/core/trunk/xwiki-observation/xwiki-observation-remote/pom.xml 2010-07-06 14:20:58 UTC (rev 30025) > @@ -59,6 +59,7 @@ > <artifactId>xwiki-core-context</artifactId> > <version>${pom.version}</version> > </dependency> > + Is it time for us to require Java 6 as well? > <dependency> > <groupId>jgroups</groupId> > <artifactId>jgroups</artifactId> -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 6 months

[xwiki-devs] [Proposal] Replace download pages on code.xwiki.org with links to the maven repo

by Vincent Massol

Hi, Thomas, JV and I discussed about replacing download pages on xwiki.org with links to our maven repo (for stuff on code.xwiki.org only). The rationale: Speed up the dev process and make it a failsafe process. Advantages: * No need to upload artifacts (which means smaller wiki and faster release process) * Full history available * No risk of being not synced with the maven repo (which is the official artifact repository) * Low-tech solution http://code.xwiki.org/xwiki/bin/view/Applications/AnnotationsApplication When you click on download you go to: http://maven.xwiki.org/releases/org/xwiki/platform/applications/xwiki-appli… Thomas has already implemented it during the last release. It should have been discussed before but Thomas was in a hurry for the release. Let us know if you don't agree. Thanks -Vincent

14 years, 7 months

[xwiki-devs] REST refactoring

by Fabio Mancinelli

Hi all, I did a small refactoring in the REST module which consisted in isolating the JAXB model classes in a separate module. This allows client to use JAXB classes for retrieving XML representations without dragging in all the core dependencies. The refactoring consisted in creating an xwiki-rest-model module in core, moving some files, and update the pom.xml's to make things compile. Maybe it's risky to commit it now, but if you are ok everything's ready. I include a diff so that you can check what it looks like. -Fabio

14 years, 7 months

Re: [xwiki-devs] [xwiki-notifications] r30000 - platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test

by Vincent Massol

On Jul 5, 2010, at 7:00 PM, vmassol (SVN) wrote: > Author: vmassol > Date: 2010-07-05 19:00:58 +0200 (Mon, 05 Jul 2010) > New Revision: 30000 yeah rev 30000 :) -Vincent > > Modified: > platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractMockingComponentTestCase.java > Log: > Added comment > > Modified: platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractMockingComponentTestCase.java > =================================================================== > --- platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractMockingComponentTestCase.java 2010-07-05 16:26:20 UTC (rev 29999) > +++ platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractMockingComponentTestCase.java 2010-07-05 17:00:58 UTC (rev 30000) > @@ -59,6 +59,7 @@ > this.componentManager = new EmbeddableComponentManager(); > > // Step 1: Register all components available > + // TODO: Remove this so that tests are executed faster. Need to offer a way to register components manually. > this.loader.initialize(this.componentManager, getClass().getClassLoader()); > > // Step 2: Inject all fields annotated with @MockingRequirement.

14 years, 7 months

[xwiki-devs] [VOTE] Agree to start using AbstractMockingComponentTestCase

by Vincent Massol

Hi, Some time ago I had added the AbstractMockingComponentTestCase class in shared-test. I've refactored it a bit over the week end to make it even easier to use. The idea is to use a @MockingRequirement annotation in the test case class to get a component instance with all its @Requirement fields injected with mocks. This makes it easier to test than using the older AbstractComponentTestCase since you don't need to setup component mocks manually. Here's an example usage: public class MacroContentTableBlockDataSourceTest extends AbstractMockingComponentTestCase { @MockingRequirement private MacroContentTableBlockDataSource source; ... Another example: public class DefaultMacroManagerTest extends AbstractMockingComponentTestCase { // Mock all required components except for some for which we want to use the real implementations since they make // the test easier to write (no need to mock them). @MockingRequirement(exceptions = { ComponentManager.class, MacroIdFactory.class }) private DefaultMacroManager macroManager; As you can see in this second example, it's also possible to exclude some @Requirement from being mocked if need be. I'd like that we agree to use this new test class from now on instead of AbstractComponentTestCase (unless there are cases where it's not usable but please discuss those use cases with me since maybe there are solutions to improve AbstractMockingComponentTestCase). Here's my +1 Thanks -Vincent

14 years, 7 months

[xwiki-devs] unsubscribe

by Hermes, Lars

Festo AG & Co. KG Lars Hermes Abteilung IS-PB BSP Development + User Services Plieninger Stra?e 50 73760 Ostfildern-Scharnhausen Deutschland Telefon +49(711)347-4510 Telefax +49(711)34754-4510 http://www.festo.com Der Inhalt dieses E-Mails ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieses E-Mails durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender des E-Mails in Verbindung zu setzen, falls Sie nicht der Adressat dieses E-Mails sind und das Material von Ihrem Computer zu loeschen. This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this e-mail, please delete it and immediately notify the sender. Rechtsform: Kommanditgesellschaft Sitz: Esslingen a.N., Registergericht Stuttgart HRA 211583, Umsatzsteuerident-Nummer: DE 145339206 Pers?nlich haftende Gesellschafterin: Festo Management Aktiengesellschaft Sitz: Wien/?sterreich, Firmenbuchgericht: Handelsgericht Wien, Firmenbuch Nr. FN 303027 d Vorstand: Dipl.-Kfm. Alfred Goll Dr. Claus Jessen Dr. Ansgar Kriwet Dr. Eberhard Veit (Vorsitzender) Dipl.- Kfm. Michael M?lleken Aufsichtsratsvorsitzender: Dr. Wilfried Stoll

14 years, 7 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