January 2010 - xwiki-devs@xwiki.org

[xwiki-devs] [Idea] Reorganizing the Administration section: presentation
by Sergiu Dumitriu 04 Jan '10

04 Jan '10

Hi devs, There are many things that could be improved in the XWiki Administration, but for the moment I would like to discuss the Presentation part, which is one of those most likely to be accessed by newbies, and should be easy to deal with. Currently, the Presentation allows to configure the following topics: - Header: title bar text and meta information - Panels: whether to show panels on the right/left, and the list of panels to display in each column - Footer: copyright notice and version - Skin: Skin document, Color theme, Default stylesheet, other stylesheets Problems: - IMO, some fields are not really presentation related: title, meta information, copyright notice, version info - It is not easy to list the panels you want without any help or suggestion - The panel columns and panel list configuration feature is also available in a friendlier form in the Panel Wizard section of the administration, but there is no reference to it from the Presentation section - There is no suggestion about available skins, and the user is not "warned" that customizing the skin actually means changing templates and css - "Default stylesheet" and "Other stylesheets" mean nothing to someone who didn't look in the skin directory; also, as I see it, they are only useful for the Toucan skin (where there were several pre-defined stylesheets for different colors), while in the Colibri skin -- and probably the other skins that will be developed from now on -- we use Color themes for changing the look. Proposed changes: - Move Header and Footer topics to the General section - Keep 4 topics: Page layout, Panels, Color theme, Advanced skin configuration, displayed in a horizontal tab bar (like the one in AllDocs) [Page layout] - Use something similar to the Page Layout tab form the wizard to choose if the right/left panels are shown [Panels] - Continue to allow listing the panels in input fields, since for some users it is faster and easier than playing with the panel wizard, but attach an AJAX suggest to those input fields - Display the Panel wizard (and remove the panel wizard section form Administration); Note: the panel wizard will need some adjustments for this to be possible. [Color themes] - Integrate the ColorTheme "application" (or soon to be application): allow browsing, previewing and selecting available color themes, and creating a new color theme [Advanced skin configuration] - Inform the user that he would need to write his own templates and stylesheets, either in the provided textareas or in files attached to the corresponding skin object - Allow to browse, preview and select skins There are many changes, and they will require much more than a couple of days (there won't be time for them to show up in 2.2, for example), but if we agree, they can be progressively integrated in future versions. -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

[xwiki-devs] Smart GWT 2.0 released
by Vincent Massol 04 Jan '10

04 Jan '10

fyi, mostly for our wysiwyg developers: http://www.ongwt.com/post/2009/12/15/Smart-GWT-2.0-has-just-been-released Thanks -Vincent

4 4

[xwiki-devs] Rewriting LDAP for upward sync
by Jessica Hawkwell 04 Jan '10

04 Jan '10

Hi everyone! I'm starting on a re-implementation of the LDAP implementation for XWiki, an implementation that performs upward sync instead of downward sync (updating LDAP instead of updating XWiki). This is for a unified platform we (a friend and myself) are working on where XWiki is the "master app". After reading through (some of) the sources for xwiki-core, it seems to me the entire LDAP infrastructure is located in 2 packages: com.xpn.xwiki.plugins.ldap.* and com.xpn.user.impl.LDAP.* Before I begin, I'd like to confirm this so I can focus exclusively on the code I need to re-implement and not have any surprise LDAP dependencies creep up later on. So, am I correct that these are the packages that need to be rewritten for upward sync? Tanks!

3 3

[xwiki-devs] [Proposal][Model] Entity References - Absolute vs Relative
by Vincent Massol 04 Jan '10

04 Jan '10

Hi devs, I'm almost done with my entity reference refactoring and I've just realized I have missed something I think. So far the implementation only supports Absolute references (i.e the entity reference factory always return a reference with all parts filled - you choose to use a default factory or a current entity depending on how you wish to resolve the names when they have not been provided in the passed reference string). I now think we must also support relative references (i.e. when some parts can be null) and that it's up to the user of the api to decide if they want to convert a relative reference to an absolute one or not. Here's a use case: renaming of documents. For exemple documents have links specified as a string representing the target doc name. If we don't have relative references then we need to decide if we want to use the default serializer (all parts printed including wiki name) or the compact serializer (only parts different from context reference printed). This doesn't support printing only what the user had decided to fill. For ex a user might have specified voluntarily the space and page name and right now with my implementation he'll get only the page name specified if the new space is the same as the space for the current doc. So here's my proposal: * Entity Reference Factory leaves parts to null when not specified in the string representation. * We add a EntityReference.getAbsoluteReference(EntityReference base) method to return an absolute reference. It's resolved against the passed base reference (i.e. parts not specified are taken from it) WDYT? I'm going to start refactoring my code to do this later today so please let me know if you see any pb with it. Thanks -Vincent

5 12

[xwiki-devs] XML Encoding for Application Development
by Andreas Schaefer 04 Jan '10

04 Jan '10

Hi For the development of the Groovy based Blog I just developed the code in IntelliJ, copied inside a browser and eventually exported the content into a XAR file. Slowly but surely this is getting way to much work especially when doing sweeping changes. Because I don't use Eclipse I am not able to use the XEclipse tool but I was wondering if anybody knows a way to XML encode text (within Maven2) so that it later could use Ant's copy and filter tool to incorporate the developed code / content inside the XML file that will build up the XAR file. Thanks - Andy

4 11

[xwiki-devs] [VOTE] Strategy for handling translations
by Vincent Massol 02 Jan '10

02 Jan '10

Hi devs, We need to define a strategy for better handling translations. I've had a call with Guillaume and Jean-Vincent and here's the process we'd like to propose: * One person is in charge of http://l10n.xwiki.org/. This means monitoring the work there, coordinating validation of key values and ensuring validated translations are incorporated in the source tree. Guillaume is willing to take that role for now. * The XE release manager has the responsibility of taking the validated keys on l10n.xwiki.org and committing them during the Milestone 2 dev (before the RC1). * The l10n manager should ping the release manager whenever there are translated and validated keys ready to be incorporated or if there have been important changes to be included in the release after M2 has been released. * The l10n manager should test XE and the applications after the keys have been applied to ensure quality. Basically the l10n manager is responsible for the quality of translations in general. Here's my +1 Thanks -Vincent

10 20

[xwiki-devs] SVG editing
by Vincent Massol 01 Jan '10

01 Jan '10

Might be interesting to integrate with XWiki: http://code.google.com/p/svg-edit/ Anyone interested? Thanks -Vincent

2 1