xwiki-devs July 2011

xwiki-devs@xwiki.org

26 participants
50 discussions

[xwiki-devs] [Proposal][UX] Application Within Minutes - Fields Parameters (I1)

by Ecaterina Moraru (Valica)

Hi devs, I did some work on the *fields parameter importance* and on the *displayers* we already have: String, TextArea, Static List and Database List integrated into Single Line Text, Paragraph Text, Radio Button, Checkboxes and Drop Down fields. The proposal covers what fields will be displayed in simple and advanced modes for these fields types. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinM… Thanks, Caty References: [1] [Proposal][UX] Application Within Minutes - Proposal 2: http://markmail.org/thread/beflzm3xeenfpnrh [2] http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AWMListManagement

13 years, 1 month

[xwiki-devs] XWiki Android Client Status

by Chamika Weerasinghe

Hi all, I've finished XWiki android client to some extend with following features. Login - HTTP Basic Auth. XWiki navigator - tree style xwiki navigator to explore wikis, spaces and select pages. XWiki Page Viewer - Simply shows the content of a page via accessing Objects and Properties of REST model. This will be developed further XWiki Object Viewer - Explorer objects of a given page. These are the screenshots of the xwiki android client https://picasaweb.google.com/chamikaw/Xwiki?authuser=0&authkey=Gv1sRgCLet4s… Improvements: 1. After modifying XWiki navigator to load dynamically as Thomas requested, it take more time since many http requests are handled. I will improve by reducing number of http requests as soon as possible. Until then xwiki navigator works but it's unstable and take long time to load. 2. xwiki classes view will implement within next week. Issue solved: Although repository can be built using maven it will not produce correct apk file to deploy in android devices. This issue is solved by using Maven Android Plugin 2.9.0-beta-1 release. Now generated .apk file in xwiki-android-client can be deployed in android devices. Please be kind to test it and give your opinions for improving. Best Regards, Chamika Weerasinghe

13 years, 1 month

[xwiki-devs] Extension Manager plan for 3.2

by Thomas Mortagne

Hi xwikiers, Here is a quick status of Extension Manager work in progress and what we (Jean-Vincent Drean and me) plan to do for 3.2. = XWiki Repository = 3.1 main target was XWiki Extension Repository and work on it will continue in 3.2 as well Conversion of extensions.xwiki.org as a XWiki Extension Repository slipped a bit but that will hopefully be fixed during 3.2. What makes it complex is that REST URLs are going to be changed during 3.2. I'm still not sure what's the best between use a 3.2 snapshot of XR rest service which wil not work with 3.1 or keep 3.1 which will not work with 3.2 = Virtual extensions = Currently we have an issue when trying to install old stuff depending on extensions for which the name changed like xwiki-core which is now xwiki-platform-oldcore so to take care of that 3.2 will introduce virtual extensions. The id is that an extension can comes will a list of id aliases which will be use as well as its own id to resolve dependency agains already installed extensions. For example org.xwiki.platforms :xwiki-platform-oldcore will declare com.xpn.xwiki.platform:xwiki-core in its virtual extension list so when an old plugin is installed using extension manager it does not try to actually install the version of com.xpn.xwiki.platform:xwiki-core declared by the plugin and make XWiki pretty much unusable. This will also allow to more easily suport several implementations for the same API, all theses implementations would declare the same virtual extension id. This is very similar to Debian virtual packages concept. See http://jira.xwiki.org/jira/browse/XWIKI-6742. = Reporting improvement = A bridge producing events based on log as just been committed, the idea is to have a generic way for component to access application logs easily. This can be used later with activity stream or remote observation manager. For Extension Manager the plan is to use that in the job manager (former task manager) to gather detailed log produce by extension manipulation job like install or uninstall and queue it in the job status. On the same idea a progression system has just been committed in extension manager which update a progress offset during job execution using events. Job Manager and both related progress and log tools are currently "hidden" in extension manager but will be move as common tools when we are happy enough with it to make easier to report progress or long task in XWiki (Lucene indexing, report page rendering log in some tab, etc.). See http://jira.xwiki.org/jira/browse/XWIKI-6781 = Non interactive 3 ways merge of XAR = Xar handler will support full 3 way merge of applications between previous xar, new xar and database. 3.2 will probably be fully non interactive as a first version but we plan to implement a question/answer system allowing to let user do live conflict resolution since there is always corner case where a generic automated system can't find any good solution. See http://jira.xwiki.org/jira/browse/XWIKI-6650. = Stabilized API = Starting with 3.2 most Extension Manager APIs will not be broken without long deprecation phase when possible as any other public API in XWiki. BTW to make sure I'm not lying too much would be great to get as much review as possible on theses ;) = New UI = Last but not least we will start the real (as not just a demo of the framework features) Extension Manager UI in 3.2. The plan is to follow Ecaterina Valica's (awesome) proposal you can see on http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ExtensionManager. To be more precise we should be able to do the following for 3.2: * general UI refactoring based on http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ExtensionManager to some extent * detailed progress and log of extensions manipulation thanks to new framework APIs * extension detailed informations * live table for search result See http://jira.xwiki.org/jira/browse/XWIKI-6775 Thanks, -- Thomas and JV

13 years, 2 months

[xwiki-devs] [proposal] Enable CSRF protection by default during the testing phase of 3.2

by Alex Busenius

Hello devs, I'd like to enable CSRF protection by default at least until 3.2-RC1 for testing purposes. The CSRF protection mechanism as been added in 2.5, but is still disabled by default, because many functional tests used to fail with CSRF protection (false positives). I have fixed the tests to work with CSRF protection, so we can try to enable it and test on a larger scale, maybe even on myxwiki.org (with RC1). If no critical bugs will be found during the testing, I'll call a vote to let it enabled in 3.2 final. Implementation note: Enabled CSRF protection puts some restrictions on possible requests that should be respected by the tests. For example, it is not possible to construct a request that logs-in as admin and deletes a page using xredirect, something that is used in UI tests for speedup. We might want to refactor the test utils a bit to discourage doing such things. Commits: * Branch enabling the protection by default https://github.com/xwiki/xwiki-platform/tree/enabled-csrf-protection * Branch with fixes for functional tests https://github.com/xwiki/xwiki-enterprise/tree/enabled-csrf-protection Bugs: http://jira.xwiki.org/jira/browse/XWIKI-6773 http://jira.xwiki.org/jira/browse/XWIKI-5465 Here is my +1 WDYT? Thanks, Alex

13 years, 2 months

[xwiki-devs] rest API does not return information by querying /wikis/wiki1/spaces in XEM-3.2-snapshot

by Jun Han

Dear all, After deploying XEM-3.2-snapshot, I created a wiki called wiki2. In XEclipse or browse http://localhost:8080/xwiki/rest/wikis, three wikis can be found, xwiki -> main wiki templatexe -> template wiki2 -> newly created wiki Then I tried to navigate in XEclipse or just use a browser. Information for all the spaces is not fetched via the URL http://localhost:8080/xwiki/rest/wikis/wiki2/spaces However, if I type the URL in the browser 1. http://localhost:8080/xwiki/rest/wikis/wiki2/spaces/Main 2. http://localhost:8080/xwiki/rest/wikis/wiki2/spaces/Main/pages The information for Main space and its pages shows up correctly. I am not sure if this is a bug in REST API. Best regards Jun Han

13 years, 2 months

[xwiki-devs] Mechanism to deprecate phrases?

by Paul Libbrecht

Hello XWiki developers, In Curriki, we have about 4000 translation keys... and we're sure there are parts we could deprecate somehow so as to get rid of them one day. They are mostly used in XWiki, a little in JavaScript. Has there been any effort done in this direction? Would it be possible for example to flag the phrases of one page as being deprecated so that it outputs a warning if used which one would collect later? Or... would it be possible to move away already a page of phrases and load it on demand for some legacy pages? thanks for ideas paul

13 years, 2 months

[xwiki-devs] [Proposal] Better support for Google Analytics (XWIKI-6579)

by Denis Gervalle

Hi Devs, I would like to answer XWIKI-6579 properly, we had an initial patch that continue tu use the .vm we had before in the core for GA support, filling it properly and providing a configuration page (see https://github.com/dgervalle/xwiki-platform/commit/192753ce97f94baf34aa2a2a… ). Since I do not see it as good as it could be, we have rewritten this patch to use a JSX, in place of the .vm. (I know JSX is loaded defer at the top now, but since the whole GA script is asynchronous, there is no more a requirement to have it in the bottom IMHO). The JSX is activated by the configuration page. Now I am wondering how I should integrate this solution in the existing code base ? 1) location : A) in XWiki B) in GoogleAnalytics space 2) document(s): A) a single document XWiki.GoogleAnalyticsConfig (config page as content, defining a class for config, containing the config object instance, and a JSX) and using translation from the core B) two documents (or more), the same as above or splitted, with a separate XWiki.GoogleAnalyticsTranslations (for just a few string, but how could it be managed with L10N ?) C) same as A, but with translation in the place official extensions will manage their translation for being supported by i10l 3) application nature: A) in the global xar, deployed by default, without anything special B) in the global xar, but with an application definition in XApp.XWikiApplicationGoogleanalytics C) in its own xar, deployable from a xwiki maven repositiory with the new extension manager D) in its own xar, on my own maven, as a private contrib, accessible manually with the new extension manager 4) sources: A) added directly to the administration application B) in xwiki-plateform-core/xwiki-platform-googleanalytics C) in ???, the place to put xar that will be build for 3C above and officially released by the XWIki Development team D) in my own github repository (for 3D) Since the code is ready, and this is just a matter of packaging, fast answer would be nice :) Personally, I felt very annoyed by where to put the translations (to manage them with l10n), so I see only how to do a simple AAAA solution, but thought the best would be AAAC or ACCC, but really do not know how to really implement it, and I feel we are not yet ready for them. WDYT ? What should I do right now ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years, 2 months

[xwiki-devs] [Proposal][UX] Improvements for the Add menu

by Ecaterina Moraru (Valica)

Hi, This is a proposal regarding the improvement of the Add menu in order to: - specify a template for the newly created entities (space/page); - specify also applications templates; - some improvements for the create page step: the ability to select an existing space or create a non-existing one + position changes. You can see the proposal at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateMenuProposal The "Add" menu could contain just the entries: - Page - Space - Application. In the usability interviews I had, no one used the other shortcuts ('Comment to page; Attachment to page'), but the interviewers were not beginners users, so if someone from the community is using those shortcuts please tell us if you want to keep them. The Create Space step relates to http://jira.xwiki.org/jira/browse/XWIKI-6684 The Create Page step relates to http://jira.xwiki.org/jira/browse/XE-897 For the application homepage http://incubator.myxwiki.org/xwiki/bin/download/Improvements/ApplicationWit… the create action will auto-generate the page name (according to the options) and will preserve the current space [1]. With this proposal we can benefit from the contextual actions (for applicationWithinMinutes inside the designated space) but we are not dependent completely of the space, being able to create application instances in an universal manner from the "Add" menu. Also, the existing behavior for the wiki pages will be preserved. The default option for the template + location will modify accordingly to the context where the "Add" menu was launched. Please provide feedback. Thanks, Caty [1] http://xwiki.markmail.org/thread/mac6a24us4ucmp3j

13 years, 2 months

[xwiki-devs] Fwd: [ANN] Maven Release Plugin 2.2 Released

by Vincent Massol

could be good to upgrade. -Vincent Begin forwarded message: > From: Stephen Connolly <stephenc(a)apache.org> > Date: July 1, 2011 12:28:29 PM GMT+02:00 > To: announce(a)maven.apache.org, Maven Users List <users(a)maven.apache.org> > Cc: Maven Developers List <dev(a)maven.apache.org> > Subject: [ANN] Maven Release Plugin 2.2 Released > Reply-To: "Maven Developers List" <dev(a)maven.apache.org> > > The Maven team is pleased to announce the release of the Maven Release > Plugin, version 2.2 > > This plugin is used to release a project with Maven, saving a lot of > repetitive, manual work. Releasing a project is made in two steps: > prepare and perform. > > http://maven.apache.org/plugins/maven-release-plugin/ > > You should specify the version in your project's plugin configuration: > > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-release-plugin</artifactId> > <version>2.2</version> > </plugin> > > Release Notes - Maven 2.x Release Plugin - Version 2.2 > > ** Bug > * [MRELEASE-374] - Snapshot versions unusable in batch mode > * [MRELEASE-622] - Creating label fails for ClearCase with message > 'Unable to determine VOB for pathname ".".' > * [MRELEASE-661] - Exception: String index out of range: -1 > > ** Improvement > * [MRELEASE-591] - release:update-versions: add option to do a checkin > * [MRELEASE-605] - when not pushing changes to remote git repo in > 2.1, the release plugin fails on release:perform > * [MRELEASE-628] - Subversion --trust-server-cert option > * [MRELEASE-641] - upgrade to scm 1.5 (hg plugin insists on 'pushing') > > ** New Feature > * [MRELEASE-159] - Support a pattern to generate the release tag > * [MRELEASE-457] - Non sparse-checkout SCM support > * [MRELEASE-613] - Add a parameter that tells the plugin to wait > for X seconds before tagging > * [MRELEASE-621] - Add a postPrepareGoals > * [MRELEASE-648] - Putting SVN password in settings.xml doesn't > support password encryption > > Enjoy, > > -The Maven team > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe(a)maven.apache.org > For additional commands, e-mail: dev-help(a)maven.apache.org >

13 years, 2 months

[xwiki-devs] [Brainstorming] Console Module/Application for logs

by Vincent Massol

Hi devs, I'd like to start brainstorming about implementing a notion of console from within XE. The idea is that most of our current logs that go in the shell console are actually application-level logs that should be visible to wiki developers (developers of applications inside XE). I've started a design page at http://dev.xwiki.org/xwiki/bin/view/Design/ConsoleModule Here are some initial ideas: * centralized logs available from all nodes * idea: use activity stream * UI: a new console tab in pages for all logs for the page * UI: an admin page for all console logs with a livetable for filtering * nice: real time addition of new logs (comet and co) * memory cache (eg last 100 logs) + block save (anti flood protection) * long term logging with compacting * system log vs application log * Requirement: current node id * Console Module / Application with API * idea: appender for slf4j (note: could use MDC for additional data: http://www.slf4j.org/api/org/slf4j/MDC.html) WDYT? Shoot your ideas! Thanks -Vincent

13 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs July 2011