xwiki-devs December 2011

xwiki-devs@xwiki.org

24 participants
49 discussions

[xwiki-devs] [Discussion] Problematic ColorTheme extensibility

by Ecaterina Moraru (Valica)

Hi, Since we introduces ColorThemes in XE 2.0 we've used them constantly, being a great improvement for the cases when we wanted to rapidly change the color variables used. The problem with the ColorThemes is that they contain a limited number of variables. There are places in Colibri where we've recycled and used variables that were not intended to be used there, for example: - Administration's vertical-menu is using $theme.panelCollapsedBackgroundColor (which was intended for the collapsed state of the panels); - Suggest search results is using for it's .resultContainer also $theme.panelCollapsedBackgroundColor; - etc. Also there are some variables in the ColorThemes like $theme.textPrimaryColor and $theme.textSecondaryColor or even $theme.backgroundSecondaryColor that are used quite randomly in the code (all being shades of gray in the default theme). Not knowing exactly what is the purpose and usage of a color is very easy when you create a ColorTheme to chose colors that in practice will not provide enough contrast or that will not look very nice together. Since their release, we've added just 6 new variables (2 for the "Add" menu and 4 for the notifications colors: warning, error, success and info). One of the reason behind not adding new colors was not to confuse the user with a wide range of color variations. The colortheme wizard was great at making it easy for the user to change the 36 variables, but having 50+ variables to set could be a difficult/complex task even when using a Wizard. Although when we created ColorThemes we had in mind that they will be skin independent I don't know if in practice this will be still valid. When we're going to create a new skin for XE it will have a different layout, a different semantic of the variables names and a different color pool need. These needs are not mappable on what we currently have. So I think the ColorThemes should be skin dependent and also version dependent in order to assure that is gonna look the way it was originally intended to look. For example I want to add some CSS3 gradients for the 3.4 Colibri skin, but I don't have enough variables to specify the gradient shades. To solve that I've used non semantically variables combinations like: background-image: -moz-linear-gradient(top, $theme.linkColor 0%, $theme.buttonPrimaryBackgroundColor 100%); background-image: -moz-linear-gradient(top, $theme.pageContentBackgroundColor 0%, $theme.buttonSecondaryBackgroundColor 100%); Even though the combination will work for the ColorTheme defined specially for XE 3.4, this means the other existing ColorThemes will be used in a way they were not designed for (like ColorThemes.Bordo theme, etc.) thus not being as good looking as before when applied on the new skin. The same use case will be for any other skin that we will create for the XE 4.x. IMO you can't assume that any defined colortheme will work "graciously" independent of the skin applied and version used. (they will work but the color mix will be random). So another solution would be add more colors to the ColorTheme. For variation of Colibri this will work, but for a new skin (that maybe will not have 2 sets of menus, or will not have 2 separate colors for the background and the content) all the semantic behind the variables naming will fail. We will end up with variables inside the colortheme that may never be used inside the new skin code and I don't even imagine how the ColorTheme Wizard would look like (a nice idea would be to adjust itself dynamically dependent of the enabled skin). Also I want to know what is your opinion regarding adding new variables. What is the backward compatibility strategy for that? Right now, we have a fallback ColorTheme that provides fallback colors in case the ColorTheme doesn't have those colors set. But this does not assure that installing an "old" red colortheme will look nice with the fallback blue colors. We are not telling the user anywhere that there are missing colors in the installed colortheme and also in the wizard is hard to know what colors are defined and what are the fallback ones (if you know what colors are missing than you can manual define them and you don't need to cover all wizard dialogs in order to find the inconsistencies). So IMO the only solution is to have ColorThemes designed dependent of a skin and a version, with the possibility to let the user manually enhance and reuse old colortheme to work on the new versions. Maybe you have other solutions. Thanks, Caty

12 years, 8 months

[xwiki-devs] [Announcement] XWiki Enterprise 3.3 and XWiki Enterprise Manager 3.3 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.3. Following the goals established for the 3.x cycle, XWiki Enterprise 3.3 delivers the first usable but experimental versions of App Within Minutes and Extension Manager features. The highlights of this release are: * Experimental "App Within Minutes" feature * Improved Extension Manager * Automatic external link checker * Better support for exporting CJK documents as PDF * LDAP user membership improvements * Attachment handling improvements * Debian packages for installing XWiki See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise33 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 8 months

[xwiki-devs] [Proposal] Community-sourcing of our compatibility grid

by Vincent Massol

Hi devs, Here's something I'd love to see: The idea is the following: * Allow end users to install the extension and run the tests on their current XWiki Enterprise instance * At the end of the test make the extension publish the result by POSTing the result to a xwiki.org URL. The results should include: ** XE version ** DB version ** DB driver version ** Browser version ** Console logs ** Screenshots taken * Display test results on several places of xwiki.org: ** On a general compatibility page ** On the Installation page for specific Servlet Containers and Databases Note that we need to improve a bit the test suite so that: * All tests create data in a Test space * If a test requires a default page of XE we need to verify it contains what we need before the test starts and if not then mark the test as skipped instead of failing it * Tests work independently of what data already exists in the wiki I've entered it as a jira here: http://jira.xwiki.org/jira/browse/XE-1064 WDYT? Thanks -Vincent

12 years, 8 months

[xwiki-devs] [VOTE] Adding the Locale into the document reference of XWikiDocuments

by Denis Gervalle

Hi Devs, I am looking at now using the new Locale added in DocumentReference into the implementation of XWikiDocument. I have already deprecated language related stuff in XWikiDocument, and I have introduce a XWikiDocument#getLocale and an XWikiDocument#isTranslation helper since the deprecation of defaultLanguage will increase the need of it. I have also added XWikiDocument#getTranslatedDocument() with Locale in place of language. All the changes are almost backward compatible, which is nice (there is some subtleties with default, "" and null that is now more equivalent, but should not have consequences). The is however one change that is not backward compatible, which is the change of the document reference. Therefore, XWikiDocument#getDocumentReference does not return the same reference than it does before, because this reference now contains the Locale. This cause breakage in several places. I see some option to fix this: A. Fix all places broken. This may be too long for me, and not trivial. B. Introduce a new XWikiDocument#getDocumentReferenceWithLocale() and have XWikiDocument#getDocumentRefence() returns without Locale. Very easy, but not nice. C. Introduce a new XWikiDocument#getDocumentReferenceWithoutLocale() and change all existing calls to XWikiDocument#getDocumentRefence() in platform to use this one. Nicer, but this is not fully backward compatible. Since I am on it right now, I would appreciate your opinion quickly. WDYT ? I am undecided between B and C -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

12 years, 8 months

[xwiki-devs] [Proposal] Improving the "Product Documentation" and "Getting Started" pages

by Silvia Rusu

Hi, Caty and Vincent are doing a very nice job improving xwiki.org's look and navigation. I think improving a bit the content is also a good idea, so I have a few proposals in this direction. * Improving the Documentation landing page, available from the website menu (http://www.xwiki.org/xwiki/bin/view/Main/ProductDocumentation). Here is a proposal with some small additions: http://dev.xwiki.org/xwiki/bin/view/Drafts/DocumentationImprovedHomepage * Improving the Getting Started guide's WebHome (http://enterprise.xwiki.org/xwiki/bin/view/GettingStarted/WebHome). Draft proposal at: http://dev.xwiki.org/xwiki/bin/view/Drafts/GettingStartedPage * We could also use the "Getting Started" page proposed above on XWiki Enterprise (the product). This would be a page inside the wiki (e.g. like the Sandbox or Syntax pages) which would be linked from the wiki Homepage. It could be helpful to wiki users who don't know where to look for information. Waiting for your feedback and votes. Thanks, Silvia

12 years, 8 months

[xwiki-devs] [VOTE] Change the default to non-backup instead of backup import when creating a new wiki template from xar in the wiki-manager module

by Eduard Moraru

Hi devs, Right now, when you create a wiki template from a xar, the import that is done in the background is a backup import, meaning that the last author of the pages that get imported in the new wiki keep the author specified by the xar. This often creates problems like: - Missing Programming Rights - Unregistered macros - Malfunctioning scripts These problems can appear because the user specified in the xar (even if it is XWiki.Admin) is almost always a local user and subwiki local users do not have PR. If it's not a PR issue, then the user specified in the xar can be non-existent and this makes admin checks fail, thus failing wiki macro registration for the entire subwiki. We are currently experiencing this problem in Workspaces, since, at the install step, we create a workspace template by using a workspace-template.xar (default XE but can also be user provided). Since we make sure to delete any local users (including XWiki.Admin), the Wiki macros will not be registered in the template and, obviously, neither in any created workspace. I`m hoping to include this in 3.3 final so that Workspaces can avoid the macro registration problems (and possibly others). So I`m asking for your vote to change the current default to non-backup. This means that all the pages in the new subwiki template will have the current admin user that created the template as last author. Here's my +1. Thanks, Eduard

12 years, 8 months

[xwiki-devs] Use complex expressions in i18n choice

by coldserenity

Hello, Doing a translation I found this message to translate {0,choice,0#No|1#One|1<{0}} included {0,choice,0#documents.|1#document:|1} So I wonder is it possible to use arithmetic expression like {0}%10 in those choice statements because in my language, the noun's ending depends on the last digit in a number . Directing me to the page describing full syntax for the language above would be enough. Regards, Roman -- View this message in context: http://xwiki.475771.n2.nabble.com/Use-complex-expressions-in-i18n-choice-tp… Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 8 months

[xwiki-devs] Why h1 in panel headers ?

by Jerome Velociter

Hello, I've realized recently that panel titles are exposed in h1. For example : <h1 class="xwikipaneltitle">Quick Links</h1> I don't think that's the best we can offer semantically. Panels are not very import sections of the page. Maybe h2 would be more appropriate ? WDYT ? Jérôme Velociter Winesquare http://www.winesquare.net/

12 years, 9 months

[xwiki-devs] Changes in the XEM distribution to workspace cause unexpected issue to existing XEM users and even new ones

by Denis Gervalle

Hi devs, I have just installed the XEM distribution has an upgrade of an existing farm. I have discovered that the new distribution cause an new DB to be created without any confirmation on first access to Main.WebHome to contains the workspace template required by the new workspace feature. IMO, this does not follow the vote we have had before about this change, since existing user of XEM are immediately impacted by the new feature. I would have been -1 if I would have been aware of this. Creating the new database this way has for me some inconveniences: - For new user, after having a possibly hard time setting up the server, there first successful access on the wiki could end in an error, since the creation of the new database could goes wrong. - For existing user, a new database is created without there agreement on there farm. If they delete it, it will probably came back again and again... They really need to understand that the simple access to the home page cause the creation of a new database. IMO, these are not good first experiences with the new release. I propose that the creation of the new database requires at least a user confirmation, and that if the user do not confirm, it should not be tried anymore. This will have two advantage, the user is well aware that a other new database is under creation in case of error, and existing farm user will have an easy way out. WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

12 years, 9 months

[xwiki-devs] XEM Workspaces Install

by Ludovic Dubost

Hi, I just tried the XEM snapshot and got an error when trying to configure it. I get this after login as Admin: Workspace Manager translations have been successfully installed. Workspace search suggestions have been successfully installed. Error installing workspace template. null Workspace template features can not be installed without the workspace base template being installed first. I also agree with Denis that any install should be done with a confirmation. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2011