xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Proposal] A tool to customize what applications are displayed on the app bar

by Guillaume "Louis-Marie" Delhumeau

Hello. I have worked a bit on http://jira.xwiki.org/browse/XWIKI-10333 <http://jira.xwiki.org/browse/XWIKI-10844>, to be able to remove some applications from the left bar. I wanted to propose it before 6.3M2 is released, so I have made a prototype (without doing a proper proposal) which is working quite well. You can see a screenshot there: http://jira.xwiki.org/secure/attachment/29296/customizable-app-bar.png The principle is very simple: on the left, you have the applications that you want to have in the app bar. On the left, the others (stored in a blacklist actually). You just need to drag&drop the icon from the left to the right, or from the right to the left, to change your settings. Then you click on "save" and voila. It is written with jQuery and jQuery-ui (loaded via a webjar). If you like it, I can commit it on master. FYI, you can already see the code there: https://github.com/gdelhumeau/xwiki-platform/compare/panels Here is my +1 to put it on master. WDYT? Thanks -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

10 years, 2 months

[xwiki-devs] can jsfx get cleared?

by Paul Libbrecht

Hello fellow XWikiers, we have a situation where some code must be clearing jsfx somehow. The code that adds to jsfx is there and changing it does output some text. A common code in other pages works flawlessly but does not in a family of pages (Group_*/Discussions) we have. What code can I look for that would be guilty of clearing the jsfx additions? thanks in advance. Paul

10 years, 2 months

[xwiki-devs] [Proposal] Simplified Home Page

by vincent＠massol.net

Hi devs, As you know I started working on a Home Page Application, see: - JIRA with screenshots: http://jira.xwiki.org/browse/XWIKI-10586 - Discussion thread: http://markmail.org/message/ghelufamwucog46x I have it all done locally but I refrained from committing it because on the email thread some expressed their doubts. I started thinking about it and I expressed some idea in the thread started by Caty about "Wiki - Space - Page concepts pitch": http://markmail.org/message/jefze7nvprz36pkw I’m pasting it here again for discussion (with some edits): " BTW concerning the home page, I’m more and more leaning towards removing the dashboard from it (it’s accessible from the App panel anyway) and instead have it contain: - explanation about how the wiki is organized (wikis, spaces, pages) - explanation about base concepts (editing, saving, etc) - encourage the user to edit this home page to make it his own and put the content he wishes instead I think this would solve the following issues: - users always want to customize the home page and this makes it easy (it’s a standard page, no dashboard). This is also a way for them to take ownership of the wiki as theirs. - explains the main concepts of wiki, space, page Of course, we also need to provide a navigation panel for easy navigation in the wiki/spaces/pages. “ If we agree about the idea of removing the dashboard and instead have a simple page then we’ll need to discuss the exact content and for that I’m proposing to discuss with Caty/GuillaumeD and make a proposal for further discussion. Of course any idea in reply to this email would also be much appreciated. But first things first! We first need to decide if this is a good idea or not. WDYT? Thanks -Vincent

10 years, 2 months

[xwiki-devs] [XWiki Day] BFD#66

by Eduard Moraru

Hi devs, As announced last week, today is BFD#66: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period tells us we are at 104 bugs behind. See: http://jira.xwiki .org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-Resolved-Chart/10470 Here's the BFD#66 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12694 Thanks and happy bug fixing! -Eduard

10 years, 2 months

[xwiki-devs] Naming convention for webjar modules

by Marius Dumitru Florea

Hi devs, I recently added two modules (on a branch, see https://github.com/xwiki/xwiki-platform/commit/de32b71e315def995b5f21b70339… ) that generate webjars and I'm not sure whether the names I've used are good enough: xwiki-platform-job-web xwiki-platform-tree-widget Thomas made me realize that -web suffix is confusing because we use it for modules that generate a WAR. I didn't use -widget for the first because it's not a widget (unlike the tree) but some JavaScript API. An alternative I had in mind and which was also suggested by Thomas is -webjar but we normally don't put the packaging type as suffix. We have -ui and not -xar for instance. So WDYT? (1) Is -webjar a good suffix for modules that generate a webjar? (2) If yes, then should it be used for all webjar modules? I.e. rename -widget to -webjar I'd say yes for both. Thanks, Marius

10 years, 2 months

[xwiki-devs] [Brainstorming] Improving the Top level Menu/Breadcrumb/Navigation

by vincent＠massol.net

Hi devs, I’ve had a few persons tell me that they don’t like the small arrow in the top level menu in Flamingo. It seems they either don’t understand the little triangles and what it’s about (submenu?) or they click on the menu itself and go to another page when they were expecting some menu to drop down, or... In addition we’re still missing a solution to easily navigate the wiki from any page (there’s the ctrl+G solution but this is more like a shortcut to know and we need something more). So here are some ideas: * For the top level menu, make it simpler by having the drop down display when you click anywhere in the menu (the whole width of it) and only navigate when you double click (there are actually few reasons to need to navigate with the other idea below so we could also not do the double click thing) * In the breadcrumb OR in the top level menu OR in both (to be decided) use something like this (screenshot taken from IntelliJ IDEA): https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944… This means when you click at a given level you get to see all sibling elements in the wiki for element you’re currently on (document, space, wiki). For example clicking on the “Home” wiki would show: - A filter box allowing you to type and it would auto suggest as you type, completing with wiki names - An icon would be displayed on the left (or on the right) of the filter box and if you click on it you’ll go the index page (Wiki Index in this case) - A list of the first 10 wikis (an improvement would be to list first the wiki that you’ve last navigated to) Same would apply for spaces and pages. We could even imagine that when you’re on a user profile page, clicking on it would display other user pages and the filter would filter on user pages. Actually we could imagine to when the current page has XObjects in it, it would be possible to list all other pages in the wiki having the same XClass. And if there are several XObjects, then somehow in the UI allow selecting which one to consider as the filter criteria. * Note 1: The breadcrumb is currently not displayed on all pages (it’s not on the home page for example) and thus if we implement this idea in the breadcrumb only then there’s no solution for navigating on the home page. * Note 2: If we were to implement this idea on the top level menu, then we still need to display the actions too. Several options: - a) Display the actions first and the navigation list after separated by a ----- - b) Have a first entry in the drop down that says “Actions...” and when you move the mouse over it a secondary menu with all actions are displayed. Note that the alternative is possible too: Display the actions and have a “Go to..." menu entry. We would just need to choose to display what we think is the most used default (actions or navigation) WDYT? Personally I would do this: - implement this idea for the breadcrumb - add “Go to wiki...”, “Go to space...", “Go to page..." menu entries in the Wiki/Space/Page top level menus - expand the menu selection to the whole width for displaying the drop down (and not just above the small arrow) - either support double-click or simply add the possibility to navigate to that element in the “Go to xxx...” submenu Thanks -Vincent

10 years, 2 months

[xwiki-devs] [Proposal] A new javascript service to get XWiki metadata

by Guillaume "Louis-Marie" Delhumeau

Hello. Some months ago, I created a topic about switching to HTML5 [1]. One of my concerns was that we currently use custom meta tags to store XWiki metadata, such as the current space, the current page, etc... [2]. These meta tags are not allowed anymore in HTML5 so we need to remove them. In this topic, you suggested some good ideas and I am making this proposal to recap them. 1/ Remove the invalid meta tags from the HTML, so it will pass our HTML validation tools. 2/ Put them back, dynamically, with JavaScript, on the client-side, to ensure retro-compatibility (and before any other script is started), because some extensions can rely on them. Also, they will be deprecated. 3/ Store the meta-data that we need in the <html> tag, via the data-* property that HTML5 allows. The prefix "xwiki" should be used to not collide with other extensions. For example: <html data-xwiki-space="the-current-space" data-xwiki-form-token="the-token" ...> 4/ Create a JS service that looks for this information and return them to other script. So if you change again the way we store the metadata, it won't break the extensions. This service should also be loaded before other scripts, and should be available to all scripts (which use jQuery, Prototype, or something else). For example: XWiki.getMetadata('space') (without the prefix) XWiki.getMetadata('form-token') Or it could be: XWiki.getSpace() XWiki.getFormToken() Actually I don't know how will be the implementation details yet, but I just would like to have your agreement on the principle. WDYT? Thanks, [1] http://markmail.org/message/4yhdlcxswbqdg3wv ([Proposal] Use HTML5 in Flamingo) [2] https://github.com/xwiki/xwiki-platform/blob/22ae6ec5b0ab3125486a0f55ab76ce… (XWiki metadata) -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

10 years, 2 months

[xwiki-devs] [myxwiki] XWiki Enterprise 6.2.2 Upgrade

by Thomas Mortagne

Hi everyone, myxwiki.org has been upgraded to XE 6.2.2. If you own a wiki hosted there you should have a look at the release notes for this version at: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ You should automatically get an upgrade wizard for your wiki when you login as admin. For more details see the upgrade guide available at : http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Upgrade#HUpgradingwikid… To be notified of the myxwiki.org server upgrade you can follow myxwiki on twitter: http://twitter.com/myxwiki Thanks, -XWiki Community

10 years, 2 months

[xwiki-devs] Which skin for xwiki.org now?

by vincent＠massol.net

Hi, When XWiki 6.2.2 is released, I’d like to upgrade xwiki.org to it. Since we now have the new flamingo skin we’ll need to decide if we want to use it or keep using Junco. Personally I think I’d prefer to start using Flamingo with a custom xwiki.org Color Theme (allows us to test Flamingo more and not have to support Junco). WDYT? Thanks -Vincent

10 years, 2 months

Re: [xwiki-devs] [VOTE] New Link and Image syntax for XWiki Syntax 2.2

by Ecaterina Moraru (Valica)

Forwarding mail since somehow we lost the mailinglist recipient ---------- Forwarded message ---------- From: vincent(a)massol.net <vincent(a)massol.net> Date: Mon, Oct 20, 2014 at 2:26 PM Subject: Re: [xwiki-devs] [VOTE] New Link and Image syntax for XWiki Syntax 2.2 To: "Ecaterina Moraru (Valica)" <valicac(a)gmail.com> On 20 Oct 2014 at 11:54:26, Ecaterina Moraru (Valica) (valicac(a)gmail.com (mailto:valicac@gmail.com)) wrote: > > Anyway, I think is less needed to want to have a custom label when you are referring an user. I wouldn't want to be forced to duplicate the user's name, but instead just use his username and the display would fill all the data (last name, first name, maybe avatar). Labels are always optional so no worries here... > Can we have something like: [[~user='evalica']]? This is not going to work as "~" is our escape character ;) > or [[user:xwiki:XWiki.evalica]] even better would be [[user:incubator:evalica]] (to cover the local users). This is what's already in all proposals since all the proposal are of the form "user<separator><reference to the user>". > Maybe [[@user=evalica]] This would be Solution 14: * [[label>>wiki:space.page]] * [[label>>@doc=wiki:space.page]] * [[label>>@path=/some/path]] * [[label>>http://xwiki.org]] * [[label>>@url=http://xwiki.org]] * [[label>>@user=evalica]] * [[image:wiki:space.page@image.png]] * [[image:@doc=wiki:space.page@image.png]] * [[image:@icon=someicon.png]] So we would recognize a Resource Type by the fact that it's enclosed between "@" on the left and "=" on the right. > or [[@evalica]]. Could be possible, it would mean: - delegate the parsing of the full link reference to each Resource Type Parser so that they have a new method to decide if they can handle the reference or not. If not, then it goes to the next Resource Type parser. Ideally we would need to define an order too. - no doc starting with '@' or should be escaped with '~@' - the other Resource Types cannot start with "@" - important performance hit since each full link reference would need to be passed to all Resource Type parsers (and each one would reparse it) before fallbacking to a doc reference or a URL. > I hope I don't digress to much, my intention is to give you ideas :) Thanks -Vincent > > Thanks, > Caty > > > On Mon, Oct 20, 2014 at 12:30 PM, vincent(a)massol.net(mailto: vincent(a)massol.net) wrote: > > > > > > > > > > On 20 Oct 2014 at 11:27:03, Ecaterina Moraru (Valica) (valicac(a)gmail.com (mailto:valicac@gmail.com)(mailto:valicac@gmail.com)) wrote: > > > > > On Fri, Oct 17, 2014 at 6:36 PM, vincent(a)massol.net(mailto: vincent(a)massol.net) > > > wrote: > > > > > > > I’ve read again both threads. Not an easy decision... > > > > > > > > Some thoughts: > > > > > > > > * I don't like any of the proposed solutions so far because they all make > > > > it harder to create links than what user already do in XWiki Syntax 2.0 or > > > > 2.1 > > > > * Solution 2 (forcing using the "doc" prefix when creating links to > > > > subwikis) is the solution that gathered the most votes. However when I > > > > think about solution 2 I think about xwiki.org(http://xwiki.org) and all the links I create > > > > every week from one wiki to another and I can't refrain from thinking that > > > > it's going to make more complex to create them. > > > > * I can understand why some didn't like my proposal to have a shortcut > > > > syntax for links and a canonical one for typed references. Basically it's > > > > too complex for users. > > > > > > > > In order to be complete, there's another possibility which is to change > > > > the delimiter for wikis or for reference types. Obviously it wouldn't be > > > > possible to change the delimiter for wikis (i.e. the ":" in > > > > "wiki:space.page") so remains the option to change the delimiter for > > > > reference types. > > > > > > > > Here are some ideas for exploring this direction: > > > > > > > > Solution 10 > > > > =========== > > > > > > > > * [[label>>wiki:space.page]] > > > > * [[label>>doc::wiki:space.page]] > > > > * [[label>>path::/some/path]] > > > > * [[label>>http://xwiki.org]] > > > > * [[label>>url::http://xwiki.org]] > > > > * [[label>>user::evalica]] > > > > * [[image:wiki:space.page@image.png]] > > > > * [[image:doc::wiki:space.page@image.png]] > > > > * [[image:icon::someicon.png]] > > > > > > > > PROs: > > > > * Syntax remains the shorter possible for links to docs and URLs > > > > * Adding a new reference type doesn't break existing links/images > > > > > > > > CONs: > > > > * When using typed links/images, it's bit longer to type ("::" instead of > > > > ":") > > > > * Small change of syntax for users but the majority of users use the > > > > shorthand notation > > > > * Still a URI! (even if a weird one) > > > > * Force to escape the ":" (with "~:") for spaces or documents starting > > > > with ":" > > > > > > > > Solution 11 > > > > =========== > > > > > > > > Using URL-like notation: > > > > > > > > * [[label>>wiki:space.page]] > > > > * [[label>>doc://wiki:space.page]] > > > > * [[label>>path:///some/path]] > > > > * [[label>>http://xwiki.org]] > > > > * [[label>>https://xwiki.org]] > > > > * [[label>>url://http://xwiki.org]] > > > > * [[label>>user://evalica]] > > > > * [[image:wiki:space.page@image.png]] > > > > * [[image:doc://wiki:space.page@image.png]] > > > > * [[image:icon://someicon.png]] > > > > > > > > Compared to solution 10: > > > > > > > > PROs: > > > > * Uses a notation closer to a URL (could be a CONs too!) > > > > > > > > CONs: > > > > * One more character to type "://" vs "::" > > > > * A bit strange when linking to URLs using the typed syntax ("url:// > > > > http://xwiki.org") > > > > * Need to use the typed syntax for URLs other than "http" and "https" > > > > (e.g. for specific URL schemes, like "ftp": "url://ftp://192.168.0.1 ") > > > > > > > > Solution 12 > > > > =========== > > > > > > > > Then there are other possible notations such as: > > > > > > > > * [[label>>wiki:space.page]] > > > > * [[label>>doc#wiki:space.page]] > > > > * [[label>>path#/some/path]] > > > > * [[label>>http://xwiki.org]] > > > > * [[label>>url#http://xwiki.org]] > > > > * [[label>>user#evalica]] > > > > * [[image:wiki:space.page@image.png]] > > > > * [[image:doc#wiki:space.page@image.png]] > > > > * [[image:icon#someicon.png]] > > > > > > > > Solution 13 > > > > =========== > > > > > > > > Or: > > > > > > > > * [[label>>wiki:space.page]] > > > > * [[label>>doc=wiki:space.page]] > > > > * [[label>>path=/some/path]] > > > > * [[label>>http://xwiki.org]] > > > > * [[label>>url=http://xwiki.org]] > > > > * [[label>>user=evalica]] > > > > * [[image:wiki:space.page@image.png]] > > > > * [[image:doc=wiki:space.page@image.png]] > > > > * [[image:icon=someicon.png]] > > > > > > > > > > I like this solution the most. It looks like a parameter. > > > > Yes this is why I suggested it. It looks "natural". However this is also why I don't like that much, it's too magical, because it's not a parameter and thus it's misleading! It's a reference... > > > > > Can I put > > > something (single quotes, double quotes) like [[label>>user='evalica']]? > > > > No, you cannot, it's a refefence… > > > > Thanks > > -Vincent > > > > > > > > Thanks, > > > Caty > > > > > > > > > > > > > > > > > Personally I'm still hesitating but seen that the majority of use cases > > > > are for links to documents, I think I'd like a solution that doesn't change > > > > the shorthand syntax for linking to documents. > > > > > > > > So I'm still ok with Solution A (i.e. don't do anything) and baring that, > > > > solution 10 also seems acceptable to me, seen that we don't use the typed > > > > syntax that often so simple users won't see their habits changed. > > > > > > > > WDYT? > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > > > > On 30 Apr 2013 at 11:02:46, Vincent Massol (vincent(a)massol.net (mailto:vincent@massol.net)(mailto: > > > > vincent@massol.net(mailto:vincent@massol.net))) wrote: > > > > > > > > > Hi devs, > > > > > > > > > > Following this thread http://markmail.org/thread/vw3derowozijqalr it > > > > seems clear that we need to introduce a better syntax for links and images > > > > in XWiki Syntax 2.2 (in order to cope with use cases such as > > > > http://jira.xwiki.org/jira/browse/XRENDERING-290). > > > > > > > > > > The need is to be able to plug new reference type handlers without > > > > breaking backward compatibility in XWiki Syntax 2.2 (since right now with > > > > XWiki Syntax 2.0 and 2.1 adding a new type reference handler would break > > > > backward compatibility). > > > > > > > > > > So here are various proposals to that effect for XWiki Syntax 2.2 (I've > > > > only kept the interesting proposals from the previous thread). Please vote > > > > for the one you prefer or add new solutions if you have other better ideas. > > > > > > > > > > Proposal 1 > > > > > ========= > > > > > > > > > > Force XWiki Syntax 2.2 to *ALWAYS* use the full form when creating a > > > > link or image, i.e. all links would need to be written: > > > > [[label>>type:reference]] > > > > > > > > > > Examples: > > > > > * [[label>>doc:space.page]] > > > > > * [[label>>doc:wiki:space.page]] > > > > > * [[label>>path:/some/path]] > > > > > * [[label>>url:http://xwiki.org]] > > > > > * [[label>>user:evalica]] > > > > > * [[image:doc:wiki:space.page@image.png]] > > > > > * [[image:icon:someicon.png]] > > > > > > > > > > CONS: > > > > > * Harder to write links to documents which is the main use case > > > > > > > > > > Proposal 2 > > > > > ========= > > > > > > > > > > Same as with XWiki Syntax 2.1 but for links or images to subwikis force > > > > the user to use the "doc:" notation > > > > > > > > > > Examples: > > > > > * [[label>>space.page]] or [[label>>doc:space.page]] > > > > > * [[label>>doc:wiki:space.page]] > > > > > * [[label>>>path:/some/path]] > > > > > * [[label>>http://xwiki.org]] or [[label>>>url:http://xwiki.org]] > > > > > * [[label>>user:evalica]] > > > > > * [[image:doc:wiki:space.page@image.png]] > > > > > * [[image:icon:someicon.png]] > > > > > > > > > > PRO: > > > > > * Still easy to reference docs and images in the current wiki > > > > > * Close to current XWiki Syntax 2.1 > > > > > > > > > > CONS: > > > > > * Harder to write links to documents in subwikis (for workspaces users > > > > for example, see example of xwiki.org(http://xwiki.org)) > > > > > > > > > > Proposal 3 > > > > > ========= > > > > > > > > > > Always define the type as a link or image parameter, i.e. separate > > > > subwiki notation from type. > > > > > > > > > > Examples: > > > > > * [[label>>space.page]] or [[label>>space.page||type="doc"]] > > > > > * [[label>>wiki:space.page]] or [[label>>wiki:space.page||type="doc"]] > > > > > * [[label>>>/some/path||type="path"]] > > > > > * [[label>>http://xwiki.org]] or [[label>>>http://xwiki.org > > > > ||type="url"]] > > > > > * [[label>>evalica||type="user"]] > > > > > * [[image:wiki:space.page@image.png]] or > > > > [[image:wiki:space.page@image.png||type="doc"]] > > > > > * [[image:someicon.png||type="icon"]] > > > > > > > > > > PRO: > > > > > * Still easy to reference docs > > > > > * Clear separation between subwiki and types > > > > > > > > > > CONS: > > > > > * Harder to write typed links > > > > > * Harder to write references in non xwiki/2.x syntax that would not > > > > support link parameters > > > > > > > > > > Thanks > > > > > -Vincent > > > > > > > > > > > > > > _______________________________________________ > > > > devs mailing list > > > > devs@xwiki.org(mailto:devs@xwiki.org) > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > _______________________________________________ > > > devs mailing list > > > devs@xwiki.org(mailto:devs@xwiki.org) > > > http://lists.xwiki.org/mailman/listinfo/devs >

10 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs