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