- xwiki-devs@xwiki.org - lists.xwiki.org

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 >

16 years, 1 month

4
3
0 0

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

16 years, 1 month

2
2
0 0

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

16 years, 1 month

1
0
0 0

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

16 years, 1 month

1
0
0 0

[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

16 years, 1 month

3
14
0 0

[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

16 years, 1 month

5
8
0 0

[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

16 years, 1 month

2
5
0 0

[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

16 years, 1 month

2
4
0 0

[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

16 years, 1 month

7
20
0 0

[xwiki-devs] [UX][Standards] Vertical Forms + (Primary / Secondary) Buttons

by Ecaterina Valica

Hi Devs, I made on incubator (http://incubator.myxwiki.org/xwiki/bin/view/Standards/) a Standards page. This is a work in progress and lots of things need to be added. We really need some standards in order to have consistency throughout the platform. So, for now I propose to use 2 standards: 1. (Primary / Secondary) Buttons http://incubator.myxwiki.org/xwiki/bin/view/Standards/Buttons 2. Vertical Aligned Forms http://incubator.myxwiki.org/xwiki/bin/view/Standards/Forms I hope you will agree and start integrating these concepts in the development of new/existing components. Thanks, Caty

16 years, 1 month

2
3
0 0

[xwiki-devs] [GSoC] Deadline approaching

by Sergiu Dumitriu

Hello GSoC students, The suggested 'pencils down' date is 5 days away, and the firm deadline is in less than 2 weeks (http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline). Therefore,* at the beginning of next week*, all students should have a *working application* that they should make available to the community for testing. The week of August 10-17 will be used for finalizing the project. Please discuss with your mentors the remaining work that needs to be done before Monday. Good luck, -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 1 month

1
0
0 0

[xwiki-devs] [Proposal] Work left for 2.0 final + Dates rescheduling

by Vincent Massol

Hi, Today is supposed to be the 2.0M3 release date but since we've had lots of delays on 2.0M2 there's no point in releasing M3 today. I've reviewed some of the important tasks we wanted to do in the 2.0 release and that are not done yet: - section editing in 2.0 syntax - JV - XAR in 2.0 syntax (at least for some pages) - All - new skin - Guillaume + Laurent + someone to implement it (?) - macro categories (this one was decided late and wasn't planned initially so I don't think it's a blocker but I'm still listing it here) - Asiri - clustering/distributed events - Thomas - captcha - Jerome - watch list bug fixes (+ activity stream refactoring) - JV - new blog UI - Caty - new User profile UI - Caty Are there any more? The conclusion is that we're very late. We need to decide what we want to skip. From the list I think we should skip the following since the work hasn't been started on them: - new user profile - activity stream refactoring We need to know from each person listed above when he can have finished his part ASAP in order to define new dates (and hoping to preserve the final 2.0 release date). Right now I'd suggest we postpone M3 by one week, i.e. to the 10th of August and move RC1 to 24th of Aug. This would mean a final for the 31st or a RC2 for the 31st and a final for the 7th of Sep. WDYT? Thanks -Vincent

16 years, 1 month

4
6
0 0

Re: [xwiki-devs] [xwiki-users] It's time to tell us what you're looking for!

by Guillaume Lerouge

Hi XWikiers, the first batch of results from the survey is available at: http://www.xwiki.org/xwiki/bin/view/Blog/CurrentSurveyResults It's meant to give you an idea of what the results look like after 50+ answers to the survey. I'll publish detailed results later on, once the survey has been officially closed (in a week or so). Thanks to all of you for your time! Guillaume On Wed, Jul 29, 2009 at 11:51 AM, Guillaume Lerouge <guillaume(a)xwiki.com>wrote: > Hi Ricardo, > > On Tue, Jul 28, 2009 at 11:38 PM, [Ricardo Rodriguez] Your EPEC Network ICT > Team <webmaster(a)environmentalchange.net> wrote: > >> First of all, congratulations to the whole community for the XWiki's 5th >> birthday! >> >> Guillaume Lerouge wrote: >> > Hi fellow XWikiers, >> > While celebrating XWiki's 5th birthday last week, we spent a couple days >> > brainstorming with the full team about where XWiki stands today and what >> its >> > future holds. We came up with a long list of features and ideas and we'd >> > love to get community feedback before deciding in which direction we're >> > going to move forward once our 2.0 release is out. >> > >> > To this aim, we've built a survey that we'd like our users and >> developers to >> > take. It's a bit long though definitely worth the pain. We're eagerly >> > waiting for your feedback to start working on new and existing features. >> > >> > You can access and fill the survey at the following address: >> > http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures >> > >> > Thanks a lot for your time, >> > >> > Guillaume on behalf of the XWiki Team >> > >> > >> >> Please, is there any way of following the results of the survey on-line? > > > Not in real time. We ran another poll internally that used another format > and I need to gather the various results and make all of them follow the > same format before publishing the data. > > The data will be made available in a publicly viewable Google Spreadsheet > as soon as I'm done. > > Guillaume > > After hitting the submit button I've been forwarded to http://xwiki.org. >> Is this te expected behavior? >> >> Thanks! >> >> -- >> Ricardo Rodríguez >> Your EPEC Network ICT Team >> >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> > > > > -- > Guillaume Lerouge > Product Manager - XWiki > Skype: wikibc > Twitter: glerouge > http://guillaumelerouge.com/ > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

16 years, 1 month

1
0
0 0

[xwiki-devs] Support for Google Gadgets in pages in panels

by Ludovic Dubost

Hi devs, I've implemented support for Google Gadgets for pages and for panels. http://incubator.myxwiki.org/xwiki/bin/view/Gadgets/ It is possible to browse the Google Gadget Directory and select a gadget, set it's parameters and either: - insert a call to a gadget macro in a wiki page - create a panel with this gadget It's basically working, except for a few Gadget translations issues in the gadget settings page (for some gadgets). To integrate in XE this requires: - a slight modification to the PanelClass and the displaypanel macro (to support a gadgeturl and gadgetprefs field) - a few pages including a Gadget Groovy page (which requires programming rights) I think we should transform the Gadget Groovy to a plugin to avoid the need for programming rights. We can also from there create a special page type to make a display of gadgets or panels like iGoogle or NetVibes. It would store gadgets or panel lists in a special class with some position parameters. And with some JS we can reposition the panels or gadgets and save the config in the wiki page. This would be an easy way to make some portal like experience in the wiki. Who wants to takeover this from the dev team ? Do you think we can have this in 1.8 ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years, 1 month

5
8
0 0

[xwiki-devs] [ANN] XWiki Enterprise 2.0 Milestone 2 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.0 Milestone 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download The main goal of 2.0 is to make XWiki fully XWiki 2.0 syntax. Main changes from 2.0 Milestone 1: * Lots of improvements and new features in the new WYSIWYG editor * Lots of improvements and bugfixes in the rendering engine and the syntax converter * Improvements for the blog application * It's now possible to choose the content renderer to use when viewing a page * New Footnote macro * New xwiki-properties module * New Latvian translation * New Swedish translation * New Korean translation For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20M2 Thanks -The XWiki dev team

16 years, 1 month

3
7
0 0

[xwiki-devs] [Standars][Components] Icons

by Ecaterina Valica

There are many ways implemented in XWiki for the case when you want to attach an icon to a html element. You can see a small study for the "Delete" icon at http://incubator.myxwiki.org/xwiki/bin/view/Standards/IconsStudyDelete. You can either use CSS to assign a background-image to a <span>, <div>, <input>, <li>, <a>, etc element or you can integrate the icon in the code with <img> element. Using the icons as background images we remove the extra/unnecessarily img code in the HTML and layout problems. The main problem is that consistency of UX and development. We currently have three icons for the "Edit" action ((BlogStyle/edit.png; js/xwiki/usersandgroups/img/clear.png;) silk/pencil.gif; images/black-edit.png )). For the delete example we write the same Css code for the background-image in attachments.css, livetable.css, dataeditors.css, comments.css, etc. Everytime we add an icon, we need to see what is the icon's name and this way is very easy make a mistake in the "standard". I want to propose an *Icons Component* in * platform\web\standard\src\main\webapp\resources\icons\icons.css* . You can read more about it at http://incubator.myxwiki.org/xwiki/bin/view/Standards/CssIcons . This is just a skeleton and doesn't meet all the needs for icons usage (left-aligned icons, right-aligned icons, gifs, pngs, etc). - One problem that can be is the separation in Css files that are dependent one from the other, instead of having them in just one big file (like toucan.css that can be cached by clients). The thing is that the UI components are not dependant of the skin, so putting them in both toucan and albatross (so both benefit from the change) would be wrong. - Having them in separated files, we load them only when needed. The problem is that the files needs to be very well documented and the developers know about their existence. - Another solution (if the cached version is preferred) would be to have a general CSS that imports all the components. This way we serve in one go the CSS files, but still preserve the modularization. - The main advantage is the consistency of the icons usage and the independence of file names. - In the webapp\resources\icons\silk we have many icons that we don't use, but we serve the full silk package. Having a general CSS file, we could know what types of icons we use. This could be a valuable information if we ever would like to change the icons in XWiki. Having them linked in a special place solves the changeability problems. Thanks, Caty

16 years, 1 month

1
0
0 0

[xwiki-devs] Debugging XWiki with IntelliJ IDEA

by Andreas Schaefer

Hi I tried to debug XWiki using IntelliJ IDEA and a remote Jetty server. Everything works fine except that the source code is off. I checked out the trunk (actually http://svn.xwiki.org/svnroot/xwiki/platform/trunks/) , built it with Maven 2. After that I created an installation from enterprise/trunk and installed it, started Jetty in debug mode and started the IDE debugger. Again everything works except that much of the code was pointing to classes. I guess this is because each module uses dependencies to Maven modules that other projects. In order to fix that I downloaded the sources but now the source code lines in the debugger are off. This is because many modules still refer 1.9.2 rather than 2.0- Snapshot or 2.0-m2. Does anyone knows how to make the debugger work? Thanks - Andy

16 years, 1 month

2
1
0 0

[xwiki-devs] Fwd: [xwiki-users] LDAP subscription

by Vincent Massol

(I have pb with my mail client and XWiki mailing list server which is rejecting my email - resending) ---------- Forwarded message ---------- From: Vincent Massol <vincent(a)massol.net> Date: Sat, Aug 1, 2009 at 6:15 PM Subject: Re: [xwiki-users] LDAP subscription To: XWiki Users <users(a)xwiki.org> Hi Geoffroy, On Aug 1, 2009, at 4:32 PM, Geoffroy Carrier wrote: > Hello, > > I'm volunteering as a technician and hoster for the > design-platform.org collaborative project. > > We are seriously considering using to the XEM platform, in particular > for its internalization and multi-wiki support, and its nice WYSIWYG > editor. very cool :) > A major feature we are looking for is LDAP support; however, I didn't > find any information about LDAP subscription. > > The objective is to create LDAP accounts for all subscriptions on the > wiki, and completely avoid XWiki-only subscriptions. Is this feature > already available? > If yes, do you have any pointers to documentation and/or source code? > If not, do you have any thoughts on an efficient way to alter XE to enable it? Yes this is supported, see http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication#HLDAPAut… Let us know if you have specific questions regarding LDAP. Thanks -Vincent

16 years, 1 month

1
0
0 0

[xwiki-devs] [PROPOSAL] Extend RESTful API

by Alexandru Cismaru

Hello. Currently I'm working at a Firefox extension for XWiki and I ran into some troubles because I can't obtain all the information I need from the current RESTful API. I've talked with Sergiu and Marta and they told me that I shouldn't use workarounds and an extension of RESTful API would be more appropiate. It would be useful to add: - a new element for every tag element from tags resource, representing the number of documents tagged with that tag; - a new element for every space element from spaces resource, representing the number of documents in that space; - two new resources: users and user. The information made available for every user could be: username, first name, last name, profile url, avatar, last modified page; - a new element for every page containing the type of the last modification (comment adding, atachment adding, content modification). Thanks, Alexandru Cismaru, gsoc student

16 years, 1 month

2
2
0 0

[xwiki-devs] performance improvement on linux using large-page-support in mysql ??

by Niels Mayer

Has anybody tried enabling "large page support" in Mysql for Xwiki? Doesn't Xwiki make use of Large pages for document attachments and other storage, and wouldn't this be useful for high-volume Xwiki based systems? (Fedora Linux has this feature enabled by default.) The improvement? "Applications that perform a lot of memory accesses may obtain performance improvements by using large pages due to reduced Translation Lookaside Buffer (TLB) misses." Is this worth doing? Would it improve performance (or are bottlenecks elsewhere that make this tweak irrelevant)? ............ http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html says: > On Linux, if the kernel is enabled for large page support, InnoDB can use > large pages to allocate memory for its buffer pool and additional memory > pool. See Section 7.5.9, “Enabling Large Page Support”. --> http://dev.mysql.com/doc/refman/5.0/en/large-page-support.html says: > 7.5.9. Enabling Large Page Support > Some hardware/operating system architectures support memory pages greater > than the default (usually 4KB). The actual implementation of this support > depends on the underlying hardware and operating system. Applications that > perform a lot of memory accesses may obtain performance improvements by > using large pages due to reduced Translation Lookaside Buffer (TLB) misses. > In MySQL, large pages can be used by InnoDB, to allocate memory for its > buffer pool and additional memory pool. > Currently, MySQL supports only the Linux implementation of large page > support (which is called HugeTLB in Linux). > Before large pages can be used on Linux, the kernel must be enabled to > support them and it is necessary to configure the HugeTLB memory pool. For > reference, the HugeTBL API is documented in the > Documentation/vm/hugetlbpage.txt file of your Linux sources. > The kernel for some recent systems such as Red Hat Enterprise Linux appear > to have the large pages feature enabled by default. To check whether this is > true for your kernel, use the following command and look for output lines > containing “huge”: > shell> cat /proc/meminfo | grep -i huge HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 4096 kB > The nonempty command output indicates that large page support is present, > but the zero values indicate that no pages are configured for use. > If your kernel needs to be reconfigured to support large pages, consult the > hugetlbpage.txt file for instructions. > Assuming that your Linux kernel has large page support enabled, configure > it for use by MySQL using the following commands. Normally, you put these in > an rc file or equivalent startup file that is executed during the system > boot sequence, so that the commands execute each time the system starts. The > commands should execute early in the boot sequence, before the MySQL server > starts. Be sure to change the allocation numbers and the group number as > appropriate for your system. > [...] > With this option, InnoDB uses large pages automatically for its buffer pool > and additional memory pool. If InnoDB cannot do this, it falls back to use > of traditional memory and writes a warning to the error log: Warning: Using > conventional memory pool > To verify that large pages are being used, check /proc/meminfo again: > shell> cat /proc/meminfo | grep -i huge HugePages_Total: 20 HugePages_Free: 20 HugePages_Rsvd: 2 HugePages_Surp: 0 Hugepagesize: 4096 kB Niels http://nielsmayer.com

16 years, 1 month

1
0
0 0

[xwiki-devs] Build Broken in xwiki-core

by Andreas Schaefer

Hi Doing a build today I saw that it is problem in the xwiki-core/pom.xml updated by you. It is a case of a missing S at the end of xwiki-core-rendering-macro-footnote(s). Cheers Andreas Schaefer CEO of Madplanet.com Inc. EMail: andreas.schaefer(a)madplanet.com schaefera(a)me.com Twitter: andy_mpc AIM: schaefera(a)me.com

16 years, 1 month

2
1
0 0

[xwiki-devs] Blog Rss Upgrade Vows

by Andreas Schaefer

Hi As the last items on the Blog 2.0 Upgrade I wanted to upgrade the RSS documents like GlobalBlogRss. There I ran into the issue that the renderer (I don't know which) is adding the macro as comment to the beginning of the XML file but that is not allowed because the <?xml must start the file (not even spaces are allowed). The upgrade code looks like this: {{include document="Blog.RssCode"/}} {{velocity filter="none"}} {{html clean="false" wiki="true"}} ## ## ## #getGlobalBlogEntries($entries) #set($entries = $xwiki.wrapDocs($entries)) #displayGlobalBlogRss($entries) {{/html}} {{/velocity}} The page output looks like this: <p> <?xml version="1.0" encoding="UTF-8" ?> Does anyone know how to remove that comment or how to generate proper XML content with 2.0? If anyone can point me to some code that does that would be enough to get me started. Cheers - Andy

16 years, 1 month

1
0
0 0

[xwiki-devs] Distributed events

by Thomas Mortagne

Hi devs, I'm currently working on a network event distribution system. The goal is to be able to shared events across XWiki instance (or not XWiki) of a same network groups. There is two target: - unique easy clustering channel: if every XWiki instance of a network group share the events it's becoming easy to make sure all instance of the same cluster are synchronized and not only the code which is using default cache system - a new push communication interface to know what append on a farm for network administrator or for softs like XWord and XEclipse to easily update pages list etc... To summarize I plan to do a Remote Observation Manager module which send events coming for Observation Manager and inject in it events coming for the network. See http://dev.xwiki.org/xwiki/bin/view/Design/DistributedEvents for more details (like events converters etc...). For now my choice is on jgroups for the network part which is simple to use, very configurable and well known. I looked at some other like JMS or Hazelcast but after all, I think jgroups contains all i need and is very light. Would be great if some of you who has experience on this (or not) could shoot with all remarks and suggestions. I should be able to commit a first try based on jgroups this week on sandbox. Thanks, -- Thomas Mortagne

16 years, 1 month

5
8
0 0

[xwiki-devs] [VOTE] Release XWiki Enterprise 2.0M2

by Thomas Mortagne

Hi devs, We are more than two weeks late already and 2.0M2 is finally is a stable enough state to be released. Note that it 68 jira issues has been closed since 2.0M1. Here is my +1. -- Thomas Mortagne

16 years, 1 month

5
5
0 0

Re: [xwiki-devs] [VOTE] Release XWiki Enterprise 2.0M2

by Jean-Vincent Drean

+1 JV. On Thu, Jul 30, 2009 at 10:55 AM, Jean-Vincent Drean<jvdrean(a)gmail.com> wrote: > +1 > > JV. > > On Wed, Jul 29, 2009 at 8:02 PM, Thomas > Mortagne<thomas.mortagne(a)xwiki.com> wrote: >> Hi devs, >> >> We are more than two weeks late already and 2.0M2 is finally is a >> stable enough state to be released. >> >> Note that it 68 jira issues has been closed since 2.0M1. >> >> Here is my +1. >> >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> >

16 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs