October 2014 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] Simplified Home Page
by vincent＠massol.net 24 Oct '14

24 Oct '14

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

9 26

[xwiki-devs] [XWiki Day] BFD#66
by Eduard Moraru 22 Oct '14

22 Oct '14

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

1 2

[xwiki-devs] Naming convention for webjar modules
by Marius Dumitru Florea 21 Oct '14

21 Oct '14

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

2 1

[xwiki-devs] [Brainstorming] Improving the Top level Menu/Breadcrumb/Navigation
by vincent＠massol.net 21 Oct '14

21 Oct '14

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

9 19

[xwiki-devs] [Proposal] A new javascript service to get XWiki metadata
by Guillaume "Louis-Marie" Delhumeau 21 Oct '14

21 Oct '14

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

5 9

[xwiki-devs] [myxwiki] XWiki Enterprise 6.2.2 Upgrade
by Thomas Mortagne 21 Oct '14

21 Oct '14

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

1 0

[xwiki-devs] Which skin for xwiki.org now?
by vincent＠massol.net 20 Oct '14

20 Oct '14

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

6 5

Re: [xwiki-devs] [VOTE] New Link and Image syntax for XWiki Syntax 2.2
by Ecaterina Moraru (Valica) 20 Oct '14

20 Oct '14

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 >

1 0

Re: [xwiki-devs] [VOTE] New Link and Image syntax for XWiki Syntax 2.2
by vincent＠massol.net 20 Oct '14

20 Oct '14

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 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]] 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@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) > > 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 > >

4 6

[xwiki-devs] About using bootstrap/flamingo for customizations in XWiki
by Anca Luca 17 Oct '14

17 Oct '14

Hello guys, I have tried to learn a bit of bootstrap last night to figure out how to do things, and I did the following test page to test the grid system: http://incubator.myxwiki.org/xwiki/bin/view/Sandbox/TestFlamingo?skin=flami… I have a few questions related to using the grid system (I didn't yet get to other parts of bootstrap/flamingo): The questions will get fuzzy-er and fuzzy-er as they advance. Please bare with me, I have a lot of questions and little knowledge about bootstrap, I am trying to figure out how should it be used in general (it's supposed to be simple but I don't feel like it) and if there are some special rules of usage in XWiki. 1/ What would be the proper structure if we wanted to make a grid layout in a wiki page ? My experiments show that the first example, div class=row and then columns inside will not work (example "doesn't fit properly"). The second example works, but that means we need to add .container-fluid all around that. Let's assume for the next questions that we're using the .container-fluid structure. 2/ On the bootstrap website here http://getbootstrap.com/css/#overview-container I found that "neither container is nestable" . I don't really know how to understand this phrase, especially in the context of needing to put it in the content of my page in order to make a grid. Is it dangerous to put it? Could it end up being nested and thus not good? 3/ On the bootstrap website here http://getbootstrap.com/css/#grid I found that any row must be in a container (which matches my usage). But I am looking at the .document-header which contains the title and the edit buttons, and it is not in a container. Or is it? If that one is in a container, does that mean that we have a "global" container in the page in XWiki which would also surround the page content (#xwikicontent) and then if I put another .container-fluid in the document content in order to make the grid I would be nesting containers? 4/ I didn't fully understand this story about the negative margins that compensate for padding in order for columns to align with non-grid content... ( 5th and 6th bullets in here http://getbootstrap.com/css/#grid ). I did some examples in my test page in section "Fits properly", and I would like to understand better this principle / approach. What would be the correct way to mix & match full width elements and grid in the document content? (by full width I mean either a paragraph with text, or other elements that need to take up the whole width of the document content area #xwikicontent). a) anything that has to be full-width should be out of a .container-fluid and whenever I want columns I make a new .container-fluid? -- the text "this is the " in section Fits Properly b) can I put stuff in a container fluid? If I do, then why is it indented? The text "dancing" in section Fits Properly c) I read in BS documentation that only columns should be direct children of .row so the text "text" in section Fits Properly is not an option (although correctly displayed). Please confirm d) I added a third column, with size 12 at the end, to get something full width. I guess this is one approach, but then its text is not aligned with the left of the column, but, because it is a column itself, it has a padding of 10px. So the texts are aligned (text in half column with text in full width but the full width text is not aligned with the border of the half column). Is it a bad practice to put borders directly on the bootstraps column? Should I be putting border on an element that I have put inside the bootstrap column? In this case, I would get a lot of space between the left side of the screen and my text. Maybe some of that space gets colored in a different color theme? e) should I be matching and mixing full-width stuff and grid stuff at all? Is this a good idea? or if I need a part of the content in a grid then I just make all content a grid and make col-12 for all the stuff that needs to be full-width? 5/ Also, I just noticed now that the content of a page is not (in) a column ( #xwikicontent ). I was thinking that it could be a 12 size column which we could split further by using this strategy: http://getbootstrap.com/css/#grid-nesting . Since the document-header is a row with columns, I was thinking that the lower part of the page could be as well... This way, aligning stuff inside could be more natural (see subquestion 4 d before). Thank you a lot for your patience, I do take RTFMs as I am sure there are parts of the internet that could enlight me on the topic. What I would like to know is how did we plan to use bootstrap grid in the context of XWiki for custom stuff, if there are some special rules... Anca

2 4