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

Reply via email to