xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

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

by vincent＠massol.net

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 > >

10 years, 2 months

[xwiki-devs] About using bootstrap/flamingo for customizations in XWiki

by Anca Luca

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

10 years, 2 months

[xwiki-devs] [Discussion] Where does livetable belong?

by Eduard Moraru

Hi devs, While looking into the delete space UI issue [1], we first thought about directly using the livetable macro to list the documents to be deleted from the space. Now the problem, as state by Vincent: Can/should we use the livetable inside templates? Is the livetable part of xwiki-platform-web or is a removable extension (xwiki-platform-livetable)? Currently, xwiki-platform-livetable only contains the 2 pages that generate the JSON for the livetable, but the html markup is generated by the #livetable macro (macros.vm) and the livetable.css and livetable.js files are all in xwiki-platform-web. The only case of it being used in templates right now is in rightsUI.vm [2] where the macro is not directly called, but the html markup is created by hand and the javascript and css is included. IMO, we should decide on a single approach for the livetable and use it all the way. What we do currently can be confusing even for us. I currently see two directions: 1) Move the content of xwiki-platform-livetable in a xwiki-platform-web as templates so that the livetable is a core feature and that it also works in the UI when the database is empty. 2) Move the livetable macro (as wiki macro?), js (as JSX) and css (as SSX) from xwiki-platform-web to xwiki-platform-livetable and see the livetable as just another extension/feature that is only present when installed. The rightsUI would need a change as well, since it can no longer rely on the livetable and probbaly we would also need to find a way to allow extenions to contribute filesystem resources. I thought it would be a good idea to open a discussion on this topic since it's currently, AFAIK, a grey area. WDYT? Thanks, Eduard ---------- [1] http://jira.xwiki.org/browse/XWIKI-8320 [2] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…

10 years, 2 months

[xwiki-devs] [ANN] XWiki 6.3 Milestone 1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 6.3 Milestone 1. This milestone is mostly about improvements but it also introduce new Velocity tools and macros and also add support for catching and display nicely exceptions in Velocity. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki63M1 Thanks -The XWiki dev team

10 years, 2 months

[xwiki-devs] [Proposal] New strategy for finding the next Release Manager

by vincent＠massol.net

Hi devs, It’s been a pain to find the next Release Manager lately so I discussed with other committers and here’s what we would like to propose: Proposal ======== * We have a list of declared Release Managers. This list would start with the following persons: - enygma - evalica - gdelhumeau - mflorea - tmortagne - vmassol If any other existing committers are willing to help the project and become a Release Manager please reply to this thread! That would help the project for sure :) Actually when new committers are added to the project we should ask them if they’d be willing to do releases. * If at any point a committer not in the Release Manager list would like to do a release, he’s more than welcome to do it! * We take turns, following the initial order. When a newcomer is added he's inserted at the bottom of the list. * If a committer cannot do the release for a reason or another (sick, holiday, workload, etc) he’s still responsible for the release and he/she needs to find a replacement. He also has the option to propose changing the release date but that needs to be accepted by the project. If he/she finds a replacement, it’s up to them to decide together who will do the release the next time that replacement’s time comes. * All releases are included (milestones, RCs, final, bugfix releases). * We switch RM at each release (be it a milestone, RC, final or bugfix release). * We put the RM list, order and upcoming releases on http://dev.xwiki.org/xwiki/bin/view/Community/ReleaseManagerRoster Bootstrapping ============= * We have 3 releases to do with some volunteers already: - 13th of Oct: 5.3M1 - Not defined - 15th of Oct: 6.2.2 - Vincent - 5.4.6 (no date defined AFAIK but ASAP) - Guillaume * Thus I propose to start with the following: - vmassol - 6.2.2 - gdelhumeau - 5.4.6 - tmortagne - 6.3M1 - enygma - following release (not known yet - 6.3M2, 6.2.3 or 5.4.7) - evalica - following release (not known yet) - mflorea - following release (not known yet) - vmassol - following release (not known yet) - ... I propose that we try this and fine-tune as we progress. Let me know if you agree or disagree. Thanks -Vincent PS: This is not a vote since I feel that only the person in the list should have a say on this since they’re the one who are going to do the hard work for the moment so it would be bad form for other committers to vote on this if they don’t participate ;) They can still voice their opinion of course...

10 years, 2 months

[xwiki-devs] My tiny noticed about the top menu (merging buttons again)...

by Pascal BASTIEN

Hello, At my opinion, It's a pity to come back at 2 click to access at space/page because buttons are no longer split into two parts.... User must click twice to access at space (it is probably the most used case) for this button. But the the most annoying is: javascript with this merging buttons. An current example: I click on Space button and Go to space but during the loading I made a mistake and I would quickly access to page (or wiki) before the javascript loading: it is impossible because I must waiting some seconds to click Backspace, waiting again and then click on Page - Go to page. On 6.2.1 there are not this problem: I could click on Space/Page button before JS loading. Of course, with top menu CSS we would no have this problem but bootstrap required JS, then for my case, the quick issue is to modify template to come back at top menu splitting. :-) Pascal BASTIEN

10 years, 2 months

Re: [xwiki-devs] My tiny noticed about the top menu (merging buttons again)...

by vincent＠massol.net

Hi, On 16 Oct 2014 at 17:18:29, Pascal BASTIEN (pbasnews-xwiki@yahoo.fr(mailto:pbasnews-xwiki@yahoo.fr)) wrote: > Hello, > > At my opinion, It's a pity to come back at 2 click to access at space/page because buttons are no longer split into two parts.... > User must click twice to access at space (it is probably the most used case) for this button. Some points related to this topic: * You can also access it through the breadcrumb with one click. That may even be more logical because in the majority of cases you want to navigate to the parent of the current page and not necessarily to the space home page. * For general navigation, I believe what we need is a good Navigation panel and Marius is working on that at this moment. Thanks -Vincent > But the the most annoying is: javascript with this merging buttons. > An current example: I click on Space button and Go to space but during the loading I made a mistake and I would quickly access to page (or wiki) before the javascript loading: it is impossible because I must waiting some seconds to click Backspace, waiting again and then click on Page - Go to page. > > On 6.2.1 there are not this problem: I could click on Space/Page button before JS loading. > > Of course, with top menu CSS we would no have this problem but bootstrap required JS, then for my case, the quick issue is to modify template to come back at top menu splitting. :-) > > > Pascal BASTIEN

10 years, 2 months

[xwiki-devs] [ANN] XWiki 5.4.6 released

by Guillaume "Louis-Marie" Delhumeau

The XWiki development team is proud to announce the availability of XWiki 5.4.6. This release is a stabilization version that fix important bugs discovered in the 5.4.5 version. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki546 Thanks -The XWiki dev team

10 years, 2 months

[xwiki-devs] [Proposal] XWiki 6.2.3

by vincent＠massol.net

Hi devs, We’ve just released 6.2.2 and we had 51 issues fixed (in 2 weeks). What this means is that we haven’t stabilized 6.2.x yet… Thus I’m proposing to plan ahead a 6.2.3 release. I propose to release 6.2.3 in 2 weeks time, i.e. for the 29th of October (Note: it’s about the same time as the 6.3M2 release). If there are not enough issues in it, we can always decide to cancel it but, unfortunately, I doubt that... What this also means is that we should continue backporting important bugs on the stable-6.2.x branch. We now have a strategy for finding RMs but I’m also ok to perform this release myself if need be. WDYT? Thanks -Vincent

10 years, 2 months

[xwiki-devs] [ANN] XWiki 6.2.2 released

by vincent＠massol.net

The XWiki development team is proud to announce the availability of XWiki 6.2.2. This is a bug fix release with lots of issues fixed to stabilize the recent Flamingo skin. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki622 Thanks -The XWiki dev team

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