xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] Subject: Re: Answer to Eduard's feedback - Proposals for gallery photo

by Cray xWiki

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

9 years, 6 months

[xwiki-devs] [Proposal] Reorganize a bit various Entity Reference Serializer by introducing some new ones

by vincent＠massol.net

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

9 years, 6 months

Re: [xwiki-devs] [Proposal] Introduce the notion of Nested Documents

by Eduard Moraru

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

9 years, 6 months

Re: [xwiki-devs] [Proposal] Introduce the notion of Nested Documents

by Ecaterina Moraru (Valica)

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

9 years, 6 months

[xwiki-devs] Fw: [xwiki-notifications] [xwiki/xwiki-platform] 4c4a36: XWIKI-12169: Add support for parsing nested spaces...

by vincent＠massol.net

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

9 years, 6 months

[xwiki-devs] [Proposal][NestedSpaces] Deprecate and Remove new DocumentReference(wiki, space, page) constructor

by vincent＠massol.net

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

9 years, 6 months

[xwiki-devs] Solr search use cases regarding nested spaces

by Marius Dumitru Florea

Hi devs, As we started to work on addind support for nested spaces, we need to think about search use cases that we expect the Solr search to cover regarding nested spaces. Currently, with one level of space, we support: UC1: Search for documents in space X (exact match) UC2: Search for documents in a space like X (free text search) With nested spaces we need to take into account several new use cases: UC1: Search for documents that are direct children of the path X.Y.Z (exact match for path) -> matches X.Y.Z.Page but not X.Y.Page and neither X.Y.Z.A.Page UC2: Search for documents that are descendents of the path X.Y.Z (exact match for path) -> matches X.Y.Z.Page and X.Y.Z.A.Page but not X.Y.Page UC3: Search for documents that have space X as parent anywhere in the hierarchy (exact match for space) -> matches A.X.Page and X.Page but not A.X.Y.Page UC4: Search for documents that have space X as ancestor anywhere in the hierarchy (exact match for space) -> matches X.Page and A.X.Y.Page but not Y.Z.Page UC5: Search for documents that have the path like X.Y.Z (free text search) -> matches X.Page, Z.Y.Page, Y.Z.X.Page UC6: Search for documents that have the parent space like X (free text search) Do you see any other use cases? Is any of the use cases I listed not useful, and can be discarded? Thanks, Marius

9 years, 6 months

[xwiki-devs] [Proposal] Introduce the notion of Nested Documents

by Guillaume "Louis-Marie" Delhumeau

Hello XWiki committers. Vincent have proposed the development of nested spaces for 7.2 and some of us have already agreed. But the concept of nested spaces introduces a problem that Denis have mentioned during some internal discussions at XWiki SAS, and that I am going to report here. >From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` could become very difficult. Moreover, we know that a lot of users do not understand the notion of spaces, and they are lost when you look at them during usability sessions. The situation is even worse if you consider the notion of parent/child documents, which is completely unrelated to the actual hierarchy. It creates confusion! To fix these problems, we propose to introduce the notion of "nested documents", i.e. the ability to create documents inside documents. Say differently, if a page `A.B.C` exists, nothing should stop the user to create the document `A.B.C.D`. In JCR[1], there is only one concept: the "node". A node can have a content, and a list of child nodes. In XWiki, documents could become a kind of nodes, and we do not need spaces anymore. If we don't have space anymore, we could ask ourselves: "How the rights will be propagated to the children documents? How do we distinguish rights applied to the documents and the rights applied to the children?" I think the easiest solution is to inherit the rights from the parent to the children, unless an object prevent it. We already have this kind of mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be applied for the current document, and XWikiGlobalRights for the document and its children. But changing the XWiki model is a lot of work, that we don't have time to achieve for 7.2. So we propose to make it step by step. The first step is to change the UI to hide the notion of space to the users. Concretely, each time a user wants to create a page called `A`, we actually create the document `A.WebHome`. So any child of this page would be created in the `A` space, like `A.Child`. But this child would be in a space too, so it would be `A.Child.WebHome` actually. Then, when we display the `A.WebHome` page, we remove all mentions to the `WebHome` name. In the UI, it will just be presented as the document `A`. This is a good point, knowing the fact that the term `WebHome` have no sense for the user, neither in English or in other languages. Again, these changes are only for the UI. For the applications, it is the developer's job to decide if the app will create documents like `Document.WebHome` or basic documents just as before. The question of what to do with AWM comes up. When a user creates an entry, should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an old-kind-of-document (`AppSpace.Entry`)? The first option is good for consistency and for the new possibilities it offers, but the second is better for retro-compatibility. And the question will be the same for all existing applications that create pages. I believe we should answer these questions on a case-by-case basis and deserve their own mail threads. This proposal also implies to change some macros, like the {{space}} one, and some panels. But I believe there is no blocking-point there. Finally, after these steps are accomplished in 7.2 and polished until the end of the 7.x cycle, we will refactor the XWiki model (something we dream about for years). To sum up, the idea we propose is: On the short run: - Hide the notion of space in the UI. - Hide the `WebHome` name in the UI. - When a user creates a page from the UI, it actually creates a space with a WebHome. - Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy. On the long run: - Remove the notion of space in the model, and replace it by "nested documents". - Tune the rights system to inherit rights from parents to children. Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents). So, I hope you will like this proposal, and here is my +1. Thanks, Guillaume D. [1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

9 years, 6 months

[xwiki-devs] Improvements proposals for a gallery photo

by Cray xWiki

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

9 years, 6 months

[xwiki-devs] XE distribution still growing

by vincent＠massol.net

Hi devs, Not sure we want to do anything about it but just wanted to point out that our XE distribution is still growing in size, see https://www.evernote.com/l/AHeoW5wLif9LwqNbItVqgFUOuiHipy8rINA Two questions: * Why is 7.1 bigger by 14MB than 7.0. Probably some JARs we updated like SOLR. Could be interesting to check. * Why are 6.4.x releases smaller than 6.4? Probably some JAR update too. Anyway this is more a FYI, I’m not proposing any plan ATM. Thanks -Vincent

9 years, 6 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