30 Jun
2014
30 Jun
'14
8:50 a.m.
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
30 Jun
30 Jun
9:45 a.m.
On Mon, Jun 30, 2014 at 9:50 AM, vincent(a)massol.net <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.
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
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:54 a.m.
On 30 Jun 2014 at 09:45:58, Marius Dumitru Florea
(mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:
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
On Mon, Jun 30, 2014 at 9:50 AM, vincent(a)massol.net
wrote:
Yes.
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. 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
>
> Thanks
> -Vincent 
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
12:31 p.m.
+1 (with the option 2).
Guillaume
2014-06-30 11:59 GMT+02:00 Eduard Moraru <enygma2002(a)gmail.com>om>:
+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:
Here’s
wish.
when
On 30 Jun 2014 at 09:45:58, Marius Dumitru Florea (
mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com))
wrote:
> 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:
to
> - 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 point to any app.
HomePage.HomePageClass
>
> 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 > -
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. an example:
>
https://www.evernote.com/shard/s119/sh/b682040d-6a09-4cfc-b6aa-1eab4b4d8d5e…
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 >
> 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 he saves his content is displayed! (this is
achieved through the
following
portion of the script in HomePageSheet:
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
## 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. 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
the
> - 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 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?
> 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
>
> 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
4:55 p.m.
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.
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.
Thanks,
Caty
On Mon, Jun 30, 2014 at 9:50 AM, vincent(a)massol.net <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
5:36 p.m.
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 
1 Jul
1 Jul
6:32 p.m.
+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:
--
Thomas Mortagne
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
7:19 p.m.
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
<thomas.mortagne(a)xwiki.com> 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, vincent(a)massol.net <vincent(a)massol.net> wrote:
--
Thomas Mortagne
Hi Caty,
On 30 Jun 2014 at 16:56:57, Ecaterina Moraru (Valica)
(valicac@gmail.com(mailto:valicac@gmail.com)) wrote:
--
Thomas Mortagne 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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
7:28 p.m.
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
(thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) 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, vincent(a)massol.net wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi Caty,
On 30 Jun 2014 at 16:56:57, Ecaterina Moraru (Valica)
(valicac@gmail.com(mailto:valicac@gmail.com)) wrote:
--
Thomas Mortagne 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 
29 Aug
29 Aug
3:01 p.m.
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, vincent(a)massol.net <vincent(a)massol.net>
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 (thomas.mortagne(a)xwiki.com
(mailto:thomas.mortagne@xwiki.com)) wrote:
--
Thomas Mortagne
_______________________________________________
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
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, 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
--
Thomas Mortagne
27 Sep
27 Sep
11:07 a.m.
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 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
(guillaume@xwiki.com(mailto:guillaume@xwiki.com)) 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, vincent(a)massol.net
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 (thomas.mortagne(a)xwiki.com
(mailto:thomas.mortagne@xwiki.com)) wrote:
_______________________________________________
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 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, 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
--
Thomas Mortagne
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:12 a.m.
On 27 Sep 2014 at 11:07:48, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) 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
(guillaume@xwiki.com(mailto:guillaume@xwiki.com)) 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, vincent(a)massol.net
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 (thomas.mortagne(a)xwiki.com
(mailto:thomas.mortagne@xwiki.com)) wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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, 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
>
>
>
> --
> Thomas Mortagne
--
Thomas Mortagne
_______________________________________________
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
11:20 a.m.
On 27 Sep 2014 at 11:12:20, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
On 27 Sep 2014 at 11:07:48, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) 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
Forgot to mention that it also solves the Dashboard editing issue, not a small one! :)
Before:
- when you edit the home page you are in wysiwyg mode and you cannot edit the dashboard
After:
- When you click edit you have instructions and a clear link to edit the dashboard (if
that’s the page pointed to)
Thanks
-Vincent
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
(guillaume@xwiki.com(mailto:guillaume@xwiki.com)) 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, vincent(a)massol.net
> > 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 (thomas.mortagne(a)xwiki.com
> > > (mailto:thomas.mortagne@xwiki.com)) 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, 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
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thomas Mortagne
> > > >
> > > >
> > > >
> > > > --
> > > > Thomas Mortagne
> > > > _______________________________________________
> > > > 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
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
29 Sep
29 Sep
3:20 p.m.
Hi,
I just tried this app locally on XE 6.2 and it works well. I'll try to have
it installed on some projects to see what type of feedback we get.
It's missing a French translation though...
Thanks,
Guillaume
On Sat, Sep 27, 2014 at 11:20 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 27 Sep 2014 at 11:12:20, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
On 27 Sep 2014 at 11:07:48, vincent(a)massol.net (vincent(a)massol.net
(mailto:vincent@massol.net)) 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
Forgot to mention that it also solves the Dashboard editing issue, not a
small one! :)
Before:
- when you edit the home page you are in wysiwyg mode and you cannot edit
the dashboard
After:
- When you click edit you have instructions and a clear link to edit the
dashboard (if that’s the page pointed to)
Thanks
-Vincent
> 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 (guillaume(a)xwiki.com
(mailto:guillaume@xwiki.com)) 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, vincent(a)massol.net
> > 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 (
thomas.mortagne(a)xwiki.com
> > >
(mailto:thomas.mortagne@xwiki.com)) 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, 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
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thomas Mortagne
> > > >
> > > >
> > > >
> > > > --
> > > > Thomas Mortagne
> > > > _______________________________________________
> > > > 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
> _______________________________________________
> 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
7 Oct
7 Oct
12:09 p.m.
Hi,
I`ve finally caught up with this topic :)
------
So, just to throw an idea based on Thomas' suggestion for this application
to be a generic one, how about if we present it as a "Page Link
Application"? Basically it can be compared to a symlink, where for a
location (page) you specify that it points to another location (page). At
least this would work at an UI level (view mode only, to be more precise),
because at a platform level (and even in edit mode - other than inline), it
will still be an individual page, with its own content, objects and/or
class.
- To disable this "linking" we could have a button in the sheet that sets
an "enabled" field to "false". Once disabled, the sheet will always
redirect to the wiki/wysiwyg editor.
- To re-enable it once disabled, we could inject a "Link" action in the
"More actions" section that would redirect to inline edit mode. The sheet
will not redirect this time (because of a request parameter) and the user
will be able to choose the page to link to.
-- Perhaps others have a better suggestion for the "Link" action's location
or display.
Would we consider such an app interesting for other use, except the Home
Page?
------
Now back to Vincent's proposal, a minor thing I wanted to add was that I am
not fond of depending on whether the content of the page is empty or not
and I think we should just use an explicit field/switch that chooses the
behavior and present that in the UI. This way the user can preserve the
content of his homepage and switch back and forward with his referenced
document whenever he likes.
I have already looked at what Vincent has done and will see if I can add
some improvements or not, but I will probably return shortly after with a
vote for including it in platform, either as 1) an application (i.e. "Home
Page Application") distributed with the default XE that other admins can
install or not, or 2) directly as part of platform.
I guess 1) would be preferred here, right? ..since otherwise it does not
make much sense.
Thanks,
Eduard
On Mon, Sep 29, 2014 at 4:20 PM, Guillaume Lerouge <guillaume(a)xwiki.com>
wrote:
Hi,
I just tried this app locally on XE 6.2 and it works well. I'll try to have
it installed on some projects to see what type of feedback we get.
It's missing a French translation though...
Thanks,
Guillaume
On Sat, Sep 27, 2014 at 11:20 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
feature
page
was
the
save
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On 27 Sep 2014 at 11:12:20, vincent(a)massol.net (vincent(a)massol.net
(mailto:
vincent(a)massol.net)) wrote:
this
On 27 Sep 2014 at 11:07:48, vincent(a)massol.net (vincent(a)massol.net
(mailto:vincent@massol.net)) 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
feature (it is nice to have), but not
extension
> 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 (took me 1 hour to do that, would take another
hour to move it back to
platform in the future too).
http://extensions.xwiki.org/xwiki/bin/view/Extension/Home+Page+Application
>
> In any case, it’s now available at
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).
restrict
>
> 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
Forgot to mention that it also solves the Dashboard editing issue, not a
small one! :)
Before:
- when you edit the home page you are in wysiwyg mode and you cannot edit
the dashboard
After:
- When you click edit you have instructions and a clear link to edit the
dashboard (if that’s the page pointed to)
Thanks
-Vincent
> 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 the feature and allow to point only to
Application home pages or to Space
home pages.
using
>
> Thanks
> -Vincent
>
>
> On 29 Aug 2014 at 15:02:19, Guillaume Lerouge (guillaume(a)xwiki.com
(mailto:guillaume@xwiki.com)) 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, vincent(a)massol.net
> > 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 the
> > > > “Space Dashboard” template there’s no include. It generates a
home
page
wiki.
> > > 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 > >
>
> > > 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 (
thomas.mortagne(a)xwiki.com
> > > > (mailto:thomas.mortagne@xwiki.com)) wrote:
> > > >
> > > > > Actually it does not fit DocumentSheetBinding since this is
expectations
> > > > 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, 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
of how
> > > > he can
> > > > > >>> interact with pages right from the start
(Homepage).
> > > > > >>> Users might like to have this 'selection'
behavior for
other
pages
the
> > > 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 initial
I
> > > > >>> 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 > >
> 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 > >
> > >>
> > > > >> 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 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 user to
https://www.evernote.com/shard/s119/sh/b682040d-6a09-4cfc-b6aa-1eab4b4d8d5e…
> > > > >>> > 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:
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > >
> > > > > >>> >
> > > > > >>> > Here’s the content of HomePageSheet (not
finished, I
still
need to
[[$doc.getValue('reference')>>$doc.getValue('reference')]]
> > > 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
> > > > > >>> > 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'
or
> > > },
> > > > >>> > '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 WYSIWYG
> > > > mode of
> > > > > >>> > the home page he gets an empty page and he can
put
content
and
to
> > > 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 > >
> 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 > >
> 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
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thomas Mortagne
> > > >
> > > >
> > > >
> > > > --
> > > > Thomas Mortagne
> > > > _______________________________________________
> > > > 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
> _______________________________________________
> 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
5:05 p.m.
FTR Edy missed the “Simplified Home Page” thread
at http://markmail.org/message/dssvydw2sjt6vz7u
I’ve had a long discussion with Edy and I guess he’s going to send some mail gathering all
options we have.
Thanks
-Vincent
On 7 Oct 2014 at 12:10:19, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote:
Hi,
I`ve finally caught up with this topic :)
------
So, just to throw an idea based on Thomas' suggestion for this application
to be a generic one, how about if we present it as a "Page Link
Application"? Basically it can be compared to a symlink, where for a
location (page) you specify that it points to another location (page). At
least this would work at an UI level (view mode only, to be more precise),
because at a platform level (and even in edit mode - other than inline), it
will still be an individual page, with its own content, objects and/or
class.
- To disable this "linking" we could have a button in the sheet that sets
an "enabled" field to "false". Once disabled, the sheet will always
redirect to the wiki/wysiwyg editor.
- To re-enable it once disabled, we could inject a "Link" action in the
"More actions" section that would redirect to inline edit mode. The sheet
will not redirect this time (because of a request parameter) and the user
will be able to choose the page to link to.
-- Perhaps others have a better suggestion for the "Link" action's
location
or display.
Would we consider such an app interesting for other use, except the Home
Page?
------
Now back to Vincent's proposal, a minor thing I wanted to add was that I am
not fond of depending on whether the content of the page is empty or not
and I think we should just use an explicit field/switch that chooses the
behavior and present that in the UI. This way the user can preserve the
content of his homepage and switch back and forward with his referenced
document whenever he likes.
I have already looked at what Vincent has done and will see if I can add
some improvements or not, but I will probably return shortly after with a
vote for including it in platform, either as 1) an application (i.e. "Home
Page Application") distributed with the default XE that other admins can
install or not, or 2) directly as part of platform.
I guess 1) would be preferred here, right? ..since otherwise it does not
make much sense.
Thanks,
Eduard
On Mon, Sep 29, 2014 at 4:20 PM, Guillaume Lerouge
wrote:
Hi,
I just tried this app locally on XE 6.2 and it works well. I'll try to have
it installed on some projects to see what type of feedback we get.
It's missing a French translation though...
Thanks,
Guillaume
On Sat, Sep 27, 2014 at 11:20 AM, vincent(a)massol.net
wrote:
feature
page
was
the
save
_______________________________________________
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
On 27 Sep 2014 at 11:12:20, vincent(a)massol.net (vincent(a)massol.net
(mailto:
vincent(a)massol.net)) wrote:
this
On 27 Sep 2014 at 11:07:48, vincent(a)massol.net (vincent(a)massol.net
(mailto:vincent@massol.net)) 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
feature (it is nice to have), but not
extension
> 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 (took me 1 hour to do that, would take another
hour to move it back to
platform in the future too).
http://extensions.xwiki.org/xwiki/bin/view/Extension/Home+Page+Application
>
> In any case, it’s now available at
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).
restrict
>
> 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
Forgot to mention that it also solves the Dashboard editing issue, not a
small one! :)
Before:
- when you edit the home page you are in wysiwyg mode and you cannot edit
the dashboard
After:
- When you click edit you have instructions and a clear link to edit the
dashboard (if that’s the page pointed to)
Thanks
-Vincent
> 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 the feature and allow to point only to
Application home pages or to Space
home pages.
using
>
> Thanks
> -Vincent
>
>
> On 29 Aug 2014 at 15:02:19, Guillaume Lerouge (guillaume(a)xwiki.com
(mailto:guillaume@xwiki.com)) 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, vincent(a)massol.net
> > 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 the
> > > > “Space Dashboard” template there’s no include. It generates a
home
page
wiki.
> > > 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 > >
>
> > > 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 (
thomas.mortagne(a)xwiki.com
> > > > (mailto:thomas.mortagne@xwiki.com)) wrote:
> > > >
> > > > > Actually it does not fit DocumentSheetBinding since this is
expectations
> > > > 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, 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
of how
> > > > he can
> > > > > >>> interact with pages right from the start
(Homepage).
> > > > > >>> Users might like to have this 'selection'
behavior for
other
pages
the
> > > 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 initial
I
> > > > >>> 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 > >
> 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 > >
> > >>
> > > > >> 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 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 user to
https://www.evernote.com/shard/s119/sh/b682040d-6a09-4cfc-b6aa-1eab4b4d8d5e…
> > > > >>> > 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:
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > >
> > > > > >>> >
> > > > > >>> > Here’s the content of HomePageSheet (not
finished, I
still
need to
[[$doc.getValue('reference')>>$doc.getValue('reference')]]
> > > 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
> > > > > >>> > 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'
or
> > > },
> > > > >>> > '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 WYSIWYG
> > > > mode of
> > > > > >>> > the home page he gets an empty page and he can
put
content
and
to
> > > 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 > >
> 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 > >
> 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
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thomas Mortagne
> > > >
> > > >
> > > >
> > > > --
> > > > Thomas Mortagne
> > > > _______________________________________________
> > > > 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
> _______________________________________________
> 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
3685
days inactive
3784
days old
16 comments
7 participants
participants (7)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Guillaume Lerouge -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net