xwiki-devs September 2011

xwiki-devs@xwiki.org

23 participants
65 discussions

[xwiki-devs] [VOTE] New committer Eduard Moraru

by Thomas Mortagne

Hi committers, I would like to propose a new committer on https://github.com/xwiki/ Eduard first officially contacted the XWiki community trough GSoC in 2008 on an XEclipse (https://github.com/xwiki/xwiki-eclipse) project. After having done a great job on XEClipse he became an employee while he was doing his 1st year master studies. He is an SAS employee for almost 3 years now and worked in the Research Team developing 3 open source research projects focused on XWiki: Concerto (https://github.com/xwiki-contrib/concerto), Scribo (https://bitbucket.org/scribo/scribo) and now Wiki3.0 (https://github.com/xwiki-contrib/wiki30). He was a GSoC co-mentor in 2010 and 2011 for XEclipse and Android client projects. - Eduard is very active on the mailing list and answer efficiently - Eduard worked and will work a lot on wiki manager and XEM which really need some love - Eduard sent a lot of good pull requests theses days and I'm tired of applying them ;) Some stats: - Mails sent by Eduard (121): http://xwiki.markmail.org/search/?q=from%3AEduard%20Moraru - Eduard's github profile https://github.com/Enygma2002 - Eduard's Masterbranch profile https://www.masterbranch.com/developer/Enygma - Eduard's ohloh profile https://www.ohloh.net/accounts/Enygma I will add that it's very pleasent to work with Edy. I'm +1 to make Edy a committer. -- Thomas Mortagne

13 years, 3 months

[xwiki-devs] [Idea] Localizing from within XE

by Vincent Massol

Hi devs, Just seen this in Jenkins: https://skitch.com/e-vmassol/f3rhr/update-center-jenkins Basically each page has a "Localize this page" button at the bottom and when clicked you have a dialog box to provide translations in all languages for the strings to translate on the page. I found this nice and easy for users since: - they have the context (they can see the rendered page) when performing the translation - it's easy and quick to use (no need to leave their application) I haven't thought about it but an extension to do this in XE could be great. I don't know how we could autodiscover the strings to translate though but it's probably possible. Just an idea. -Vincent

13 years, 3 months

[xwiki-devs] [Investigation] SOLR integration

by Fabio Mancinelli

Hi everybody, for the 3.2 release cycle I said that I was going to investigate a bit the SOLR search engine and how to use/integrate it in the current platform. I wrote a document that you can find here: http://dev.xwiki.org/xwiki/bin/view/Design/SOLRIntegration about some of the things I looked at. There is a lot of room for discussion/improvement but I think the document is already a good starting point. Feedback is welcome. Thanks, Fabio

13 years, 3 months

[xwiki-devs] [PROPOSAL] Introduce a work directory concept in the Container API

by Thomas Mortagne

Hi devs, Right now there is no way for a component to know where is the standard work directory (the one used for Lucene or filesystem attachments for example) so I would like to add an API to access it. That said I propose to add a File getWorkDirectory() in org.xwiki.container.ApplicationContext which will use XWiki#getWorkDirectory() behind the scene probably for now. WDYT ? -- Thomas Mortagne

13 years, 3 months

[xwiki-devs] [Proposal] Global versioning brainstorming

by Vincent Massol

Hi devs, I'd like to brainstorm about the idea of having global versioning in XE. First here is a use case: * I have a given state in my wiki with pages in different versions * I add some pages or make modifications to existing pages * I want to go back to the previous state A good use case could be for example to return to a state before one or several applications have been installed. Proposed solution ============== * Store a global version number in the DB. Let's call it VERSION * Whenever a doc is modified, use VERSION + 1 as the new doc version * When we rollback (to say version OLDVERSION) do a query on all docs in the wiki having a version > OLDVERSION and for each of them rollback to their last version <= OLDVERSION * Write a migrator that runs the whole wiki history by looking at all versions of all docs (map in memory) and recompute the new version starting a VERSION = 1 and incrementing. * We would also need to modify the XAR importer so that importing a XAR with an older versioning scheme will work. BTW knowing that it's an old scheme is relatively easy since all old versions have a dot in their name. More notes: * This would also allow us to rollback before a given date * If we wanted we could easily add the notion of Tags later on, i.e. to associate a name with a VERSION * I've been thinking about this in the context of the new model but it's probably easier to implement it first with the old model * JRCS uses the format X.Y for versions but we could decide to only use the major, i.e always have versions of the form X.0 * In order to continue to support minor edits we would need a way to save that information. One solution is to use the minor to signify a minor edit, for ex: X.1 would mean that X is a minor. Another, probably better solution would be to store that information in the DB in the xwikircs table WDYT? Do you see any drawback of using a global versioning scheme? Do you think this is doable or too much work? Is there anything Git can tell us re managing versions that would be useful to this discussion? Thanks -Vincent

13 years, 3 months

[xwiki-devs] Usability feedback on first time usage for setting a logo

by Vincent Massol

Hi devs, I've just installed a new wiki with someone (an xwiki newbie) and realized that we have some usability issues. I'm listing just one below to start with. Usability issue #1: Color theme usage Story: * A user wants to change the logo * First he has to know it's done in the Color theme but let's imagine that this is fine… (although it's not since Color theme means changing colors, not the logo…) * He click on "customize" for the Color Theme then realizes that he wants his own color theme (for ex because he doesn't want that a future upgrade overwrites his theme) * He clicks on manager color themes * He sees the "create new color theme" and use it. However he finds that the new color theme isn't the same as the color theme he wants to use as the basis for the new color theme (btw the new color theme should be the default color theme IMO and not a different one as it is now). * Then he's stuck because the doesn't offer the possibility to copy an existing theme * Imagine that he understands that he can go a color theme page and click the copy action… * He goes there clicks copy, he finds that he wants to copy in a new space but he cannot (this is fixed in 3.2 I think so cool). He copies in the new space. * Then he edits the new color theme, finds the way to set the logo * He sees a field where he has to enter information and doesn't see how to upload his logo. Reading more carefully the text he understand that he has to cancel the edit, go to the attachment tab, upload the logo, edit again, edit the header again and there he's stuck again because he doesn't remember the name of his logo. So he has to do it all again this time copy pasting his logo name * Then he saves his modifications * .. and realizes that nothing is happening: the displayed theme is still the same as before. He hits refresh (because he's a clever guy!) and finds it doesn't help * Then someone points to him that he has to go back to the admin, click on presentation and sets the color theme to use to be his new color theme. * So he does this and finds that his new color theme doesn't appear in the list but OTOH there are 2 color themes with the same name * Then someone mentions to him that it's because he hasn't changed the title of this copied page... Ideas for improving this experience: * In the Admin>L&F>Presentation screen, next to "customize", add a new button "Create new colortheme". * In the new color theme page screen, add the possibility to copy from an existing theme *AND* that sets the new title! * In color theme edit mode, add the capability to select the logo using the widget used in the user profile to select/upload images * When saving the new color theme, go back automatically to the admin page from where the user clicked on "create new colortheme" and set the newly created theme as the selected them * The user press save and he's done WDYT? In addition to all this we should probably rename Color Theme into something else to make it more clear that it's not just about colors (or move the logo out). Also it's probably not very clear what's the difference between color themes and skins. Note: I really did all those steps mentioned above in the story and it was a real pain from a newbie user POV. Thanks -Vincent

13 years, 3 months

Re: [xwiki-devs] 5

by dennis.coonich＠comcast.net

Visit this site. I hope it will help you to rid of shyness.. http://www.endrik.com/com.page.php?jfuGIS=50up9

13 years, 3 months

[xwiki-devs] (no subject)

by dennis.coonich＠comcast.net

Life is not boring!!!. http://www.kempsu-huolto.fi/com.page.php?iaolid=25o0

13 years, 3 months

[xwiki-devs] Blockers for XE 3.2M3 and XE 3.2 release?

by Vincent Massol

Hi devs, Can we list blocker issues in this thread? I can think of the following: - http://jira.xwiki.org/jira/browse/XWIKI-6925: ActivityStream nolonger works if upgrading a legacy system. - http://jira.xwiki.org/jira/browse/XRENDERING-46: Upgrade to HTML Cleaner 2.2 This one is a blocker because we want to put XE 3.2M3 and XE 3.2 final on Maven Central for Commons and Rendering and we're using HTML Cleaner 2.1 which isn't located on Central but version 2.2 is. An alternative is to push version 2.1 of HTML Cleaner on Central. - http://jira.xwiki.org/jira/browse/XWIKI-6939: Can't find any core extension when executed in a folder with white space - upgrade myxwiki to XE 3.3M3 There are also 47 issues marked "Critical" in JIRA… We need to review them and verify if they're really critical. Please add more if you know blocker issues. Also, we need volunteers to work on them! Thanks -Vincent

13 years, 3 months

Re: [xwiki-devs] 8

by dennis.coonich＠comcast.net

Cool! I want you to visit this site too!. http://mpbarnehage.no/com.page.php?jcaolid=60w4

13 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2011