xwiki-devs November 2012

xwiki-devs@xwiki.org

30 participants
78 discussions

by Marius Dumitru Florea

Hi devs, I committed an improved User Picker in the feature-xclass-property-component branch. You can see some images on http://jira.xwiki.org/browse/XWIKI-4022 . I'd like to integrate it in the platform. Thanks, Marius [1] https://github.com/xwiki/xwiki-platform/compare/feature-xclass-property-com…

11 years, 10 months

[xwiki-devs] [VOTE] Name of the localization module script service

by Thomas Mortagne

Hi devs, Quick vote on the name of the localization module: * $services.l10n * $services.localization something else ? I'm ok with both even if "localization" is a bit "cleaner". -- Thomas Mortagne

11 years, 10 months

[xwiki-devs] [VOTE] Name of the localization macro name

by Thomas Mortagne

Hi devs, Quick vote for the macro name: * {{l10n}} * {{locallization}} localization is a bit too long for a macro so I would go for "l10n". We can also decide to maintain both aliases. -- Thomas Mortagne

11 years, 10 months

[xwiki-devs] How to Include a page without velocity code into another page

by Geo Du

Hi All, I want to include one page into another page in terms of content instead of velocity code, for example, the Blog.WebHome is a page without velocity code if you choose Edit->Wiki, but it has Blog.BlogClass if you select Edit->Objects, from Blog.WebHome page, I can create a new post with tile testpage, now the Blog.testpage is the new page created that I need to include into another page, this testpage has no velocity code from Edit_>Wiki. so how to include that page into a different page? I tried: include Macro, includeInContext Macro, includeTopic Macro, none of them displays the testpage for me, any idea? Thanks very much for your help. David

11 years, 10 months

[xwiki-devs] [Vote] Use the Date Picker from AppWithinMinutes as the default picker for Date XClass properties

by Marius Dumitru Florea

Here's the commit https://github.com/xwiki/xwiki-platform/commit/a6f4bd499fc2b1cf3757d423205a… . The main changes are: * Move the JS/CSS of the date picker used by AppWithinMinutes into the file system (/resources/uicomponents/widgets/datepicker). * Apply checkstyle to DateProperty and DateClass. * Modify DateClass to use the AWM date picker when the 'picker' meta property is set. * Add back the 'picker' meta property to Date property (in DateMetaClass) to allow developers to use a different picker than the default one (or no picker at all). * Use Boolean property for 'picker' and 'emptyIsToday' meta properties (was Number property). Since a Boolean property is stored as an integer property the only difference will be visually (checkbox instead of text input). I'd like to merge this into the platform. My +1. Thanks, Marius

11 years, 10 months

[xwiki-devs] [VOTE] Add xwiki-platform-wiki-manager-api as a dependency for XE - Pull request "Add REST APIs for creating wikis and importing XARs"

by Fabio Mancinelli

Hi everybody, I will try to go forward in committing REST API improvements made by Ludovic and me. Looking at the discussion about the pull request I opened https://github.com/xwiki/xwiki-platform/pull/68 Thomas pointed out the fact that it brings "xwiki-platform-wiki-manager-api" as a dependency in XE, and this might require a vote. xwiki-platform-wiki-manager-api is something that was bundled only in XEM and not in XE. I added it as a dependency because I use its code for performing wiki creation and XAR importing. Thomas' comment is here: https://github.com/xwiki/xwiki-platform/pull/68#discussion_r1335333 So the vote is about the bundling of xwiki-platform-wiki-manager-api in XE for merging this pull request. I am +1, of course. Thanks, Fabio

11 years, 10 months

[xwiki-devs] [VOTE] Merge feature-localization branch to master

by Thomas Mortagne

Hi devs, I would like to merge the https://github.com/xwiki/xwiki-platform/tree/feature-localization branch to master. Here is a summary of what it contains: * new localization module API following what described in http://markmail.org/message/blynasgz53ys345i * implementation of this API for ApplicationResources resources and document bundles listed in the preferences * implementation of this API for dynamically registered wiki document translations as described on http://markmail.org/message/bcmbhpwxnbagma3g Here is my +1. Thanks, -- Thomas Mortagne

11 years, 10 months

[xwiki-devs] [VOTE] Property declarations for the execution context

by Andreas Jonsson

Hi Everyone, I would like you to vote on merging the feature-execution-context branches of commons and platform before the release of 4.3M2: https://github.com/xwiki/xwiki-commons/compare/master...feature-execution-c… https://github.com/xwiki/xwiki-platform/compare/master...feature-execution-… Explanation of the feature: The execution context is a simple map that binds a string to an object. This can be compared to how variables are handled by scripting languages such as bash, where an assignment brings the variable into existance: $ my_variable="some value" In the case of the execution context, the syntax is: context.setProperty("my_variable", "some value"); This feature is about adding property declarations, where a property can be associated with attributes that controls how the execution context and execution context manager handles the property. The general idea can, once again, be compared to bash and how it is possible to declare variables there: $ declare -ru my_variable="read only, forced upper case" Of course, the set of attributes that are interesting to us is different from bash. Currently the feature branch have support for declaring properties with these attributes: * Final - The value may not be updated within the the execution context. Default: false. * Inherited - The property will be inherited from the current context when replacing the execution context within the current scope. Default: false. * Cloned value - Also clone the value when the execution context is cloned. Default: false. * Type - The class of the value, for typechecking when setting the value. Default: null (unchecked). * Non-null - The value may not be null, checked when setting the value. Default: false. Example declaration: ExecutionContextProperty property = new ExecutionContextProperty("my_variable"); property.setValue("some value"); property.setType(String.class); property.setInherited(true); context.declareProperty(property); The property value may be updated and the property may be removed and redeclared, unless declared 'final': context.setProperty("my_variable", "some new value"); context.removeProperty("my_variable"); Additional attributes may be added later. This feature is also backwards compliant, in that implicit declaration by just setting a value is allowed. (Although we might want to make explicit declarations mandatory in the future.) Within the scope of a request, or the life time of a thread executing some administrative task (e.g., the lucene index updater) the basic life cycle of the execution context is the following: @Inject Execution execution; @Inject ExecutionContextManager ecm; ExecutionContext context = new ExecutionContext(); ecm.initialize(context); try { // Do work } finally { ecm.removeContext(); } Within the life cycle of the "root" execution context, we may push a new execution context, which may either be a clean context, or a clone of the current context: // Pushing a clone ExecutionContext context = ecm.clone(execution.getContext()); execution.pushContext(context); try { // Do work } finally { execution.popContext(); } // Pushing a clean context ExecutionContext context = new ExecutionContext(); execution.pushContext(context); try { // Do work } finally { execution.popContext(); } Component authors that needs to place a value in the execution context provides an initializer that declares the variable and sets an initial value. The attributes 'final', 'cloned value', and 'inherited' lets component authors control how the value is managed during the lifecycle of the root execution context. The attributes 'type' and 'non-null' provides some runtime assertions to catch some errors earlier. So to summarize, this feature: 1. is a convenient mechanism for managing properties in the execution context, 2. provides some validation of the property values, 3. improves performance slightly by avoiding unnecessary cloning. For more information, see the proposal thread: http://xwiki.475771.n2.nabble.com/PROPOSAL-Execution-context-property-decla… Best Regards, /Andreas

11 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2012