On Mon, May 22, 2017 at 4:46 PM, Thomas Mortagne <[email protected]> wrote: > On Mon, May 22, 2017 at 4:44 PM, Vincent Massol <[email protected]> wrote: >> >>> On 22 May 2017, at 16:39, Thomas Mortagne <[email protected]> wrote: >>> >>> On Mon, May 22, 2017 at 4:31 PM, Vincent Massol <[email protected]> wrote: >>>> >>>>> On 22 May 2017, at 16:27, Thomas Mortagne <[email protected]> >>>>> wrote: >>>>> >>>>> On Mon, May 22, 2017 at 3:37 PM, Vincent Massol <[email protected]> >>>>> wrote: >>>>>> >>>>>>> On 22 May 2017, at 15:34, Thomas Mortagne <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> I would be more in favor of moving them to some extension than can be >>>>>>> easily installed if really needed. >>>>>> >>>>>> The downside with this approach compared to the legacy approach are: >>>>>> >>>>>> * The user will gets broken before they can understand the problem and >>>>>> fix it so bad from a usability POV. They’ll also need to understand >>>>>> where to get the extension and install it >>>>>> * We break a contract if we consider that default pages are a contract >>>>>> (we need to decide about that but I think it would be fair to say the >>>>>> pages are a contract) >>>>> >>>>> Well by that definition we "broke" quite a lot of XE pages over the >>>>> years by moving them to not bundled contrib extensions or simply by >>>>> modifying some page that never been supposed to be API. Saying any >>>>> page is an API is really not a good idea in the current state. We >>>>> could discuss an explicit way to indicate what is an API and what is >>>>> internal for future pages if you want but right now It should be a >>>>> case by case I think. >>>>> >>>>> If you absolutely want to keep them, keep them. I'm just saying that I >>>>> would be OK to move them away (provided that they are easy to install >>>>> if really needed) since they display stuff that many recent users >>>>> won't understand ("space" ?) and I don't think they are used that much >>>>> in extensions. >>>> >>>> Yes but that’s not the main point. The main point is breaking the XWiki UI >>>> of the user who upgrades (and thus introducing a WTF effect - what I >>>> called a usability issue). So what you’re saying in essence, is that it’s >>>> ok to do so from your POV. >>> >>> I don't understand. Standard XE UI does not use those pages anywhere >>> anymore so what is going to be broken exactly when you upgrade ? >>> My >>> point is that it's only supposed to break extensions that would use >>> those pages or if the user have customization that rely on those pages >>> but that's true for any change in any page most of which never been >>> designed as APIs (so a lot less carefully than is required for an >>> API). >> >> Take for example the home page which was using Main.Spaces AFAIR. Imagine >> I’m on XWiki 7.x and I’ve customized the home page. When I upgrade to 9.x >> I’ll keep the home page that I’ve customized. So the home page will not get >> displayed correctly anymore (if it’s using an include, it’ll be missing >> content). >> >> I’d venture that 99% of wikis used for real have their home page customized >> and thus this should affect a lot of users. > > I agree with the 99% but not so much with the fact that they keep the > spaces widget :)
Note: we replaced the space panel in the dashboard by a pages panel in 7.2. > >> >> Thanks >> -Vincent >> >>> >>>> >>>> Any other opinion on this (I’d like more before deciding on something)? >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> On Mon, May 22, 2017 at 2:41 PM, Vincent Massol <[email protected]> >>>>>>> wrote: >>>>>>>> Hi devs, >>>>>>>> >>>>>>>> We have this jira issue I created a while ago and I’d like to move >>>>>>>> forward: >>>>>>>> https://jira.xwiki.org/browse/XWIKI-13101 >>>>>>>> >>>>>>>> I have one question: >>>>>>>> Should we move the 4 pages into a legacy module in platform and bundle >>>>>>>> it in XE or just remove them? >>>>>>>> >>>>>>>> My POV: >>>>>>>> We could consider the pages as APIs I guess and use the API strategy >>>>>>>> of moving deprecated APIs to legacy. >>>>>>>> >>>>>>>> WDYT? >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thomas Mortagne >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Mortagne >>>> >>> >>> >>> >>> -- >>> Thomas Mortagne >> > > > > -- > Thomas Mortagne -- Thomas Mortagne
