xwiki-devs August 2009

xwiki-devs@xwiki.org

41 participants
141 discussions

[xwiki-devs] [VOTE] Special event matching all events

by Thomas Mortagne

Hi, For network event distribution I need to be able to receive all events (because it's not done by ObservationManager itself but by an external module). Currently ObservationManager only match events with the exact same class so it's impossible to match all events or event several events of same subject like documents event for example. I don't have time to design a generic multievent matcher and a redesign of the OM is already started for activity stream so for now I propose to introduce a special AllEvent event ObservationManager will trait as a particular case when returned by a listener (with lots of comments of course). WDYT ? here is my +1 -- Thomas Mortagne

15 years, 1 month

Re: [xwiki-devs] Tests for XEclipse? (was Re: [xwiki-notifications] r22402 - in sandbox/gsoc/xeclipse: org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/notifications org.xwiki.ecl

by Arvind Gupta

Vincent Can you please explain what do u mean by testing XEclipse? I mean how do you write them? Please pass on some pointers. -arvind -arvind On Fri, Aug 7, 2009 at 12:49 PM, Vincent Massol <vincent(a)massol.net> wrote: > Venkatesh, > > Do we have tests for xeclipse? If not, we'll hit a wall in some not > far future in term of quality. > > Thanks > -Vincent > > On Aug 7, 2009, at 12:05 AM, vnkatesh (SVN) wrote: > > > Author: vnkatesh > > Date: 2009-08-07 00:05:35 +0200 (Fri, 07 Aug 2009) > > New Revision: 22402 > > > > Added: > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > > eclipse/ui/handlers/NewSpaceHandler.java > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > > eclipse/ui/wizards/NewSpaceWizard.java > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > > eclipse/ui/wizards/NewSpaceWizardState.java > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > > eclipse/ui/wizards/SpaceSettingsPage.java > > Modified: > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/ > > xwiki/eclipse/core/DataManager.java > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/ > > xwiki/eclipse/core/notifications/CoreEvent.java > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/ > > xwiki/eclipse/core/storage/RemoteXWikiDataStorage.java > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/plugin.xml > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > > eclipse/ui/NavigatorContentProvider.java > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > > eclipse/ui/UIConstants.java > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > > eclipse/ui/actions/DataManagerActionProvider.java > > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > > eclipse/ui/wizards/PageSettingsPage.java > > Log: > > Feature added. > > > > * "New space" Creation for XEclipse > > [snip] > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

15 years, 1 month

[xwiki-devs] Update on the work on a new Skin for XE 2.0

by Guillaume Lerouge

Hi Devs, here's a quick update on the current work being undertaken to bring a new skin to life for XWiki 2.0. The aim of this new skin is to provide XE with a fresh / new look & feel for the 2.0 release. The main items, ordered by their priority, are listed here: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/NewSkin It's broken down into 2 sets: hard requirements (XE 2.0 can't ship without meeting them) and soft requirements (we can do them later if needed). Its main aims are: - make it easier for a new wiki user to change the look & feel of the wiki using its own color set - move the action bar closer to the content area and make it scroll with the page (removing the flickering issue in linux) - make it possible to automatically display a page's title when its title field is filled (configuration option) - replace the stripped background images with a plain color background Those items are those that we run into when trying to customize skins and should help users make their wiki look nice more easily. Cati & I will keep you posted about the skin's progress. Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

15 years, 1 month

Re: [xwiki-devs] [VOTE] Hide Office Importer Features when the OOoserver isn't running

by PERINAUD Christophe

I agree with Vincent about the hiding way. I would prefer a message instead of not knowing the existance of this (great) functionnality. Also +1 for the first and the (new) third suggestion Thanks -----Message d'origine----- De : devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] De la part de Vincent Massol Envoyé : vendredi 7 août 2009 11:35 À : XWiki Developers Objet : Re: [xwiki-devs] [VOTE] Hide Office Importer Features when the OOoserver isn't running On Aug 7, 2009, at 11:22 AM, Guillaume Lerouge wrote: > Hi Devs, > right now an user can go to the Office Importer page and try > uploading a > file even when the backend OOo server isn't running. This leads to > usability > issues. Thus I'd like to send a vote on the following 2 items: > > - On the Office Importer page, add the following message: > - > > "You cannot import an Office document since the conversion > server has not been started. Please ask an administrator to get it > started for you." > > - > > If the current user is an admin, the message should read: "You > cannot import an Office document since the OpenOffice server has not > been started yet. You can start the OpenOffice server and manage it > from this page (link to the OOo server administration page)." +1 > - > > In the action bar: add a check to see whether the OOo server is > running and don't display the link if the OOo server is not. -0 I'm not a big fan of magically hiding things. How will a user know there's an office import feature? I prefer that the menu entry stays and the page explains that the office importer is not started. I'd like to add a new behavior though (if it's not already done): - if the office importer app is not installed (we can test for the main office importer page availability) then the menu entry shouldn't appear. Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -------------------------------------------------------------------------------- This e-mail is intended only for the addressee named above. It does not bind the sender, except in the case of an existing written convention with the addressee. This e-mail may contain material that is confidential and privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender and delete all copies. While reasonable precautions have been taken to ensure that this e-mail and any attachments are free from any computer virus or similar defect, no liability will be accepted in that respect. Anyone accessing this e-mail must take their own precautions as to security and virus protection. KBL European Private Bankers S.A., 43 boulevard Royal L-2955 Luxembourg, R.C.S. Luxembourg B 6395, T (352) 47 97 1

15 years, 1 month

[xwiki-devs] Tests for XEclipse? (was Re: [xwiki-notifications] r22402 - in sandbox/gsoc/xeclipse: org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/notifications org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage org.xwiki.eclipse.ui org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/actions org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/handlers org.x

by Vincent Massol

Venkatesh, Do we have tests for xeclipse? If not, we'll hit a wall in some not far future in term of quality. Thanks -Vincent On Aug 7, 2009, at 12:05 AM, vnkatesh (SVN) wrote: > Author: vnkatesh > Date: 2009-08-07 00:05:35 +0200 (Fri, 07 Aug 2009) > New Revision: 22402 > > Added: > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > eclipse/ui/handlers/NewSpaceHandler.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > eclipse/ui/wizards/NewSpaceWizard.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > eclipse/ui/wizards/NewSpaceWizardState.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > eclipse/ui/wizards/SpaceSettingsPage.java > Modified: > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/ > xwiki/eclipse/core/DataManager.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/ > xwiki/eclipse/core/notifications/CoreEvent.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/ > xwiki/eclipse/core/storage/RemoteXWikiDataStorage.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/plugin.xml > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > eclipse/ui/NavigatorContentProvider.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > eclipse/ui/UIConstants.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > eclipse/ui/actions/DataManagerActionProvider.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/ > eclipse/ui/wizards/PageSettingsPage.java > Log: > Feature added. > > * "New space" Creation for XEclipse [snip]

15 years, 1 month

[xwiki-devs] on new rendering

by [Ricardo Rodriguez] Your EPEC Network ICT Team

Hi all, Since almost two years ago you has done a lot of work to develop the new rendering system based on components. I can found two documents I'd been following to understand how this work has been done and what was its development state. Those are: http://dev.xwiki.org/xwiki/bin/view/Design/NewRenderingArchitecture and http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HCustomiz… I am trying now to catch up with this thread due mainly to two reasons: * At least a couple of new XWiki installations will be made public in the following weeks. It seems logical to use the last available version and take profit of all the new features. We do need to serve XWiki pages rendered as plain text. This was simple done working with XWiki 1.0 syntax. It seems to work the same way while working with XE 2.0m1 when using XWiki 1.0 syntax, but xpage=plain it is not enough when working with XWiki 2.0 syntax. I've read a number of thread related with issue in the devs list and, if I've well understood, there will be new parameters introduced in 2.0m2 to * We do need to control at least rtf and pdf outputs. So, please, are these two links still valid to follow the development of the new rendering architecture and how it affects/will affect the production of rtf and/or pdf files? What other locations I must follow, if any, to follow this development? I hope I've been able to explain what I am trying to do! All the best! Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

15 years, 1 month

[xwiki-devs] [PROPOSAL] Name threads from request URL

by Thomas Mortagne

Hi devs, When we have farm like xwiki.org or myxwiki.org stuck we usually kill the jvm and look at its last state to see if we can find some lock etc... Most of the time if the issue is in a specific script and not a platform bug it's unreadable. To make it more easy I propose to rename thread created by the application server based on the URL. Basically it means something like adding: Thread.currentThread().setName(request.getRequestURL() + "?" + request.getQueryString()); in XWikiAction#initializeXWikiContext. I tested it on tomcat and it works well. WDYT ? Here is my +1 for this -- Thomas Mortagne

15 years, 1 month

[xwiki-devs] Question about AbstractMacro API

by Asiri Rathnayake

Hi all, While working on macro categories implementation I came across a small problem that made me little uncomfortable with AbstractMacro API. I'm writing this email just to make sure that I'm not making things worse in the public API. Currently AbstractMacro has 4 constructors: * public AbstractMacro(String description); * public AbstractMacro(String description, ContentDescriptor contentDescriptor) * public AbstractMacro(String description, Class< ? > parametersBeanClass) * public AbstractMacro(String description, ContentDescriptor contentDescriptor, Class< ? > parametersBeanClass) Now, I wanted to introduce a MacroDescriptor::getDefaultCategory() method and I also wanted to make this new parameter available in AbstractMacro constructors (makes sense). Now the problem with this is, If I introduce an optional 'defaultCategory' parameter into AbstractMacro, this will make the total number of constructors 8. What will happen if someone wants to introduce a MacroDescriptor::getIcon() method some time later? One solution is to have setXXXX methods for those parameters instead. But then a slight problem occurs where AbstractMacro needs to somehow call setXXX methods on it's internal MacroDescriptor instance. It's not that we can't cook comething up, but it's going to look hackish. My question is, why do we have to make AbstractMacro constructors so simple? Can't we have these two constructors only? * public AbstractMacro(); * public AbstractMacro(MacroDescriptor); The problem with this approach is that a client will have to do little more work like; ContentDescriptor myContentDescriptor = new DefaultContentDescriptor("This is my content", true); MacroDescriptor myMacroDescriptor = new DefaultMacroDescriptor("This is my macro", myContentDescriptor, beanManager.getBeanDescriptor(MyParametersClass.Class)) super(myMacroDescriptor); Even though this is too much of work, I think it will make the API more extensible an clean. This is only my opinion. I didn't want to drag this issue this far but I just couldn't feel myself comfortable with the way I'm going to implement the macro categories support. Up to you. Thanks. - Asiri

15 years, 1 month

[xwiki-devs] [DESIGN][PROPOSAL] Macro Categories Implementation

by Asiri Rathnayake

Hi, I would like to introduce a MacroCategoriesManager component for managing macro categories. We already have a MacroManager component in place but I think seperating out the concern of macro categories management into a seperate component creates a more extensible design. Following is a basic outline for implementing MacroCategoriesManager component: * Introduce MacroDescriptor::getDefaultCategory() method which returns a String. The purpose of this method is to allow macro author to supply a default category under which his macro should be listed. This method can virtually return any string. Following three steps I'm not very confident about: * Duplicate each existing constructor in AbstractMacro and add a 'category' parameter. * Make AbstractMacroDescriptor constructor accept a 'category' parameter. * Duplicate each existing constructor in DefaultMacroDescriptor and add a 'category' parameter. If a macro author does not specify a default category, the "Other" category will be used. * Introduce the MacroCategoriesManager component with following methods: List<String> getMacroCategories() List<String> getMacroNames(String category) List<String> getMacroNames(String category, Syntax syntax) Each of these methods will give priority to admin configured macro categories. That is they will discard MacroDescriptor::getDefaultCategory() return value if the wiki admin has configured a different category for a given macro. * A macro category can be overwritten by specifying the configuration parameter "org.xwiki.rendering.macro.<macro_name>.category" using xwiki's configuration mechanism (Ex. xwiki.properties). This is my initial design idea, please let me know what you think. Thanks. - Asiri

15 years, 1 month

[xwiki-devs] [DISCUSSION] Macro categories

by Asiri Rathnayake

Hi all, This is about implementing back-end support for macro categories. My understanding of macro categories and it's implementation is bit vague at this point, hopefully this email will set things straight. To understand the usefulness of macro categories, have a look at confluence macro browser: http://confluence.atlassian.com/display/DOC/Working+with+the+Macro+Browser We can identify several categories by looking at confluence but XWiki will need several other categories as well. I can think of few XWiki macro categories: * Presentation - Macros that allow presenting document content with various styles. Like box & code macros * Document content - Macros that add stuff into a wiki page, like image, video & office macros. * Scripting - HTML, Velocity, Groovy, Ruby etc. * Visualization / Reporting - Chart macro and the like. * External content - Macros that fetch content from external sources. Like Rss macro. * Development - Macros in development / introductory stage. I'm pretty sure there are more categories to consider (please list them). Now for the real questions that are troubling me: * Should these categories be statically defined inside the rendering module? This would mean that the macro author gets to select which category his macro belogs to, which in turn means we should have a method like: MacroCategory getCategory() inside the Macro interface. Using this information MacroManager will present different macro categories to the outside world. * The other approach is to keep this categorization inside some wiki pages and allow administrators to manipulate it: Create / Edit categories, assign macros to categories etc. I'm not sure what problems this would create when implementing macro browser though. * Another (very hackish) approach would be to use the component role hint in the same fashion it is used to specify macros for different syntaxes. I think this is enough to get the discussion started. Thank you very much for your input. - Asiri

15 years, 1 month

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 August 2009