June 2015 - xwiki-devs@xwiki.org

[xwiki-devs] [Feedback Request] New 'script' right
by Eduard Moraru 23 Jun '15

23 Jun '15

Hi, For 7.2, we are introducing a new right to control permissions on the execution of scripts. Right now, out of all the scripts we support, Velocity is special and does not require programming rights, since it uses only the public API. Of course, if it has PR available, it can also access privileged API. All other scripts (groovy, python, etc) require PR by default. The new 'script' right should be used to control "light"/sandboxed scripting, such as velocity or any other scripts that are configured to consider this new right when executing (assuming they override the standard PR check). Since the build is not in top shape due to the nested spaces changes, I have currently committed my work on this in a branch, created a PR and would like to profit from this occasion to ask the devs that are more familiar with the rights system for some feedback on it. The Jira issue is http://jira.xwiki.org/browse/XWIKI-12171 The PR is https://github.com/xwiki/xwiki-platform/pull/410 Thanks, Eduard

2 6

[xwiki-devs] [Proposal] Next week, remove DocumentReference constructor accepting a single space (aka breaking the build!)
by vincent＠massol.net 22 Jun '15

22 Jun '15

Hi devs, Following http://markmail.org/message/sfqing2nnvk2lhqg I’d like to propose that starting on the 29 we do the following: * Move the DocumentReference constructors and Script Services accepting a single space to legacy (using Aspects) * Update RN for 7.2M1 to indicate that extensions depending on 7.2M1+ need to either update their code or depend on the legacy modules * All work together to fix the build which will be broken to fix the 1500 occurrences or so (a lot of them are tests) * At the same time update the tests to always test using more than 1 space since testing for 2 spaces will make sure the code supports nested spaces (this is not true when testing with a single space). * Whenever it’s too difficult to fix the code right away to support NS, pass a single space (but using the "List<String> spaces” constructor signature) BUT create a JIRA issue to remember to fix the issue. The idea is that there will be build chaos for the week of the 29th but that we take the week to stabilize the build, all together. I believe this would help us get faster to supporting NS. WDYT? Too bold or ok? :) Thanks -Vincent

2 1

[xwiki-devs] Fwd: [Proposal] Introduce the notion of Nested Documents
by Denis Gervalle 22 Jun '15

22 Jun '15

** BE CAREFUL, REPLYING VINCENT MAIL WITHOUT TRUNCATING HISTORY CAUSE MAILMAN TO REJECT YOUR ANSWER ** I hope this forward will not cause disruption in the mail thread. On Thu, Jun 18, 2015 at 12:33 PM, vincent(a)massol.net <vincent(a)massol.net> wrote: > So we really need to start deciding what will be the differences from a > user POV about the “Nested Spaces” view and the “Nested Documents” view. > > There are 2 possibilities I can think ok. > > Assumptions: > - In both cases we assume that by default XE is in “Nested Documents” view > when you install it and that going to the “Nested Spaces” view is an > advanced and technical option. > - In both cases we implement the hiding of WebHome everywhere in the UI by > assimilating WebHome and the Space it’s in. > Well, if we can assume that WebHome and space are the exact same thing, NS became really a edge case. > > Option 1 > ======== > > Concept: We clearly show the differences between Spaces and Documents in > the UI > > * Have an checkbox option in the user profile that is named something like > “Show the Space concept” > * Everywhere in the UI where we display spaces (and there are lots of > places), we display them differently than documents. Some examples: > ** In the Document Tree the icon used to display spaces is different than > the one used to display documents > ** In the Index application we would need to either have 2 tabs: one for > Documents and one for Spaces or a single one but in this case the Livetable > column should be named “Document and Spaces” and both entities should be > displayed differently (I’m assuming we want a single column, see T13 at > http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces#HOriginallisto… > ) > ** The Add button would list 2 actions: Add > Page and Add > Space > ** In the Main Wiki administration UI we have a “Select Space to > Administer” label to choose the space to administer > ** In the Add Page UI we ask the user to select both the document name and > the space in which it’s located > ** We can keep the “Space List” on the home page’s dashboard > > Option 2 > ======== > > Concept: We show Spaces and Documents as similarly as possible in the UI > to have the same UI as much as possible between “Nested Spaces” and “Nested > Documents”. > > * In the user profile, we would have a checkbox option named something > like “Ability to create several Documents in the same Space” > * Everywhere in the UI we don’t differentiate Spaces and Documents. The > same examples as above would become: > When you are in NS or ND mode, you still have an issue regarding existing document that are not WebHome. This is not really a matter of showing them the same or differently, but more of showing them or not. ** In the Document Tree we use the same icon (a node icon) to display > either spaces or documents -1, since here Document are not all document that could have childs. So, if I take your word about assumptions, there should be no difference with option one in term of icons. The difference could be that for ND, those documents that are not Webhome are simply not shown by default. > ** In the Index Application, we have a single Document tab and in the > Livetable column is named “Location” (or “Document Names”) and the > reference is displayed but without showing different icons for Spaces or > Documents. > Exact same effect here, even with ND, we still need to distinct those WebHome from simple documents. > ** The Add > Space menu entry could be removed and only an Add > Page > entry would stay but when you click on it, you’d still have the ability to > create new Spaces. Basically we ask the user to select both the document > name and the space in which it’s located > This is probably fine, and a good simplification of the UI. > ** We replace the “Space List” on the home page’s dashboard by a “Document > List” widget (showing both spaces and pages). > Fine, but again, in either mode, we need ways to distinct WebHome and simple documents. And again, the visibility of simple documents in ND mode should probably be hidden by default. > > In summary, option 2 reduces the difference between Nested Documents and > Nested Spaces to the Add > Page UI. > > Pros/Cons > ========= > > * Option 1: > ** Strong difference between Space/Documents in the UI > ** Hard to implement: lots of places need to have different behavior > depending on whether the user profile option is turned on or off > ** Existing extensions don’t need to be modified to feel natural if you’re > in the “Nested Spaces” mode. However note that since we want to have Nested > Documents by default these extensions must be updated ASAP anyway to > reflect that. > * Option 2: > ** Smaller difference between Space/Document in the UI > ** Easy to implement since the only UI > ** Existing extensions may not feel natural (until they’re updated for > Nested Documents but we need to do that anyway) > > WDYT? I’m worried that Option 1 is going to be costly to develop and > maintain. > I agree, we should think as much as possible in a way that makes development as sharable as possible between the two mode. Once, again, in either mode, we will need to support both type of documents (WebHome vs other documents), and it will require them to be clearly identifiable IMO. > Anca, since you were the one who raised this idea of keeping both “Nested > Spaces” and “Nested Documents” in the UI, what’s your POV? > > Thanks > -Vincent > > > -- Denis Gervalle SOFTEC sa - CEO

3 2

[xwiki-devs] [Contrib] Filesystem Attachment Porter
by Paul-Catalin Cojan 19 Jun '15

19 Jun '15

Hello devs! I did some customization on http://extensions.xwiki.org/xwiki/bin/view/Extension/Filesystem+Attachment+… and I want to put them on github. Can we have a repository for it? The name can be: filesystem-attachment-porter or if you have any suggestion. Thank you!

1 0

[xwiki-devs] Subject: Re: Answer to Eduard's feedback - Proposals for gallery photo
by Cray xWiki 19 Jun '15

19 Jun '15

Hello Eduard, Thank you very much for your feed back. -You’re right, step 4 is actually the final view of the creation process, where the user can check if all its informations and settings are corrects. -« Add albums » permits to create a quick album and also a sub-album inside an existing one, but it’s true that it’s not clear in the wireframes. -For the URL on slide 37-38, thank you for pointing us this detail. For the UI buttons, we proposed a flat design for rebranding the XWiki design. We noticed all your suggestions for future feedbacks, thank you for it and sorry we didn't answer to the two first answers, we were novice on using this type of mailing list. You can now consult our work through a macro gallery with the help of Ludovic Dubost. I remind you the link : http://design.xwiki.org/xwiki/bin/view/Proposal/PhotoAlbumBenchmark We are going to adjust our wireframes and mockups and let you know when we’re done. Thank you again for your help. CRAY Team 2015-06-17 17:57 GMT+02:00 <devs-request(a)xwiki.org>: > Send devs mailing list submissions to > devs(a)xwiki.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xwiki.org/mailman/listinfo/devs > or, via email, send a message with subject or body 'help' to > devs-request(a)xwiki.org > > You can reach the person managing the list at > devs-owner(a)xwiki.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devs digest..." > > > Today's Topics: > > 1. Re: Improvements proposals for a gallery photo (Eduard Moraru) > 2. Re: [Proposal][NestedSpaces] Deprecate and Remove new > DocumentReference(wiki, space, page) constructor (Eduard Moraru) > 3. Re: [VOTE] Drop support for Colibri Skin in 7.x > (Ecaterina Moraru (Valica)) > 4. Re: [VOTE] Drop support for IE8/IE9 in 7.x > (Ecaterina Moraru (Valica)) > 5. [ANN] XWiki 7.1.1 released (Guillaume "Louis-Marie" Delhumeau) > 6. Re: [Proposal][NestedSpaces] Deprecate and Remove new > DocumentReference(wiki, space, page) constructor > (Guillaume "Louis-Marie" Delhumeau) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Jun 2015 14:14:55 +0300 > From: Eduard Moraru <enygma2002(a)gmail.com> > To: XWiki Developers <devs(a)xwiki.org> > Subject: Re: [xwiki-devs] Improvements proposals for a gallery photo > Message-ID: > < > CADGDyY+S6mRYnGUGUQ7DUZYyJcJEoB-VY1hbTAfmGQPxXnrQ3g(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi, > > Nice mockups. > > Here are my remarks: > > * What is the purpose of step4 in the creation wizard (slides 33-34)? 3 > steps should be enough in a wizard and the 4th step looks more like "view" > mode to me and should be separate from the wizard. > > * What is the difference between AWM's "Add new entry" button and the "Add > album" button on the app's homepage (slides 35-36). Seems to me that they > both do the same thing. > > * Minor details: On slides 37-38, I am guessing you want to show the > details of the album "Holidays", but XWiki's UI (URL and breadcrumbs) > suggest you are still on the app's homepage. > > * Things to consider: On a similar note, you should consider XWiki's > actions for editing something (e.g. an album) with respect to the UI > buttons that are available at the bottom of the screen [1]. All you mockups > seem to be in "view" mode, however the create and edit steps for an album > entry should be performed in the "edit" (?editor=inline) mode. > > It`s great that you`re working on this and sharing it with the community. > Hope to hear more from you! > > Thanks, > Eduard > > P.S.: > --- > Note/suggestions for the future when asking for/receiving people's > feedback: > > I must admit that I have not read all the details in that PDF, I mainly > scanned the titles and looked at the mockups. I did not even touch the zip > file. You need to consider these things when asking for feedback, since if > you give a link, people will expect to find everything on the linked page. > In your case I had to find out that the content was attached to the page > and not in the page itself (the page was an empty and unattractive > "placeholder"). I had to download a pdf and view it, instead of reading a > wiki/web page. The zip attachment was just too complicated (download + > extract + view in local viewer + etc.). > > Bottom line is that people's time is precious and, if you want feedback, > you have to present it in a way that is easily reviewable. The more > complicated you make the process to review (i.e. the less time you spend in > preparing the work to be reviewed), the less reviews/feedback you will > receive from people that just can`t afford to invest the time. > > Also, maybe you`ve missed them, but there were a couple of replies [2] to > your initial message. Make sure you acknowledge the feedback you get so > that you keep people motivated in giving it again the next time :) > --- > > P.P.S.: Hope you take the above suggestions constructively and not as > critique. > > ---------- > [1] > > http://platform.xwiki.org/xwiki/bin/view/Features/PageEditing#HCommoneditac… > [2] > > http://markmail.org/thread/t6lo7lvqplrbcnfx#query:+page:1+mid:ubhhqlnyxklva… > > On Wed, Jun 17, 2015 at 12:45 AM, Cray xWiki <crayxwiki(a)gmail.com> wrote: > > > Dear all, > > > > For reminder, we are a groupe of four students working on a XWiki photo > > gallery improvements under the supervision of Ludovic Dubost. > > > > Please find on the link below (in the attachments section) a benchmark of > > Photo Albums and our requirements including wireframes and mock ups : > > http://design.xwiki.org/xwiki/bin/view/Proposal/PhotoAlbumBenchmark > > > > Feel free to give us feedback an our work and give us your opinion. We > are > > open to any suggestions you may have > > > > Thank you in advance. > > > > Best regards, > > > > CRAY team > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > ------------------------------ > > Message: 2 > Date: Wed, 17 Jun 2015 14:24:13 +0300 > From: Eduard Moraru <enygma2002(a)gmail.com> > To: XWiki Developers <devs(a)xwiki.org> > Subject: Re: [xwiki-devs] [Proposal][NestedSpaces] Deprecate and > Remove new DocumentReference(wiki, space, page) constructor > Message-ID: > < > CADGDyYL3sCaPTxG2W1mE+binSyFp3ucvEcW-2p86ZCqgBMBXzw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > +1. We don`t have much choice in this anyway. > > Thanks, > Eduard > > On Wed, Jun 17, 2015 at 11:07 AM, vincent(a)massol.net <vincent(a)massol.net> > wrote: > > > > > > > > > On 17 Jun 2015 at 10:04:00, Jean SIMARD (jean.simard(a)xwiki.com) wrote: > > > > > > > > On 17/06/2015 10:02, vincent(a)massol.net wrote: > > > We also need to do the same for: > > > public DocumentReference createDocumentReference(String wiki, String > > space, String page) > > > > > > > > > FTR: > > > > > > * 1300 places to fix in Java using new DocumentReference(wiki, space, > > page) > > > * 90 places using $services.model.createDocumentReference(?) in *.vm > > > * 140 places using $services.model.createDocumentReference(?) in *.xml > > > > > > That?s a lot? > > Yes but IntelliJ and sed are your friends ;-) > > > > > > Unfortunately not that simple? there?s no automatic fix. > > > > -Vincent > > > > > > > > > > Thanks > > > -Vincent > > > > > > On 17 Jun 2015 at 09:57:38, vincent(a)massol.net (vincent(a)massol.net) > > wrote: > > > > > > Hi devs, > > > > > > Ideally I believe we should remove the new DocumentReference(wiki, > > space, page) constructor. However, for backward compatibility we cannot > do > > this. > > > > > > So I propose that we start by deprecating it as we should now always > use > > the new DocumentReference(wiki, List<String> spaces, page) one. > > > > > > What I suggest we do to flesh out all issues related to Nested Spaces, > > is to start by removing it on our dev machines to find out places to fix. > > > > > > Then once we?ve progressed enough to not break everything, I suggest we > > move it to Legacy with an Aspect to make sure we don?t use it anymore. > > > > > > WDYT? > > > > > > Thanks > > > -Vincent > > > > > > > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > -- > > Jean Simard > > jean.simard(a)xwiki.com > > Research engineer at XWiki SAS > > http://www.xwiki.com > > Committer on the XWiki.org project > > http://www.xwiki.org > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > ------------------------------ > > Message: 3 > Date: Wed, 17 Jun 2015 14:46:40 +0300 > From: "Ecaterina Moraru (Valica)" <valicac(a)gmail.com> > To: XWiki Developers <devs(a)xwiki.org> > Subject: Re: [xwiki-devs] [VOTE] Drop support for Colibri Skin in 7.x > Message-ID: > < > CAHQu0mbkYi_vDZ1NFqsQodHzi75NaR36M7yf-Y08VTn_8FvjyQ(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi, > > Thanks for your votes. > > 6x(+1) + 2x(+1 non-binding) > > Vote has passed. > > I've updated > http://extensions.xwiki.org/xwiki/bin/view/Extension/Colibri+Skin > > Thanks, > Caty > > > On Tue, Jun 9, 2015 at 11:24 AM, Thomas Mortagne < > thomas.mortagne(a)xwiki.com> > wrote: > > > +1 > > > > On Tue, Jun 9, 2015 at 8:43 AM, vincent(a)massol.net <vincent(a)massol.net> > > wrote: > > > > > > > > > On 8 Jun 2015 at 12:16:24, Ecaterina Moraru (Valica) ( > valicac(a)gmail.com > > (mailto:valicac@gmail.com)) wrote: > > > > > >> Hi, > > >> > > >> This mail is about dropping support for Colibri Skin [1]. > > >> > > >> Colibri Skin has been developed in version 2.0 (Sep 2009) and used as > a > > >> default Skin until version 6.2 (Sep 2014), when it was replaced by > > Flamingo > > >> Skin [2]. > > >> > > >> Colibri is still supported for 6.x branch (currently we are developing > > >> version 6.4.5). > > >> > > >> Since the Flamingo Skin had stabilized, I propose we drop support for > > >> Colibri Skin in 7.x, in order to focus on Flamingo. > > >> This means the improvements and bugfixes will not be mandatory to be > > ported > > >> on Colibri anymore. > > >> We can still have Colibri bundled for one more cycle and after we can > > >> retired it. > > >> > > >> WDYT? > > >> > > >> Here is my +1 > > > > > > +1 to deprecate it now (i.e. update xwiki.org to mention the > > deprecation and its retirement that will soon happen) > > > +1 to remove it in 8.0 > > > > > > Thanks > > > -Vincent > > > > > >> Thanks, > > >> Caty > > >> > > >> > > >> > > >> [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Colibri+Skin > > >> [2] > http://extensions.xwiki.org/xwiki/bin/view/Extension/Flamingo+Skin > > >> [3] http://design.xwiki.org/xwiki/bin/view/Proposal/SupportSkin > > > > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > -- > > Thomas Mortagne > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > ------------------------------ > > Message: 4 > Date: Wed, 17 Jun 2015 15:42:57 +0300 > From: "Ecaterina Moraru (Valica)" <valicac(a)gmail.com> > To: XWiki Developers <devs(a)xwiki.org> > Subject: Re: [xwiki-devs] [VOTE] Drop support for IE8/IE9 in 7.x > Message-ID: > <CAHQu0mYAeCOLCmTqN6N17e2CJbKTRWEQOW3= > hQBqLsE_0wsa2Q(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi, > > Status: > 4x(+1) > 1x(+1 non-binding) > 1x(+0) > > The vote has passed. > I've updated > http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy > > Thanks for your votes, > Caty > > > On Fri, Jun 12, 2015 at 1:06 PM, vincent(a)massol.net <vincent(a)massol.net> > wrote: > > > > > > > On 9 Jun 2015 at 13:18:16, Ecaterina Moraru (Valica) (valicac(a)gmail.com > > (mailto:valicac@gmail.com)) wrote: > > > > > On Tue, Jun 9, 2015 at 9:49 AM, vincent(a)massol.net > > > wrote: > > > > > > > > > > > > > > > > > > > On 8 Jun 2015 at 15:41:15, Ecaterina Moraru (Valica) ( > > valicac(a)gmail.com > > > > (mailto:valicac@gmail.com)) wrote: > > > > > > > > > Hi, > > > > > > > > > > One year ago (Mar 2014) [1] we discussed dropping support for IE8 > > for the > > > > > 6.x cycle. The vote did not pass. > > > > > > > > > > Since then, we started the support for IE10/IE11 (Jun 2014) [2]. > > > > > > > > > > You can see some statistics and the current browsers we support at > > > > > > http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy > > > > > > > > > > This mail is about voting the drop of support for IE8/IE9 for cycle > > 7.x. > > > > > WDYT? > > > > > > > > > > My +1 > > > > > > > > Well, IE8+9 still account for close to 30% of browser shares > according > > to > > > > your link. Is it wise to drop a potential 30% user base? :) > > > > > > > > What?s the current status of IE8/9 in XWiki 7.1 for example (Do we > have > > > > lots of opened issues for them)? > > > > > > > > WDYM by dropping support: Do we remove code specific to support IE8/9 > > now > > > > or do we just stop fixing issues raised for IE8/9 from now on and we > > remove > > > > the specific code in 8.0? > > > > > > > > > > > There is a high chance the skin will work on IE8, especially since the > > > first versions of Flamingo was tested on IE8 and we added Respond.js > and > > > HTML5Shiv just for this case. > > > > > > Dropping support means that we will not particularly test on that > version > > > of browser, nor prioritizing fixing issues for it. We will focus on > newer > > > versions. We will still apply commits if contributors are interested. > > > > > > Regarding fixing issues on IE8, on several occasions I fixed issues for > > IE8 > > > in BFDs. > > > > > > Now if you consider that the user base is still great, we could leave > the > > > issues still open (instead of closing them as 'Not supported anymore'). > > The > > > main problem is that if you look at the Dashboard listing issues marked > > > with IE > > > http://jira.xwiki.org/issues/?filter=13809 > > > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13102 > > > all open issues (except 1) are reported by active contributors, not by > > > community user members. And that is because we still support the > browser: > > > still doing tests on it and providing fixes. For such an old browser > is a > > > waste of resources IMO. > > > > +0 > > > > Thanks > > -Vincent > > > > > Thanks, > > > Caty > > > > > > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > Thanks, > > > > > Caty > > > > > > > > > > > > > > > [1] http://markmail.org/thread/es5ghym4gphlj4mz > > > > > [2] http://markmail.org/thread/mzvcovh2da2t4e3w > > > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > ------------------------------ > > Message: 5 > Date: Wed, 17 Jun 2015 16:41:53 +0200 > From: "Guillaume \"Louis-Marie\" Delhumeau" <gdelhumeau(a)xwiki.com> > To: XWiki Developers <devs(a)xwiki.org>, XWiki Users <users(a)xwiki.org> > Subject: [xwiki-devs] [ANN] XWiki 7.1.1 released > Message-ID: > < > CAA+-eqW0Utb_k6mdrtQYhRTc6UbwMDO3J8fq-+qtEj0WpDvR1w(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > The XWiki development team is proud to announce the availability of XWiki > 7.1.1. > > This is a stabilization release that fixes important bugs discovered in the > 7.1 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/ReleaseNotesXWiki711 > > The following people have contributed code to this release: > > - Vincent Massol > - Guillaume Delhumeau > > Thanks for your support > -The XWiki dev team > > > ------------------------------ > > Message: 6 > Date: Wed, 17 Jun 2015 17:57:10 +0200 > From: "Guillaume \"Louis-Marie\" Delhumeau" <gdelhumeau(a)xwiki.com> > To: XWiki Developers <devs(a)xwiki.org> > Subject: Re: [xwiki-devs] [Proposal][NestedSpaces] Deprecate and > Remove new DocumentReference(wiki, space, page) constructor > Message-ID: > < > CAA+-eqW57oy_1Yg3K3kVr2R70hU9s-JyWxO+kkhTO93CnVLH-w(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > +1 > > 2015-06-17 13:24 GMT+02:00 Eduard Moraru <enygma2002(a)gmail.com>: > > > +1. We don`t have much choice in this anyway. > > > > Thanks, > > Eduard > > > > On Wed, Jun 17, 2015 at 11:07 AM, vincent(a)massol.net <vincent(a)massol.net > > > > wrote: > > > > > > > > > > > > > > On 17 Jun 2015 at 10:04:00, Jean SIMARD (jean.simard(a)xwiki.com) wrote: > > > > > > > > > > > > On 17/06/2015 10:02, vincent(a)massol.net wrote: > > > > We also need to do the same for: > > > > public DocumentReference createDocumentReference(String wiki, String > > > space, String page) > > > > > > > > > > > > FTR: > > > > > > > > * 1300 places to fix in Java using new DocumentReference(wiki, space, > > > page) > > > > * 90 places using $services.model.createDocumentReference(?) in *.vm > > > > * 140 places using $services.model.createDocumentReference(?) in > *.xml > > > > > > > > That?s a lot? > > > Yes but IntelliJ and sed are your friends ;-) > > > > > > > > > Unfortunately not that simple? there?s no automatic fix. > > > > > > -Vincent > > > > > > > > > > > > > > Thanks > > > > -Vincent > > > > > > > > On 17 Jun 2015 at 09:57:38, vincent(a)massol.net (vincent(a)massol.net) > > > wrote: > > > > > > > > Hi devs, > > > > > > > > Ideally I believe we should remove the new DocumentReference(wiki, > > > space, page) constructor. However, for backward compatibility we cannot > > do > > > this. > > > > > > > > So I propose that we start by deprecating it as we should now always > > use > > > the new DocumentReference(wiki, List<String> spaces, page) one. > > > > > > > > What I suggest we do to flesh out all issues related to Nested > Spaces, > > > is to start by removing it on our dev machines to find out places to > fix. > > > > > > > > Then once we?ve progressed enough to not break everything, I suggest > we > > > move it to Legacy with an Aspect to make sure we don?t use it anymore. > > > > > > > > WDYT? > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > > > > _______________________________________________ > > > > devs mailing list > > > > devs(a)xwiki.org > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > -- > > > Jean Simard > > > jean.simard(a)xwiki.com > > > Research engineer at XWiki SAS > > > http://www.xwiki.com > > > Committer on the XWiki.org project > > > http://www.xwiki.org > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Delhumeau (gdelhumeau(a)xwiki.com) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > > ------------------------------ > > End of devs Digest, Vol 96, Issue 27 > ************************************ >

1 0

[xwiki-devs] [Proposal] Reorganize a bit various Entity Reference Serializer by introducing some new ones
by vincent＠massol.net 19 Jun '15

19 Jun '15

Hi devs, I’m modifying code for handling NestedSpaces in URLs and a lot of code is doing reference serialization "by hand”. I’d like to rationalize this. Proposal: * Deprecate the “path” resolver/serializer which is currently located in platform-store-filesystem-attachment since “path” is misleading. It’s actually a FS Path (since it uses File.separator). * Introduce a new “fspath” resolver/serializer (copy the “path” one) but put it in the platform-model module since it should be able to be used by any module using the FS. * Introduce a new “file” serializer which will generate a file name out of a reference. UC: when needing to store temporary files (for exports for example) ** use “.” as separator ** escape the “.” using “%2E” as it’s done in the “path” serializer ( URLEncoder.encode(currentReference.getName(), "UTF-8").replace(".", "%2E")); ) hoping that whoever wrote it checked that “%” was a valid char in all File systems… ;) WDYT? Thanks -Vincent

3 6

Re: [xwiki-devs] [Proposal] Introduce the notion of Nested Documents
by Eduard Moraru 18 Jun '15

18 Jun '15

Hi, The problem with Option 2 is that in read-only mode it works, however, when you start manipulating regular document as if they were ND (e.g. add a child document or go to the document Administration), you need to convert the simple document into a ND (e.g. move X.Page to X.Page.WebHome) and the result would most certainly impact applications. Not sure if this is a problem that impacts only the transition period, but IMO it`s worth keeping in mind. A second (maybe not vital but still valid) issue with Option 2 is URLs. I understand we plan to resolve /bin/view/X/Y to X.Y if it exists, then try X.Y.WebHome and ultimately fallback to the page not found error. The issue I see is that if at point A in time X.Y.WebHome exists and at a later point B in time the document X.Y is also created, then any existing "/bin/view/X/Y" URLs that previously existed will no longer point at X.Y.WebHome, but will now point at X.Y instead, effectively hijacking it. The only way of accessing X.Y.WebHome after point B in time would be to use /bin/view/X/Y/WebHome and our objective was to remove "WebHome" from the UI or URLs. Even with the above in mind, I still favor Option 2, since option 1 sounds unrealistic in terms of work to be done an ensuring consistency across implementations. Thanks, Eduard

1 0

Re: [xwiki-devs] [Proposal] Introduce the notion of Nested Documents
by Ecaterina Moraru (Valica) 18 Jun '15

18 Jun '15

Hi, Regarding Anca's comment about: > * Said differently she believes that the UI should be in accordance with > the model and that it’s a bit utopian to think that users will never see > it. But she also acknowledges that it could be interesting for some users > or xwiki instances to have a simplified view. > > I think it depends on how well we hide something. Sure some users might find out there is a difference between Comments and Attachments implementation, even if in the UI they are represented at the same level (docextra) as entities that can be added on a page. It's our duty to make things transparent / easier for user, no matter what is the behind implementation. --- I already mentioned that I prefer Option 2, creating the UI for Nested Documents. This way we remove a level from XWiki's structure complexity and remain only with 'main wiki / wikis / pages'. Users will create hierarchies of pages. They will be making Add/Delete/Move/.../Administer on nodes. It will be harder for us with this transition from nested spaces to nested documents to provide some of the magic to make actions invisible for end-users (like transforming pages into spaces, or creating page administration, etc.). With a difference in the UI for Spaces and Pages, for end-users I think it will be very hard to understand why: - they can create multiple spaces, but not pages; - why there are differences between actions that can be performed on spaces and pages; - why we have pages, but we don't have WebHome pages on spaces; - why we have administration of multiple levels of spaces, but we don't have at page level; - why are the leaves so important that they are represented in a different manner; - why we separate everywhere in the UI the spaces concept, but we don't quite use it, since spaces need pages in order to exist. - even spaces.webhomes dashboards might sound a bit off, since users are mostly interested in content when it comes to such hierarchies. > > > On Thu, Jun 18, 2015 at 1:33 PM, vincent(a)massol.net <vincent(a)massol.net> > wrote: > >> So we really need to start deciding what will be the differences from a >> user POV about the “Nested Spaces” view and the “Nested Documents” view. >> >> There are 2 possibilities I can think ok. >> >> Assumptions: >> - In both cases we assume that by default XE is in “Nested Documents” >> view when you install it and that going to the “Nested Spaces” view is an >> advanced and technical option. >> - In both cases we implement the hiding of WebHome everywhere in the UI >> by assimilating WebHome and the Space it’s in. >> >> Option 1 >> ======== >> >> Concept: We clearly show the differences between Spaces and Documents in >> the UI >> >> * Have an checkbox option in the user profile that is named something >> like “Show the Space concept” >> > > If this option's target are just advanced users / developers, I don't see no reason to alter all the UI in order to show the Space concept. I propose this option maybe would display a full reference of the document in the #docextra Information tab, in order for the developer to use in scripting that reference. > > >> * Everywhere in the UI where we display spaces (and there are lots of >> places), we display them differently than documents. Some examples: >> ** In the Document Tree the icon used to display spaces is different than >> the one used to display documents >> ** In the Index application we would need to either have 2 tabs: one for >> Documents and one for Spaces or a single one but in this case the Livetable >> column should be named “Document and Spaces” and both entities should be >> displayed differently (I’m assuming we want a single column, see T13 at >> http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces#HOriginallisto… >> ) >> > > I would disagree to add more tabs in the AllDocs page. IMO some of the functionality got deprecated by the ability to filter in the SOLR Search. I don't see any reason to keep the Attachments tabs (when I can filter for attachments) - also the current Attachment tabs list attachments even if the containing page is hidden, so it's clearly we have some deprecated code there. Same for Deleted Doc and Deleted Attachments which should be replaced with a Recycle bin; Orphaned Pages. What should remain is a Documents/Pages Index, with a Livetable and a Tree display + a Recycle Bin. > > >> ** The Add button would list 2 actions: Add > Page and Add > Space >> ** In the Main Wiki administration UI we have a “Select Space to >> Administer” label to choose the space to administer >> ** In the Add Page UI we ask the user to select both the document name >> and the space in which it’s located >> ** We can keep the “Space List” on the home page’s dashboard >> >> Option 2 >> ======== >> >> Concept: We show Spaces and Documents as similarly as possible in the UI >> to have the same UI as much as possible between “Nested Spaces” and “Nested >> Documents”. >> >> * In the user profile, we would have a checkbox option named something >> like “Ability to create several Documents in the same Space” >> * Everywhere in the UI we don’t differentiate Spaces and Documents. The >> same examples as above would become: >> ** In the Document Tree we use the same icon (a node icon) to display >> either spaces or documents >> ** In the Index Application, we have a single Document tab and in the >> Livetable column is named “Location” (or “Document Names”) and the >> reference is displayed but without showing different icons for Spaces or >> Documents. >> ** The Add > Space menu entry could be removed and only an Add > Page >> entry would stay but when you click on it, you’d still have the ability to >> create new Spaces. Basically we ask the user to select both the document >> name and the space in which it’s located >> > > We will have just one Add - Page. It will default the parent to the current location, with the ability to change it to other parent (Tree or Input). > > >> ** We replace the “Space List” on the home page’s dashboard by a >> “Document List” widget (showing both spaces and pages). >> > > I've mentioned some notes on 'The future of Spaces macro' ( http://xwiki.markmail.org/thread/fz6fonamx4d3x25i) that we might even replace this macro with the tree, or even remove it in favor of a Navigation panel. Also I think now is a good time to clean a bit old stufff and deprecate / remove it. I don't see no reason to keep/update the create panel or any other panels that we haven't used in years. I already mentioned tabs in AllDocs that have been deprecated by new features. Even the Information tabs is listing the parent that we will provide additional view for it. Also the Spaces Macro, why improve it when we have a Document Tree Macro? For me Option 1 is too complex and this complexity doesn't provide any benefit for the end-user. All the user wants is to be able to create hierarchies. He doesn't care if there are spaces or pages. Thanks, Caty > > >> >> In summary, option 2 reduces the difference between Nested Documents and >> Nested Spaces to the Add > Page UI. >> >> Pros/Cons >> ========= >> >> * Option 1: >> ** Strong difference between Space/Documents in the UI >> ** Hard to implement: lots of places need to have different behavior >> depending on whether the user profile option is turned on or off >> ** Existing extensions don’t need to be modified to feel natural if >> you’re in the “Nested Spaces” mode. However note that since we want to have >> Nested Documents by default these extensions must be updated ASAP anyway to >> reflect that. >> * Option 2: >> ** Smaller difference between Space/Document in the UI >> ** Easy to implement since the only UI >> ** Existing extensions may not feel natural (until they’re updated for >> Nested Documents but we need to do that anyway) >> >> WDYT? I’m worried that Option 1 is going to be costly to develop and >> maintain. >> >> Anca, since you were the one who raised this idea of keeping both “Nested >> Spaces” and “Nested Documents” in the UI, what’s your POV? >> >> Thanks >> -Vincent >> >

1 0

[xwiki-devs] Fw: [xwiki-notifications] [xwiki/xwiki-platform] 4c4a36: XWIKI-12169: Add support for parsing nested spaces...
by vincent＠massol.net 18 Jun '15

18 Jun '15

What??? Why is the author “Marius”? I just committed it! :) -Vincent On 18 Jun 2015 at 16:59:00, GitHub (noreply@github.com(mailto:noreply@github.com)) wrote: > Branch: refs/heads/master > Home: https://github.com/xwiki/xwiki-platform > Commit: 4c4a367de5d305455dda91e4fcfc02ef7ac42374 > https://github.com/xwiki/xwiki-platform/commit/4c4a367de5d305455dda91e4fcfc… > Author: Marius Dumitru Florea > Date: 2015-06-18 (Thu, 18 Jun 2015) > > Changed paths: > M xwiki-platform-core/xwiki-platform-url/xwiki-platform-url-schemes/xwiki-platform-url-scheme-standard/src/main/java/org/xwiki/url/internal/standard/entity/AbstractEntityResourceReferenceResolver.java > M xwiki-platform-core/xwiki-platform-url/xwiki-platform-url-schemes/xwiki-platform-url-scheme-standard/src/test/java/org/xwiki/url/internal/standard/BinEntityResourceReferenceResolverTest.java > > Log Message: > ----------- > XWIKI-12169: Add support for parsing nested spaces in URLs > * Added special handling for "viewattachrev" and "delattachment" (in addition to "download") a which need to consider the last segment to be the attachment > > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

1 0

[xwiki-devs] [Proposal][NestedSpaces] Deprecate and Remove new DocumentReference(wiki, space, page) constructor
by vincent＠massol.net 18 Jun '15

18 Jun '15

Hi devs, Ideally I believe we should remove the new DocumentReference(wiki, space, page) constructor. However, for backward compatibility we cannot do this. So I propose that we start by deprecating it as we should now always use the new DocumentReference(wiki, List<String> spaces, page) one. What I suggest we do to flesh out all issues related to Nested Spaces, is to start by removing it on our dev machines to find out places to fix. Then once we’ve progressed enough to not break everything, I suggest we move it to Legacy with an Aspect to make sure we don’t use it anymore. WDYT? Thanks -Vincent

5 7