On 27 Sep 2014 at 11:07:48, [email protected]
([email protected](mailto:[email protected])) wrote:
> FTR the results of the proposals (wasn’t a vote) were:
> - Vincent: +1
> - Marius: +1
> - Edy: +1
> - Thomas: +1
> - Guillaume: +1
> - Caty: I’d say 0 since she said "I don't have a clear opinion of this
> feature (it is nice to have), but not
> sure it will fix any of our problems.”
>
> Unfortunately I asked on IRC yesterday (see
> http://dev.xwiki.org/xwiki/bin/view/IRC/xwikiArchive20140926) and it seems
> people changed their minds since almost everyone told me to not commit it
> anymore and instead move it as a contrib extension for now.
>
> I’ve tried to make my case (see IRC) but it didn’t work ;) and in the end I
> have respected other’s position and made it available as an extension (took
> me 1 hour to do that, would take another hour to move it back to platform in
> the future too).
>
> In any case, it’s now available at
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Home+Page+Application
> and you can test it (note that I’ve noticed we get a conflict when installing
> it, not sure why yet, I’ve pinged Thomas about it).
>
> Please play with it and let me know what we should do about it. I still find
> it a pity that we do nothing and continue to have a crappy situation (as
> proven by Caty’s usability tests).
>
> Note that in the roadmap for 6.3 Edy is going to take care of the
> http://jira.xwiki.org/browse/XE-1389 (Welcome block is too hard to edit)
> issue but this Home Page Application is actually not fixing this issue, it’s
> fixing:
> - ability to use your own content on the home page (when using any edit mode:
> default inline mode, the wiki editor, or the WYSIWYG editor)
> - ability to change the home page to display the content of another page/space
>
> Also note that there are some fine tuning to bring to it to be perfect.For
> example right now the LiveTable does show hidden docs and
s/does/doesn’t/
-Vincent
> Dashboard.WebHome is hidden by default. There are various solutions, one of
> them being to list hidden docs in the LT. Another one is to restrict the
> feature and allow to point only to Application home pages or to Space home
> pages.
>
> Thanks
> -Vincent
>
>
> On 29 Aug 2014 at 15:02:19, Guillaume Lerouge
> ([email protected](mailto:[email protected])) wrote:
>
> > Hi,
> > ᐧ
> >
> > so in the end was this implemented or not? Albeit imperfect, it did improve
> > the current situation a bit.
> >
> > Guillaume
> >
> > On Tue, Jul 1, 2014 at 7:28 PM, [email protected]
> > wrote:
> >
> > > Hi Thomas,
> > >
> > > I’m not sure this app is generic. I imagined it for the main home page of
> > > the wiki.
> > >
> > > The main reason is that since the main home page does an include of the
> > > dashboard app’s home page it wasn’t easy for the user to edit it.
> > >
> > > This is not the case for the spaces. When you create a space using the
> > > “Space Dashboard” template there’s no include. It generates a home page
> > > with the “{{dashboard}}” macro call inside and it’s easy to edit it by
> > > clicking the edit button (it goes in inline mode directly).
> > >
> > > Thus for me this is really only about the main webhome of the wiki.
> > >
> > > Maybe one day we’ll make the WYSIWYG editor so much more obvious to use
> > > that it won’t be needed anymore and we’ll be able to remove it. For
> > > example
> > > if the WYSIWYG editor was providing a custom UI editor for the display
> > > macro and if it made it obvious that the display macro can be edited we
> > > wouldn’t need this app I think.
> > >
> > > Thanks
> > > -Vincent
> > >
> > > On 1 Jul 2014 at 19:20:47, Thomas Mortagne ([email protected]
> > > (mailto:[email protected])) wrote:
> > >
> > > > Actually it does not fit DocumentSheetBinding since this feature is
> > > > about display and not include.
> > > >
> > > > In any case the feature seems a lot more generic than home page so it
> > > > would be a pity to limit it to that so I propose "Default Page App"
> > > > instead.
> > > >
> > > > On Tue, Jul 1, 2014 at 6:32 PM, Thomas Mortagne
> > > > wrote:
> > > > > +1 for the theory
> > > > >
> > > > > Just thinking that instead of introducing a new class, the property
> > > > > "optionnal" set to true (maybe the default) in
> > > > > XWiki.DocumentSheetBinding could probably trigger the same thing since
> > > > > XWiki.DocumentSheetBinding already have this concept for giving to
> > > > > another sheet the display of the document.
> > > > >
> > > > > On Mon, Jun 30, 2014 at 5:36 PM, [email protected] wrote:
> > > > >> Hi Caty,
> > > > >>
> > > > >> On 30 Jun 2014 at 16:56:57, Ecaterina Moraru (Valica) (
> > > [email protected](mailto:[email protected])) wrote:
> > > > >>
> > > > >>> The problem is that you are changing the user's expectations of how
> > > he can
> > > > >>> interact with pages right from the start (Homepage).
> > > > >>> Users might like to have this 'selection' behavior for other pages
> > > too, not
> > > > >>> just the Homepage.
> > > > >>>
> > > > >>> What you are describing is setting a template for the Homepage
> > > (Dashboard,
> > > > >>> empty, or any other existing page), but it doesn't solve the initial
> > > > >>> problems with the editing of Welcome message, the technicality of
> > > WYSWYG
> > > > >>> include macros, the display of rendered macros in WYSIWYG, etc.
> > > > >>
> > > > >> Sure it doesn’t solve everything (I never said it was!). As I
> > > mentioned it solves the following 2 points:
> > > > >> - Make it easy for the user to be able to change his wiki's home page
> > > > >> - Make it understandable when clicking “edit” on the home page
> > > > >>
> > > > >> Now regarding edition of the dashboard (and thus edition of the
> > > Welcome message), I do believe it helps:
> > > > >> - Users will click “Edit” on the home page
> > > > >> - They will see it actually points to Dashboard.WebHome and they’ll
> > > see the “Edit” link (see screenshot)
> > > > >> - When they click on the “edit” button they’ll arrive in inline edit
> > > mode on Dashboard.WebHome and thus be able to edit all widgets, including
> > > the Welcome one.
> > > > >>
> > > > >>> I don't have a clear opinion of this feature (it is nice to have),
> > > but not
> > > > >>> sure it will fix any of our problems.
> > > > >>
> > > > >> Maybe it doesn’t fix all problems (although I think it comes close)
> > > but I don’t understand why it wouldn’t fix “any” of our problems.
> > > > >>
> > > > >> Would be interesting to try out on newcomers ;)
> > > > >>
> > > > >> In any case I think it’s a nice progress from what we have and it’s
> > > easy to do. I’m willing to do it for XWiki 6.2M1.
> > > > >>
> > > > >> Thanks
> > > > >> -Vincent
> > > > >>
> > > > >>> Thanks,
> > > > >>> Caty
> > > > >>>
> > > > >>>
> > > > >>> On Mon, Jun 30, 2014 at 9:50 AM, [email protected]
> > > > >>> wrote:
> > > > >>>
> > > > >>> >
> > > > >>> > Hi devs,
> > > > >>> >
> > > > >>> > Problem
> > > > >>> > =======
> > > > >>> >
> > > > >>> > This week end I’ve had an idea that solves the following issue:
> > > > >>> >
> > > > >>> > - Make it easy for the user to be able to change his wiki's home
> > > page
> > > > >>> > - Make it understandable when clicking “edit” on the home page
> > > > >>> >
> > > > >>> > Solution
> > > > >>> > =========
> > > > >>> >
> > > > >>> > At some point in the past, I moved the dashboard which was on the
> > > home
> > > > >>> > page to the Dashboard space. My rationale at the time was:
> > > > >>> > - if the user removes the home page then the user will still be
> > > able to
> > > > >>> > navigate to the Dashboard by clicking on the “Dashboard” link in
> > > the
> > > > >>> > Applications Panel
> > > > >>> > - when editing the home page it’s “just” an Include
> > > > >>> >
> > > > >>> > Said differently, I considered that the home page can be
> > > configured to
> > > > >>> > point to any app.
> > > > >>> >
> > > > >>> > This is what I’d like to push for and make it easy for the user to
> > > > >>> > configure the home page so that it can point to any app.
> > > > >>> >
> > > > >>> > Implementation
> > > > >>> > ===============
> > > > >>> >
> > > > >>> > - A HomePage.HomePageClass XClass with one “reference” field which
> > > is the
> > > > >>> > reference to the document to include from the home page (the app
> > > to point
> > > > >>> > to if you prefer)
> > > > >>> > - A HomePage.HomePageSheet which is bound to the
> > > HomePage.HomePageClass
> > > > >>> > - One instance of the HomePage.HomePageClass put in Main.WebHome
> > > so that
> > > > >>> > when you click “edit” on the home page, HomePage.HomePageSheet is
> > > called
> > > > >>> > and displays some instructions about changing the home page.
> > > Here’s an
> > > > >>> > example:
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > https://www.evernote.com/shard/s119/sh/b682040d-6a09-4cfc-b6aa-1eab4b4d8d5e/f970d4cd4c0e2e73742e9f6e6fb3793c
> > > > >>> >
> > > > >>> > Here’s the content of HomePageSheet (not finished, I still need to
> > > code
> > > > >>> > the part that changes the “reference” property):
> > > > >>> >
> > > > >>> > {{velocity}}
> > > > >>> > #if ($xcontext.action == 'edit')
> > > > >>> > #set ($previewenabled = 'false')
> > > > >>> > The content of this home page can be the content of any page you
> > > wish.
> > > > >>> >
> > > > >>> > Right now it is displaying the content of the
> > > > >>> > [[$doc.getValue('reference')>>$doc.getValue('reference')]] page.
> > > > >>> >
> > > > >>> > In order to change it, click the "Use as Home Page" link in the
> > > table
> > > > >>> > below for the page you wish to use as your new home page.
> > > > >>> >
> > > > >>> > #set($collist = ['doc.name', 'doc.space', 'doc.date',
> > > 'doc.author',
> > > > >>> > '_actions'])
> > > > >>> > #set($colprops = {
> > > > >>> > 'doc.title' : { 'type' : 'text' , 'size' : 30, 'link' : 'view' },
> > > > >>> > 'doc.fullName' : { 'type' : 'text' , 'size' : 30, 'link' : 'view'
> > > },
> > > > >>> > 'doc.name' : { 'type' : 'text' , 'size' : 30, 'link' : 'view' },
> > > > >>> > 'doc.space' : { 'type' : 'text', 'link' : 'space' },
> > > > >>> > 'doc.date' : { 'type' : 'date' },
> > > > >>> > 'doc.author' : { 'type' : 'text', 'link' : 'author' },
> > > > >>> > '_actions': { 'html': true, 'sortable': false, 'actions': ['Use']
> > > > >>> > }
> > > > >>> > })
> > > > >>> > #set($options = {
> > > > >>> > 'translationPrefix' : 'platform.index.'
> > > > >>> > })
> > > > >>> > #livetable('documents' $collist $colprops $options)
> > > > >>> > #else
> > > > >>> > ## If there's content don't use the default app
> > > > >>> > #if ($doc.content.trim().length() > 0)
> > > > >>> > $doc.content
> > > > >>> > #else
> > > > >>> > {{include reference="$doc.getValue('reference')" context="new"/}}
> > > > >>> > #end
> > > > >>> > #end
> > > > >>> > {{/velocity}}
> > > > >>> >
> > > > >>> > - Note that if the user forces the edition in wiki mode or WYSIWYG
> > > mode of
> > > > >>> > the home page he gets an empty page and he can put content and
> > > when he
> > > > >>> > saves his content is displayed! (this is achieved through the
> > > following
> > > > >>> > portion of the script in HomePageSheet:
> > > > >>> >
> > > > >>> > ## If there's content don't use the default app
> > > > >>> > #if ($doc.content.trim().length() > 0)
> > > > >>> > $doc.content
> > > > >>> > #else
> > > > >>> > {{include reference="$doc.getValue('reference')" context="new"/}}
> > > > >>> > #end
> > > > >>> >
> > > > >>> > - Also note that I’d like to propose to add the ability to
> > > configure the
> > > > >>> > buttons to display in edit mode. ATM I think only the preview one
> > > can be
> > > > >>> > hidden but we could do the same for all. In our case here we could
> > > decide
> > > > >>> > to only leave the “Cancel” one active since clicking on “use” in
> > > the
> > > > >>> > Livetable could set the page to include immediately. The other
> > > option is to
> > > > >>> > use a different picker than the livetable and keep the save
> > > buttons. Any
> > > > >>> > suggestion for this?
> > > > >>> >
> > > > >>> > The idea would be to package this as an HomePage Application in
> > > > >>> > xwiki-platform and would be bundled by default in XE.
> > > > >>> >
> > > > >>> > WDYT?
> > > > >>> >
> > > > >>> > Thanks
> > > > >>> > -Vincent
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> > _______________________________________________
> > > > >>> > devs mailing list
> > > > >>> > [email protected]
> > > > >>> > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >>> >
> > > > >>> _______________________________________________
> > > > >>> devs mailing list
> > > > >>> [email protected]
> > > > >>> http://lists.xwiki.org/mailman/listinfo/devs
> > > > >> _______________________________________________
> > > > >> devs mailing list
> > > > >> [email protected]
> > > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thomas Mortagne
> > > >
> > > >
> > > >
> > > > --
> > > > Thomas Mortagne
> > > > _______________________________________________
> > > > devs mailing list
> > > > [email protected]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > > _______________________________________________
> > > devs mailing list
> > > [email protected]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > [email protected]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
