30 Jun
2014
30 Jun
'14
11:59 a.m.
+1, but hopefully without duplicating the doc.content field in a new
xproperty.
Thanks,
Eduard
On Mon, Jun 30, 2014 at 10:54 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 30 Jun 2014 at 09:45:58, Marius Dumitru Florea (
mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com))
wrote:
>
https://www.evernote.com/shard/s119/sh/b682040d-6a09-4cfc-b6aa-1eab4b4d8d5e…
Indeed redirecting is a good idea.
Two solutions for the problem you raise:
- option 1: Have an Admin screen for the HomePage application
(ConfigurableClass) so that the admin user can always configure the page to
point to
- option 2: Add a “content” field of type TextArea in HomePageClass and
display it in HomePageSheet when editing in inline mode, saying that the
user can either choose to display the content of any existing page or if he
wants write his own content below. Remark: It would be nice to not have to
create a new xproperty and instead point directly to the doc’s content in
edit mode, maybe we could modify our code to support this ;) If we do this,
then it’ll work too even if the user forces the wiki or WYSIWYG edit mode,
which is nice.
Option 2 seems to be a more “integrated” solution which also has the
advantage of not requiring any redirect.
Thanks
-Vincent
> Thanks
> -Vincent _______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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:
I'd also add a link to "use a blank page" which would take the user to
the wiki/wysiwyg edit mode for the home page and let him type any
content there, considering that the sheet will display this content
when present, as you say below.
Yes.
> 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
What about the edit mode when content is present? Should the sheet
redirect to wiki/wysiwyg edit mode when the content is not empty? But
then the user needs a way to 'reset' the initial/factory behaviour, as
otherwise he might not know that he needs to empty the content. > - 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?
+1
Thanks,
Marius