+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, vincent(a)massol.net <vincent(a)massol.net> wrote:
  Hi Caty,
 On 30 Jun 2014 at 16:56:57, Ecaterina Moraru (Valica)
(valicac@gmail.com(mailto:valicac@gmail.com)) 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, vincent(a)massol.net
 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…
 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
 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