Hi Denis, I had failed to add the 6th use case (about flavors and overriding the homepage) when I moved the content to design.xwiki.org Thanks for noticing it and taking the time to read everything, Eduard On Wed, Oct 8, 2014 at 5:03 PM, Denis Gervalle <[email protected]> wrote:

Hi Edouard,

I have started reading those proposals, and I am puzzled since the proposals does not seems fully in relation with the UC described. Proposals talk about UC1 to UC6 while only UC1 to UC5 are described. Regards,

On Wed, Oct 8, 2014 at 3:48 PM, Eduard Moraru <[email protected]> wrote:

...

Hi devs,

We have already had some discussions recently on how we can improve XWiki's homepage.

After talking to Vincent in private, we have decided to come up with a set of use cases/goals[1] that we want to have/achieve with the improvement of the homepage so that we make sure that we all speak the same language and consider all use cases when proposing something.

On the same page as the use cases[1], you have a link below for the existing proposals[2] and each proposal that was discussed until now (I added one too) is listed and compared to the use cases it had to cover.

Please have a look and tell us what you think about the use cases and the analysis of each proposal.

This is not yet a vote, but just an attempt to get everybody on the same boat in terms of expectations.

Thanks, Eduard

---------- [1] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageUseCases [2] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi. = Proposal 1 = Still too technical IMO. The first time you edit a page, you edit either the Sandbox or the Main page. When you do it, you expect to learn once for all how to edit a page. But what happens: you are not editing a page but using the Dashboard application. Even worse: you are not using the dashboard macro, you are including it via a macro and you cannot change it directly in the WYSWYG editor. Conclusion: too much concepts to learn and nothing feels "natural". We are far far away from the "iPhone experience" where everything feels so natural: start an application, scroll inside a window, resize an image... I think the natural way to discover a wiki is (in this order): 1 - Learn to edit a page 2 - Then learn what is a space and a wiki 3 - Discover the other content (ie: navigation) 4 - Learn how to use the other applications 5 - Customize the home page Moving from one step to the other should be easy. That is how I expect a wiki to work, and this was basically the first things I have done when I have started XWiki the first time (+ going to the administration to discover all the options). = Proposal 2 = It is a bit like a workaround. Everything is complex but we offer an helper to easily replace the content of the home page. It does not fix the problem we have with the dashboard application or the wysiwyg editor, but it is a bit less terrible that what we have today. = Proposal 3 = To me it is the best option. A very simple page (KISS) that explains what the wiki is, and that the user is not afraid to edit (like the Sandbox) even if we should encourage the user to use the sandbox to do her tests. The user could still go to the dashboard application to enjoy all its features, and it could make it more clear that the Dashboard is a special application with a special editing : it is on its own space and we discover it after having learnt how to do basic stuffs. It does not fix all the use cases though. = Proposal 4 = Retro-compatibility issue but I like it + a button on every page "set me as the main page" (like the "fork me on github" buttons). But this proposal is not enough. = Proposal 5 = I like it. Even if I don't like the wizards in general, I think it is still the best option regarding the complexity of XWiki. = Conclusion = To me the solution is a mix of P3, P4 and P5. Of course P1 should be fixed too, but it is not the priority to make XWiki easier to use. Thanks, Guillaume

Hello. I have again a new argument against using the dashboard and the include macro in the main page. When the user uses the "Inline" editor to change some gadgets, she can not use the rollback action of the main page to cancel her changes. She has to go to the Dashboard page first, and then rollback her changes from there. Having an include macro in the default page is absolutely not intuitive, even if you make it appears more clearly. Thanks, Guillaume

Hi, On 24 Oct 2014 at 21:18:31, Eduard Moraru ([email protected](mailto:[email protected])) wrote:

Hi,

2 new proposals (P6 and P7) have been made recently. I did not yet get the chance to add comments/analysis on them. Feel free to do it in the meanwhile if anybody wants to.

A few notes on Jeremie's "Proposal7: DistrbutionWizard sets the homepage of a flavor and the Help App teaches users" [2]:

Personally, I find it a rather elegant solution based on separation of concerns. However, you need to be aware that it is a medium/long term objective.

The way I understood it is that we delegate the task of choosing a homepage to the DistributionWizard that will most likely be in charge of offering the user flavor options. At that point, the homepage of the current wiki will be the homepage of the user selected flavor. Optionally, we can also propose to use a blank page as homepage if the user wants, however this might be a bit of an overkill, since the user can easily edit the page and trash everything.

The DW should not know at all about any page. It should be up to the flavor to define the wiki pages it will contain and install. Each flavor should propose its own home page. BTW there’s also another variation for the home page that hasn’t been discussed yet: * Make the home page special by not making it editable (and without any docextra tabs at the bottom). So no rollback issue/edit weirdness. * Only admins can change it and only through the Admin UI (basically decide which space home page to display on the wiki home page). * Somewhere in the content of the default home page or through the first time wizard, direct the users to the Sandbox page to try it out editing (since this is what Sandbox is for!) Thanks -Vincent

The task of teaching the user is delegated exclusively to the Help Application, with the note that the application will also be proposed to the user to be redirected to, as a final step in the DW (after the installation of the user selected flavor is complete).

All of this assumes that we have a properly working Flavors feature and Help Application. However, what should we do in the meanwhile for the default XWiki Enterprise UI / Flavor / build? Should we postpone yet again any work on the homepage until we have the needed elements to delegate the problematic aspects, or should we do something about it in the meanwhile?

Thanks, Eduard

---------- [1] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals [2] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbution...

On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

Hello.

I have again a new argument against using the dashboard and the include macro in the main page.

When the user uses the "Inline" editor to change some gadgets, she can not use the rollback action of the main page to cancel her changes. She has to go to the Dashboard page first, and then rollback her changes from there.

Having an include macro in the default page is absolutely not intuitive, even if you make it appears more clearly.

Thanks, Guillaume _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, Le 28 oct. 2014 19:39, "Eduard Moraru" <[email protected]> a écrit :

Hi Vincent,

On Mon, Oct 27, 2014 at 11:05 AM, [email protected] <[email protected]> wrote:

...

Hi,

On 24 Oct 2014 at 21:18:31, Eduard Moraru ([email protected](mailto: [email protected])) wrote:

...

Hi,

2 new proposals (P6 and P7) have been made recently. I did not yet get the chance to add comments/analysis on them. Feel free to do it in the meanwhile if anybody wants to.

A few notes on Jeremie's "Proposal7: DistrbutionWizard sets the

homepage

...

of

...

a flavor and the Help App teaches users" [2]:

Personally, I find it a rather elegant solution based on separation of concerns. However, you need to be aware that it is a medium/long term objective.

The way I understood it is that we delegate the task of choosing a homepage to the DistributionWizard that will most likely be in charge of offering the user flavor options. At that point, the homepage of the current wiki will be the homepage of the user selected flavor. Optionally, we can also propose to use a blank page as homepage if the user wants, however this might be a bit of an overkill, since the user can easily edit the page and trash everything.

The DW should not know at all about any page. It should be up to the flavor to define the wiki pages it will contain and install. Each flavor should propose its own home page.

Maybe I did not choose the best words, but the way I understood it (and tried to reformulate it) was not that the DW explicitly allows you to select a homepage, but that indirectly, through allowing you to install a flavor, it will additionally do the job (again, indirectly) of making you choose a homepage (through the flavor you have selected).

Yes that was the idea, possibly: - DW doesn't have to know pages or set homepage - there could be a new wizard, similar to wizards for new page / space from template, that allows choosing a kind of homepage (empty, wiki concepts, dashboard, etc) - a flavor also adds its homepage as a possible "template" - btw it could be exactly the new space from template page, but with more choices than current (empty / dashboard) - following a dw run and a flavor installation, this "new Main space homepage from template" wizard is triggered and displayed (or just proposed to user through a button or link), and allows user to either choose default homepage of the flavor, or use another one - current (or reworked) homepage is just the default home of the default flavor (which is the current XE xar) Maybe instead of all this, it could be enough to unrelate the "new space" and "apply space homepage template" features ? So I would just have to call "space / apply template" to replace the homepage of any space already existing (including Main obviously) ?

It was just a high level view on the direction to follow, and not a specific technical aspect, so no reason to -1 it, right?

...

BTW there’s also another variation for the home page that hasn’t been discussed yet: * Make the home page special by not making it editable (and without any docextra tabs at the bottom). So no rollback issue/edit weirdness. * Only admins can change it and only through the Admin UI (basically decide which space home page to display on the wiki home page). * Somewhere in the content of the default home page or through the first time wizard, direct the users to the Sandbox page to try it out editing (since this is what Sandbox is for!)

Adding this too and I think we`re good for going forward with a vote,

since

we have plenty of proposals.

Thanks, Eduard

...

Thanks -Vincent

...

The task of teaching the user is delegated exclusively to the Help Application, with the note that the application will also be proposed

to

...

...

the user to be redirected to, as a final step in the DW (after the installation of the user selected flavor is complete).

All of this assumes that we have a properly working Flavors feature and Help Application. However, what should we do in the meanwhile for the default XWiki Enterprise UI / Flavor / build? Should we postpone yet again any work on the homepage until we have the needed elements to delegate the problematic aspects, or should we do something about it in the meanwhile?

Thanks, Eduard

---------- [1] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals [2]

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbution...

...

...

On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

Hello.

I have again a new argument against using the dashboard and the

include

...

...

macro in the main page.

When the user uses the "Inline" editor to change some gadgets, she can not use the rollback action of the main page to cancel her changes. She has to go to the Dashboard page first, and then rollback her changes from there.

Having an include macro in the default page is absolutely not intuitive, even if you make it appears more clearly.

Thanks, Guillaume _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, 2014-10-28 21:08 GMT+01:00 [email protected] <[email protected]>:

On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET ([email protected] (mailto:[email protected])) wrote:

...

Hi, Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :

...

Hi Vincent,

On Mon, Oct 27, 2014 at 11:05 AM, [email protected] wrote:

...

Hi,

On 24 Oct 2014 at 21:18:31, Eduard Moraru ([email protected]

(mailto:

...

...

[email protected])) wrote:

...

Hi,

2 new proposals (P6 and P7) have been made recently. I did not yet get the chance to add comments/analysis on them. Feel free to do it in the meanwhile if anybody wants to.

A few notes on Jeremie's "Proposal7: DistrbutionWizard sets the homepage of a flavor and the Help App teaches users" [2]:

Personally, I find it a rather elegant solution based on separation of concerns. However, you need to be aware that it is a medium/long term objective.

The way I understood it is that we delegate the task of choosing a homepage to the DistributionWizard that will most likely be in charge of offering the user flavor options. At that point, the homepage of the current wiki will be the homepage of the user selected flavor. Optionally, we can also propose to use a blank page as homepage if the user wants, however this might be a bit of an overkill, since the user can easily edit the page and trash everything.

The DW should not know at all about any page. It should be up to the flavor to define the wiki pages it will contain and install. Each flavor should propose its own home page.

Maybe I did not choose the best words, but the way I understood it (and tried to reformulate it) was not that the DW explicitly allows you to select a homepage, but that indirectly, through allowing you to install a flavor, it will additionally do the job (again, indirectly) of making you choose a homepage (through the flavor you have selected).

Yes that was the idea, possibly: - DW doesn't have to know pages or set homepage - there could be a new wizard, similar to wizards for new page / space from template, that allows choosing a kind of homepage (empty, wiki concepts, dashboard, etc) - a flavor also adds its homepage as a possible "template" - btw it could be exactly the new space from template page, but with more choices than current (empty / dashboard) - following a dw run and a flavor installation, this "new Main space homepage from template" wizard is triggered and displayed (or just proposed to user through a button or link), and allows user to either choose default homepage of the flavor, or use another one - current (or reworked) homepage is just the default home of the default flavor (which is the current XE xar)

ok but:

1) it’s complex since it means that a flavor would need to register some kind of post install script to execute (which is something we don’t really have)

Depends, I was thinking more about a specific event like "flavor installed" or "extension installed" or "wiki installed / updated". I'm not sure to get what you would need to do in this post install script ? But it could be completely "manual" or just a link at the end of DW to some possible post-install stuff (like, consult help, manage home page, etc). I'd like to apologize here because my "proposal" was more an idea than a well formalized proposal, even if it ended up in the list of proposals, it's obvious that it misses some thoughts and clarifications... (I understand your -1).

2) it negates a bit the point of a flavor which is to propose a defined “theme” and thus a defined home page matching that theme

Well, if you consider that current UI of XE is the default xwiki "flavor", this is exactly what it's about when we talk about switching home page easily, isn't it ? We want to let user set a home page that doesn't match the default theme freely. Obviously this default theme is not very "thematic" as it's the default and should be versatile ... Home page matching that theme could still be the mostly recommended choice. BTW a flavor, with such mechanism, could provide several "home page" variants and not only one, depending on the case. If I take the case of a flavor based on the Mail archive (or the mail archive extension alone, say), it already provides different views as the app home page (timeline, livetable, etc). Currently the switch is done through conditional include. Currently that app home page is MailArchive.WebHome, if I could register it as a possible home page template, it would avoid having to rename it "Main.WebHome" to make it a flavor (and potentially destroy existing wiki home page by mistake when you install that extension/flavor), and I could fullfill both installation use-cases (of using it as an app among others in some wiki, and as a wiki-wide-flavor in another wiki or subwiki), from the same xar bundled app. Again, here, I talk about possibilities and use-cases that seem logical or interesting to me if I dig into my proposal, but I really don't know if it's a good path or even a good idea for xwiki - I may not have the big picture :) Also, the proposal certainly does not offer any solution for short-term (if you consider it provides options for long-term ;-) )

3) it doesn’t solve anything since once you select a default homepage you still need a way to change it afterwards if you want to change it…

There was the side-idea of the proposal (not well formulated, maybe was just in my mind) that this wizard and/or DW could be triggered at any later time by an admin if he wants to replace homepage with some other "default" content. Maybe could be seen as a "personalization" step following a new wiki install or upgrade, but that could be triggered at any later time to "re-personalize" his wiki. I would put this then also as a feature in admin UI. The difference with some other proposals, is that it would not be an action available from the standard UI but limited to a post-install step and the admin UI (not like the variant below).

I don’t see how this is much better than having a Admin UI allowing you to change the home page you wish to have. However it’s a lot more complex (and really marginally better).

...

Maybe instead of all this, it could be enough to unrelate the "new space" and "apply space homepage template" features ? So I would just have to call "space / apply template" to replace the homepage of any space already existing (including Main obviously) ?

Yes that’s better already IMO but then it should be a menu option to replace any page content with a page template.

I'm not sure if you talk about an additional option, or an option that would replace the "space /apply template" by a more generic "page / apply template", but I don't think anyway that a page template is the same thing as a home page template (whether it's a space or wiki home page). You'd seldom want to use a blog post as a home page ... In this variant, there's still the question, if applying such template is considered an admin operation or not. If it's an admin operation, you also proposed to start moving those admin actions to the admin UI, which is - sort of - what was my proposal about in first place :) (I didn't talk specifically about admin UI at that time, but about avoiding to crowd standard UI menus with unfrequent/admin operations). That being said I don't think it's an admin action, if you need to protect home page, as an admin you can set specific rights and forbid this "apply template" to people that don't have those edit rights. I'm not sure editing home page and applying a template should really be different in terms of privileges. But applying a template on an existing page or home page, seems to be a rather unfrequent operation.

Thanks -Vincent

...

...

It was just a high level view on the direction to follow, and not a specific technical aspect, so no reason to -1 it, right?

...

BTW there’s also another variation for the home page that hasn’t been discussed yet: * Make the home page special by not making it editable (and without any docextra tabs at the bottom). So no rollback issue/edit weirdness. * Only admins can change it and only through the Admin UI (basically decide which space home page to display on the wiki home page). * Somewhere in the content of the default home page or through the first time wizard, direct the users to the Sandbox page to try it out editing (since this is what Sandbox is for!)

Adding this too and I think we`re good for going forward with a vote, since we have plenty of proposals.

Thanks, Eduard

...

Thanks -Vincent

...

The task of teaching the user is delegated exclusively to the Help Application, with the note that the application will also be

proposed to

...

...

the user to be redirected to, as a final step in the DW (after the installation of the user selected flavor is complete).

All of this assumes that we have a properly working Flavors feature and Help Application. However, what should we do in the meanwhile for the default XWiki Enterprise UI / Flavor / build? Should we postpone yet again any work on the homepage until we have the needed elements to delegate the problematic aspects, or should we do something about it in the meanwhile?

Thanks, Eduard

---------- [1] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals [2]

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbution...

...

...

...

...

On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie"

Delhumeau <

...

[email protected]> wrote:

...

Hello.

I have again a new argument against using the dashboard and the include macro in the main page.

When the user uses the "Inline" editor to change some gadgets, she can not use the rollback action of the main page to cancel her changes. She has to go to the Dashboard page first, and then rollback her changes from there.

Having an include macro in the default page is absolutely not intuitive, even if you make it appears more clearly.

Thanks, Guillaume

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

2014-11-05 14:43 GMT+01:00 Eduard Moraru <[email protected]>:

Concerning UC3 and UC4, we should not re-invent the wheel. I have just remembered about the fact that we already have the option of setting the homepage of a wiki exposed in the wiki's descriptor, so this makes is already configurable.

All we need to do now, is to expose this configuration further, in Administration > Configuration, under Wiki section (just like it was for workspaces, no idea why we removed it when refactoring to 'wikis'),

About this setting in particular it is because it is part of the wiki descriptor, and we now have only one place to edit these properties.

where you can select what is the homepage of your current wiki. Selecting the owner and basically all the other stuff that you have in a wiki descriptor should be done at this same level, since these are very important configurations that one needs to perform for either his main wiki or subwiki.

And no, the xwiki-platform-wiki module is not optional (it is part of the wiki model!), so no point in using a configurable class and throwing it back in the 'Applications' section.

This actually goes along the lines of 'Proposal4: Set this page as homepage' [1], but done in Administration, not on every page, like Vincent suggested.

To get the homepage, apps need to do: $services.wiki.getById($services.wiki.currentWikiId).mainPageReference Of course, this can be improved to $services.wiki.currentWikiDescriptor.mainPageReference

We will be still having the backwards compatibility concerns of P4, however I am sure that practical solutions (e.g. making Main.WebHome redirect to $services.wiki.getById($services.wiki.currentWikiId).mainPageReference, etc.) can be found if problems arise in daily use.

WDYT?

---------- [1]

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal4Setthispage...

On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET < [email protected]> wrote:

...

Hi,

2014-10-28 21:08 GMT+01:00 [email protected] <[email protected]>:

...

On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (

[email protected]

...

(mailto:[email protected])) wrote:

...

Hi, Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :

...

Hi Vincent,

On Mon, Oct 27, 2014 at 11:05 AM, [email protected] wrote:

...

Hi,

On 24 Oct 2014 at 21:18:31, Eduard Moraru ([email protected]

(mailto:

...

...

[email protected])) wrote:

> Hi, > > 2 new proposals (P6 and P7) have been made recently. I did not yet get the > chance to add comments/analysis on them. Feel free to do it in the > meanwhile if anybody wants to. > > A few notes on Jeremie's "Proposal7: DistrbutionWizard sets the homepage of > a flavor and the Help App teaches users" [2]: > > Personally, I find it a rather elegant solution based on separation of > concerns. However, you need to be aware that it is a medium/long term > objective. > > The way I understood it is that we delegate the task of choosing a homepage > to the DistributionWizard that will most likely be in charge of offering > the user flavor options. At that point, the homepage of the current wiki > will be the homepage of the user selected flavor. Optionally, we can also > propose to use a blank page as homepage if the user wants, however this > might be a bit of an overkill, since the user can easily edit the page and > trash everything.

The DW should not know at all about any page. It should be up to the flavor to define the wiki pages it will contain and install. Each flavor should propose its own home page.

Maybe I did not choose the best words, but the way I understood it (and tried to reformulate it) was not that the DW explicitly allows you to select a homepage, but that indirectly, through allowing you to install a flavor, it will additionally do the job (again, indirectly) of making you choose a homepage (through the flavor you have selected).

Yes that was the idea, possibly: - DW doesn't have to know pages or set homepage - there could be a new wizard, similar to wizards for new page / space from template, that allows choosing a kind of homepage (empty, wiki concepts, dashboard, etc) - a flavor also adds its homepage as a possible "template" - btw it could be exactly the new space from template page, but with more choices than current (empty / dashboard) - following a dw run and a flavor installation, this "new Main space homepage from template" wizard is triggered and displayed (or just proposed to user through a button or link), and allows user to either choose default homepage of the flavor, or use another one - current (or reworked) homepage is just the default home of the default flavor (which is the current XE xar)

ok but:

1) it’s complex since it means that a flavor would need to register some kind of post install script to execute (which is something we don’t really have)

Depends, I was thinking more about a specific event like "flavor installed" or "extension installed" or "wiki installed / updated". I'm not sure to get what you would need to do in this post install script ? But it could be completely "manual" or just a link at the end of DW to some possible post-install stuff (like, consult help, manage home page, etc).

I'd like to apologize here because my "proposal" was more an idea than a well formalized proposal, even if it ended up in the list of proposals, it's obvious that it misses some thoughts and clarifications... (I understand your -1).

...

2) it negates a bit the point of a flavor which is to propose a defined “theme” and thus a defined home page matching that theme

Well, if you consider that current UI of XE is the default xwiki "flavor", this is exactly what it's about when we talk about switching home page easily, isn't it ? We want to let user set a home page that doesn't match the default theme freely. Obviously this default theme is not very "thematic" as it's the default and should be versatile ... Home page matching that theme could still be the mostly recommended choice. BTW a flavor, with such mechanism, could provide several "home page" variants and not only one, depending on the case. If I take the case of a flavor based on the Mail archive (or the mail archive extension alone, say), it already provides different views as the app home page (timeline, livetable, etc). Currently the switch is done through conditional include. Currently that app home page is MailArchive.WebHome, if I could register it as a possible home page template, it would avoid having to rename it "Main.WebHome" to make it a flavor (and potentially destroy existing wiki home page by mistake when you install that extension/flavor), and I could fullfill both installation use-cases (of using it as an app among others in some wiki, and as a wiki-wide-flavor in another wiki or subwiki), from the same xar bundled app. Again, here, I talk about possibilities and use-cases that seem logical or interesting to me if I dig into my proposal, but I really don't know if it's a good path or even a good idea for xwiki - I may not have the big picture :) Also, the proposal certainly does not offer any solution for short-term (if you consider it provides options for long-term ;-) )

...

3) it doesn’t solve anything since once you select a default homepage you still need a way to change it afterwards if you want to change it…

There was the side-idea of the proposal (not well formulated, maybe was just in my mind) that this wizard and/or DW could be triggered at any later time by an admin if he wants to replace homepage with some other "default" content. Maybe could be seen as a "personalization" step following a new wiki install or upgrade, but that could be triggered at any later time to "re-personalize" his wiki. I would put this then also as a feature in admin UI. The difference with some other proposals, is that it would not be an action available from the standard UI but limited to a post-install step and the admin UI (not like the variant below).

...

I don’t see how this is much better than having a Admin UI allowing you

to

...

change the home page you wish to have. However it’s a lot more complex (and really marginally better).

...

Maybe instead of all this, it could be enough to unrelate the "new space" and "apply space homepage template" features ? So I would just have to call "space / apply template" to replace the homepage of any space already existing (including Main obviously) ?

Yes that’s better already IMO but then it should be a menu option to replace any page content with a page template.

I'm not sure if you talk about an additional option, or an option that would replace the "space /apply template" by a more generic "page / apply template", but I don't think anyway that a page template is the same thing as a home page template (whether it's a space or wiki home page). You'd seldom want to use a blog post as a home page ...

In this variant, there's still the question, if applying such template is considered an admin operation or not. If it's an admin operation, you also proposed to start moving those admin actions to the admin UI, which is - sort of - what was my proposal about in first place :) (I didn't talk specifically about admin UI at that time, but about avoiding to crowd standard UI menus with unfrequent/admin operations). That being said I don't think it's an admin action, if you need to protect home page, as an admin you can set specific rights and forbid this "apply template" to people that don't have those edit rights. I'm not sure editing home page and applying a template should really be different in terms of privileges. But applying a template on an existing page or home page, seems to be a rather unfrequent operation.

...

Thanks -Vincent

...

...

It was just a high level view on the direction to follow, and not a specific technical aspect, so no reason to -1 it, right?

...

BTW there’s also another variation for the home page that hasn’t

been

...

...

...

...

discussed yet: * Make the home page special by not making it editable (and without any docextra tabs at the bottom). So no rollback issue/edit weirdness. * Only admins can change it and only through the Admin UI (basically decide which space home page to display on the wiki home page). * Somewhere in the content of the default home page or through the first time wizard, direct the users to the Sandbox page to try it out editing (since this is what Sandbox is for!)

Adding this too and I think we`re good for going forward with a vote, since we have plenty of proposals.

Thanks, Eduard

...

Thanks -Vincent

> The task of teaching the user is delegated exclusively to the

Help

...

> Application, with the note that the application will also be proposed to > the user to be redirected to, as a final step in the DW (after the > installation of the user selected flavor is complete). > > All of this assumes that we have a properly working Flavors feature and > Help Application. However, what should we do in the meanwhile for the > default XWiki Enterprise UI / Flavor / build? Should we postpone yet again > any work on the homepage until we have the needed elements to delegate the > problematic aspects, or should we do something about it in the meanwhile? > > Thanks, > Eduard > > ---------- > [1] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals > [2] >

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbution...

...

...

...

...

...

> > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" Delhumeau < > [email protected]> wrote: > > > Hello. > > > > I have again a new argument against using the dashboard and the include > > macro in the main page. > > > > When the user uses the "Inline" editor to change some gadgets, she can not > > use the rollback action of the main page to cancel her changes. She has to > > go to the Dashboard page first, and then rollback her changes from there. > > > > Having an include macro in the default page is absolutely not intuitive, > > even if you make it appears more clearly. > > > > Thanks, > > Guillaume

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru <[email protected]> wrote:

The problem with the current place is that it is not really natural and thus not very discoverable at all.

I have this feeling to. I wanted to edit the descriptor of a subwiki a few days ago and I was surprised I could find anything related in the subwiki administration.

If you have to set the homepage, owner, etc of your wiki, you go to administration, but never to "wiki index > edit wiki".

I believe that along this thread we have identified that these settings are valuable for both the main wiki and subwikis so this makes editing the wiki descriptor a valuable and deserving section to be introduced in administration, don`t you agree?

Thanks, Eduard

On Wed, Nov 5, 2014 at 4:38 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2014-11-05 14:43 GMT+01:00 Eduard Moraru <[email protected]>:

...

Concerning UC3 and UC4, we should not re-invent the wheel. I have just remembered about the fact that we already have the option of setting the homepage of a wiki exposed in the wiki's descriptor, so this makes is already configurable.

All we need to do now, is to expose this configuration further, in Administration > Configuration, under Wiki section (just like it was for workspaces, no idea why we removed it when refactoring to 'wikis'),

About this setting in particular it is because it is part of the wiki descriptor, and we now have only one place to edit these properties.

...

where you can select what is the homepage of your current wiki. Selecting the owner and basically all the other stuff that you have in a wiki descriptor should be done at this same level, since these are very important configurations that one needs to perform for either his main wiki or subwiki.

And no, the xwiki-platform-wiki module is not optional (it is part of the wiki model!), so no point in using a configurable class and throwing it back in the 'Applications' section.

This actually goes along the lines of 'Proposal4: Set this page as homepage' [1], but done in Administration, not on every page, like Vincent suggested.

To get the homepage, apps need to do: $services.wiki.getById($services.wiki.currentWikiId).mainPageReference Of course, this can be improved to $services.wiki.currentWikiDescriptor.mainPageReference

We will be still having the backwards compatibility concerns of P4, however I am sure that practical solutions (e.g. making Main.WebHome redirect to $services.wiki.getById($services.wiki.currentWikiId).mainPageReference, etc.) can be found if problems arise in daily use.

WDYT?

---------- [1]

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal4Setthispage...

...

On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET < [email protected]> wrote:

...

Hi,

2014-10-28 21:08 GMT+01:00 [email protected] <[email protected]>:

...

On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (

[email protected]

...

(mailto:[email protected])) wrote:

...

Hi, Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit : > > Hi Vincent, > > On Mon, Oct 27, 2014 at 11:05 AM, [email protected] > wrote: > > > Hi, > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru (

...

...

...

(mailto:

...

> > [email protected])) wrote: > > > > > Hi, > > > > > > 2 new proposals (P6 and P7) have been made recently. I did not yet get > > the > > > chance to add comments/analysis on them. Feel free to do it in the > > > meanwhile if anybody wants to. > > > > > > A few notes on Jeremie's "Proposal7: DistrbutionWizard sets the homepage > > of > > > a flavor and the Help App teaches users" [2]: > > > > > > Personally, I find it a rather elegant solution based on separation of > > > concerns. However, you need to be aware that it is a medium/long term > > > objective. > > > > > > The way I understood it is that we delegate the task of choosing a > > homepage > > > to the DistributionWizard that will most likely be in charge of offering > > > the user flavor options. At that point, the homepage of the current wiki > > > will be the homepage of the user selected flavor. Optionally, we can also > > > propose to use a blank page as homepage if the user wants, however this > > > might be a bit of an overkill, since the user can easily edit the page > > and > > > trash everything. > > > > The DW should not know at all about any page. It should be up to the > > flavor to define the wiki pages it will contain and install. Each flavor > > should propose its own home page. > > > > Maybe I did not choose the best words, but the way I understood it (and > tried to reformulate it) was not that the DW explicitly allows you to > select a homepage, but that indirectly, through allowing you to install a > flavor, it will additionally do the job (again, indirectly) of making you > choose a homepage (through the flavor you have selected).

Yes that was the idea, possibly: - DW doesn't have to know pages or set homepage - there could be a new wizard, similar to wizards for new page / space from template, that allows choosing a kind of homepage (empty, wiki concepts, dashboard, etc) - a flavor also adds its homepage as a possible "template" - btw it could be exactly the new space from template page, but with more choices than current (empty / dashboard) - following a dw run and a flavor installation, this "new Main space homepage from template" wizard is triggered and displayed (or just proposed to user through a button or link), and allows user to either choose default homepage of the flavor, or use another one - current (or reworked) homepage is just the default home of the default flavor (which is the current XE xar)

ok but:

1) it’s complex since it means that a flavor would need to register some kind of post install script to execute (which is something we don’t really have)

Depends, I was thinking more about a specific event like "flavor installed" or "extension installed" or "wiki installed / updated". I'm not sure to get what you would need to do in this post install script ? But it could be completely "manual" or just a link at the end of DW to some possible post-install stuff (like, consult help, manage home page, etc).

I'd like to apologize here because my "proposal" was more an idea than a well formalized proposal, even if it ended up in the list of proposals, it's obvious that it misses some thoughts and clarifications... (I understand your -1).

...

2) it negates a bit the point of a flavor which is to propose a defined “theme” and thus a defined home page matching that theme

Well, if you consider that current UI of XE is the default xwiki "flavor", this is exactly what it's about when we talk about switching home page easily, isn't it ? We want to let user set a home page that doesn't match the default theme freely. Obviously this default theme is not very "thematic" as it's the default and should be versatile ... Home page matching that theme could still be the mostly recommended choice. BTW a flavor, with such mechanism, could provide several "home page" variants and not only one, depending on the case. If I take the case of a flavor based on the Mail archive (or the mail archive extension alone, say), it already provides different views as the app home page (timeline, livetable, etc). Currently the switch is done through conditional include. Currently that app home page is MailArchive.WebHome, if I could register it as a possible home page template, it would avoid having to rename it "Main.WebHome" to make it a flavor (and potentially destroy existing wiki home page by mistake when you install that extension/flavor), and I could fullfill both installation use-cases (of using it as an app among others in some wiki, and as a wiki-wide-flavor in another wiki or subwiki), from the same xar bundled app. Again, here, I talk about possibilities and use-cases that seem logical or interesting to me if I dig into my proposal, but I really don't know if it's a good path or even a good idea for xwiki - I may not have the big picture :) Also, the proposal certainly does not offer any solution for short-term (if you consider it provides options for long-term ;-) )

...

3) it doesn’t solve anything since once you select a default homepage you still need a way to change it afterwards if you want to change it…

There was the side-idea of the proposal (not well formulated, maybe was just in my mind) that this wizard and/or DW could be triggered at any later time by an admin if he wants to replace homepage with some other "default" content. Maybe could be seen as a "personalization" step following a new wiki install or upgrade, but that could be triggered at any later time to "re-personalize" his wiki. I would put this then also as a feature in admin UI. The difference with some other proposals, is that it would not be an action available from the standard UI but limited to a post-install step and the admin UI (not like the variant below).

...

I don’t see how this is much better than having a Admin UI allowing

you to

...

change the home page you wish to have. However it’s a lot more complex (and really marginally better).

...

Maybe instead of all this, it could be enough to unrelate the "new space" and "apply space homepage template" features ? So I would just have to call "space / apply template" to replace the homepage of any space already existing (including Main obviously) ?

Yes that’s better already IMO but then it should be a menu option to replace any page content with a page template.

I'm not sure if you talk about an additional option, or an option that would replace the "space /apply template" by a more generic "page / apply template", but I don't think anyway that a page template is the same thing as a home page template (whether it's a space or wiki home page). You'd seldom want to use a blog post as a home page ...

In this variant, there's still the question, if applying such template is considered an admin operation or not. If it's an admin operation, you also proposed to start moving those admin actions to the admin UI, which is

[email protected] -

...

...

sort of - what was my proposal about in first place :) (I didn't talk specifically about admin UI at that time, but about avoiding to crowd standard UI menus with unfrequent/admin operations). That being said I don't think it's an admin action, if you need to protect home page, as an admin you can set specific rights and forbid this "apply template" to people that don't have those edit rights. I'm not sure editing home page and applying a template should really be different in terms of privileges. But applying a template on an existing page or home page, seems to be a rather unfrequent operation.

...

Thanks -Vincent

...

> It was just a high level view on the direction to follow, and

not a

...

...

> specific technical aspect, so no reason to -1 it, right? > > > > BTW there’s also another variation for the home page that hasn’t been > > discussed yet: > > * Make the home page special by not making it editable (and without any > > docextra tabs at the bottom). So no rollback issue/edit weirdness. > > * Only admins can change it and only through the Admin UI (basically > > decide which space home page to display on the wiki home page). > > * Somewhere in the content of the default home page or through the first > > time wizard, direct the users to the Sandbox page to try it out editing > > (since this is what Sandbox is for!) > > > > Adding this too and I think we`re good for going forward with a vote, since > we have plenty of proposals. > > Thanks, > Eduard > > > > > Thanks > > -Vincent > > > > > The task of teaching the user is delegated exclusively to the Help > > > Application, with the note that the application will also be proposed to > > > the user to be redirected to, as a final step in the DW (after the > > > installation of the user selected flavor is complete). > > > > > > All of this assumes that we have a properly working Flavors feature and > > > Help Application. However, what should we do in the meanwhile for the > > > default XWiki Enterprise UI / Flavor / build? Should we postpone yet > > again > > > any work on the homepage until we have the needed elements to delegate > > the > > > problematic aspects, or should we do something about it in the meanwhile? > > > > > > Thanks, > > > Eduard > > > > > > ---------- > > > [1] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals > > > [2] > > > > >

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbution...

...

...

...

...

> > > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" Delhumeau < > > > [email protected]> wrote: > > > > > > > Hello. > > > > > > > > I have again a new argument against using the dashboard and the include > > > > macro in the main page. > > > > > > > > When the user uses the "Inline" editor to change some gadgets, she can > > not > > > > use the rollback action of the main page to cancel her changes. She > > has to > > > > go to the Dashboard page first, and then rollback her changes from > > there. > > > > > > > > Having an include macro in the default page is absolutely not > > intuitive, > > > > even if you make it appears more clearly. > > > > > > > > Thanks, > > > > Guillaume

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

  On 6 Nov 2014 at 12:58:48, Guillaume Louis-Marie Delhumeau ([email protected](mailto:[email protected])) wrote:

We had this discussion one year ago with Vincent. He wanted to go in the direction where everything is an application with a proper UI and not necessary in the administration.

Some points on this to be clear: 1) Indeed for discoverability I think it's good to have application features visible in the app themselves whether it’s for end users, developers or admins. For example the fact that in the Wiki Index, you can have an “Edit Descriptor” button if you’re an admin of that wiki, or the fact that in the AllDocs livetable page, you can delete a doc if you have the permissions. Basically you see actions that you have the right to perform. 2) Regarding configuration of apps, I agree that the best place is the Administration with sections for each app. What I didn’t want to have is to force the users to be admin to be able to access applications. For example at the time the discussions were about the Scheduler app, the Statistics app just to name 2. It was proposed that they be visible/findable only from the Admin screens and that’s what I didn’t like. In the end I’ve made them visible/discoverable by listing them in the Application Panel when the user has admin rights. 3) Wiki descriptors are about configuration and I would find it normal and good to have them in the Main wiki’s administration screens too. This means they could be accesssed both from the Wiki index screen ( point 1) above) and from the Admin UI (point 2) above). Thanks -Vincent

Moreover, it is very important to be able to modify a descriptor from the main wiki instead of the subwiki, since if you break it, you might be unable to access your subwiki anymore!

2014-11-06 11:10 GMT+01:00 Marius Dumitru Florea < [email protected]>:

...

On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru wrote:

...

The problem with the current place is that it is not really natural and thus not very discoverable at all.

I have this feeling to. I wanted to edit the descriptor of a subwiki a few days ago and I was surprised I could find anything related in the subwiki administration.

...

If you have to set the homepage, owner, etc of your wiki, you go to administration, but never to "wiki index > edit wiki".

I believe that along this thread we have identified that these settings are valuable for both the main wiki and subwikis so this makes editing the wiki descriptor a valuable and deserving section to be introduced in administration, don`t you agree?

Thanks, Eduard

On Wed, Nov 5, 2014 at 4:38 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2014-11-05 14:43 GMT+01:00 Eduard Moraru :

...

Concerning UC3 and UC4, we should not re-invent the wheel. I have just remembered about the fact that we already have the option of setting the homepage of a wiki exposed in the wiki's descriptor, so this makes is already configurable.

All we need to do now, is to expose this configuration further, in Administration > Configuration, under Wiki section (just like it was for workspaces, no idea why we removed it when refactoring to 'wikis'),

About this setting in particular it is because it is part of the wiki descriptor, and we now have only one place to edit these properties.

...

where you can select what is the homepage of your current wiki. Selecting the owner and basically all the other stuff that you have in a wiki descriptor should be done at this same level, since these are very important configurations that one needs to perform for either his main wiki or subwiki.

And no, the xwiki-platform-wiki module is not optional (it is part of the wiki model!), so no point in using a configurable class and throwing it back in the 'Applications' section.

This actually goes along the lines of 'Proposal4: Set this page as homepage' [1], but done in Administration, not on every page, like Vincent suggested.

To get the homepage, apps need to do: $services.wiki.getById($services.wiki.currentWikiId).mainPageReference Of course, this can be improved to $services.wiki.currentWikiDescriptor.mainPageReference

We will be still having the backwards compatibility concerns of P4, however I am sure that practical solutions (e.g. making Main.WebHome redirect to

$services.wiki.getById($services.wiki.currentWikiId).mainPageReference,

...

etc.) can be found if problems arise in daily use.

WDYT?

---------- [1]

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal4Setthispage...

...

...

On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET < [email protected]> wrote:

...

Hi,

2014-10-28 21:08 GMT+01:00 [email protected] :

> > > > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET ( [email protected] > (mailto:[email protected])) wrote: > > > Hi, > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit : > > > > > > Hi Vincent, > > > > > > On Mon, Oct 27, 2014 at 11:05 AM, [email protected] > > > wrote: > > > > > > > Hi, > > > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru (

...

...

> (mailto: > > > > [email protected])) wrote: > > > > > > > > > Hi, > > > > > > > > > > 2 new proposals (P6 and P7) have been made recently. I did not yet > get > > > > the > > > > > chance to add comments/analysis on them. Feel free to do it in the > > > > > meanwhile if anybody wants to. > > > > > > > > > > A few notes on Jeremie's "Proposal7: DistrbutionWizard sets the > > homepage > > > > of > > > > > a flavor and the Help App teaches users" [2]: > > > > > > > > > > Personally, I find it a rather elegant solution based on > separation of > > > > > concerns. However, you need to be aware that it is a medium/long > term > > > > > objective. > > > > > > > > > > The way I understood it is that we delegate the task of choosing a > > > > homepage > > > > > to the DistributionWizard that will most likely be in charge of > > offering > > > > > the user flavor options. At that point, the homepage of the current > > wiki > > > > > will be the homepage of the user selected flavor. Optionally, we > can > > also > > > > > propose to use a blank page as homepage if the user wants, however > > this > > > > > might be a bit of an overkill, since the user can easily edit the > page > > > > and > > > > > trash everything. > > > > > > > > The DW should not know at all about any page. It should be up to the > > > > flavor to define the wiki pages it will contain and install. Each > flavor > > > > should propose its own home page. > > > > > > > > > > Maybe I did not choose the best words, but the way I understood it (and > > > tried to reformulate it) was not that the DW explicitly allows you to > > > select a homepage, but that indirectly, through allowing you to > install a > > > flavor, it will additionally do the job (again, indirectly) of making > you > > > choose a homepage (through the flavor you have selected). > > > > Yes that was the idea, possibly: > > - DW doesn't have to know pages or set homepage > > - there could be a new wizard, similar to wizards for new page / space > from > > template, that allows choosing a kind of homepage (empty, wiki concepts, > > dashboard, etc) > > - a flavor also adds its homepage as a possible "template" > > - btw it could be exactly the new space from template page, but with more > > choices than current (empty / dashboard) > > - following a dw run and a flavor installation, this "new Main space > > homepage from template" wizard is triggered and displayed (or just > proposed > > to user through a button or link), and allows user to either choose > default > > homepage of the flavor, or use another one > > - current (or reworked) homepage is just the default home of the default > > flavor (which is the current XE xar) > > ok but: > > 1) it’s complex since it means that a flavor would need to register some > kind of post install script to execute (which is something we don’t really > have) >

Depends, I was thinking more about a specific event like "flavor installed" or "extension installed" or "wiki installed / updated". I'm not sure to get what you would need to do in this post install script ? But it could be completely "manual" or just a link at the end of DW to some possible post-install stuff (like, consult help, manage home page, etc).

I'd like to apologize here because my "proposal" was more an idea than a well formalized proposal, even if it ended up in the list of proposals, it's obvious that it misses some thoughts and clarifications... (I understand your -1).

> 2) it negates a bit the point of a flavor which is to propose a defined > “theme” and thus a defined home page matching that theme >

Well, if you consider that current UI of XE is the default xwiki "flavor", this is exactly what it's about when we talk about switching home page easily, isn't it ? We want to let user set a home page that doesn't match the default theme freely. Obviously this default theme is not very "thematic" as it's the default and should be versatile ... Home page matching that theme could still be the mostly recommended choice. BTW a flavor, with such mechanism, could provide several "home page" variants and not only one, depending on the case. If I take the case of a flavor based on the Mail archive (or the mail archive extension alone, say), it already provides different views as the app home page (timeline, livetable, etc). Currently the switch is done through conditional include. Currently that app home page is MailArchive.WebHome, if I could register it as a possible home page template, it would avoid having to rename it "Main.WebHome" to make it a flavor (and potentially destroy existing wiki home page by mistake when you install that extension/flavor), and I could fullfill both installation use-cases (of using it as an app among others in some wiki, and as a wiki-wide-flavor in another wiki or subwiki), from the same xar bundled app. Again, here, I talk about possibilities and use-cases that seem logical or interesting to me if I dig into my proposal, but I really don't know if it's a good path or even a good idea for xwiki - I may not have the big picture :) Also, the proposal certainly does not offer any solution for short-term (if you consider it provides options for long-term ;-) )

> 3) it doesn’t solve anything since once you select a default homepage you > still need a way to change it afterwards if you want to change it… >

There was the side-idea of the proposal (not well formulated, maybe was just in my mind) that this wizard and/or DW could be triggered at any later time by an admin if he wants to replace homepage with some other "default" content. Maybe could be seen as a "personalization" step following a new wiki install or upgrade, but that could be triggered at any later time to "re-personalize" his wiki. I would put this then also as a feature in admin UI. The difference with some other proposals, is that it would not be an action available from the standard UI but limited to a post-install step and the admin UI (not like the variant below).

> > I don’t see how this is much better than having a Admin UI allowing you to > change the home page you wish to have. However it’s a lot more complex (and > really marginally better). > > > Maybe instead of all this, it could be enough to unrelate the "new space" > > and "apply space homepage template" features ? > > So I would just have to call "space / apply template" to replace the > > homepage of any space already existing (including Main obviously) ? > > Yes that’s better already IMO but then it should be a menu option to > replace any page content with a page template. >

I'm not sure if you talk about an additional option, or an option that would replace the "space /apply template" by a more generic "page / apply template", but I don't think anyway that a page template is the same thing as a home page template (whether it's a space or wiki home page). You'd seldom want to use a blog post as a home page ...

In this variant, there's still the question, if applying such template is considered an admin operation or not. If it's an admin operation, you also proposed to start moving those admin actions to the admin UI, which is

[email protected] -

...

...

sort of - what was my proposal about in first place :) (I didn't talk specifically about admin UI at that time, but about avoiding to crowd standard UI menus with unfrequent/admin operations). That being said I don't think it's an admin action, if you need to protect home page, as an admin you can set specific rights and forbid this "apply template" to people that don't have those edit rights. I'm not sure editing home page and applying a template should really be different in terms of privileges. But applying a template on an existing page or home page, seems to be a rather unfrequent operation.

> > > Thanks > -Vincent > > > > It was just a high level view on the direction to follow, and not a > > > specific technical aspect, so no reason to -1 it, right? > > > > > > > > > > BTW there’s also another variation for the home page that hasn’t been > > > > discussed yet: > > > > * Make the home page special by not making it editable (and without > any > > > > docextra tabs at the bottom). So no rollback issue/edit weirdness. > > > > * Only admins can change it and only through the Admin UI (basically > > > > decide which space home page to display on the wiki home page). > > > > * Somewhere in the content of the default home page or through the > first > > > > time wizard, direct the users to the Sandbox page to try it out > editing > > > > (since this is what Sandbox is for!) > > > > > > > > > > Adding this too and I think we`re good for going forward with a vote, > > since > > > we have plenty of proposals. > > > > > > Thanks, > > > Eduard > > > > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > The task of teaching the user is delegated exclusively to the Help > > > > > Application, with the note that the application will also be > proposed > > to > > > > > the user to be redirected to, as a final step in the DW (after the > > > > > installation of the user selected flavor is complete). > > > > > > > > > > All of this assumes that we have a properly working Flavors feature > > and > > > > > Help Application. However, what should we do in the meanwhile for > the > > > > > default XWiki Enterprise UI / Flavor / build? Should we postpone > yet > > > > again > > > > > any work on the homepage until we have the needed elements to > delegate > > > > the > > > > > problematic aspects, or should we do something about it in the > > meanwhile? > > > > > > > > > > Thanks, > > > > > Eduard > > > > > > > > > > ---------- > > > > > [1] > http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals > > > > > [2] > > > > > > > > > > > >

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbution...

...

...

...

> > > > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" > Delhumeau < > > > > > [email protected]> wrote: > > > > > > > > > > > Hello. > > > > > > > > > > > > I have again a new argument against using the dashboard and the > > include > > > > > > macro in the main page. > > > > > > > > > > > > When the user uses the "Inline" editor to change some gadgets, > she > > can > > > > not > > > > > > use the rollback action of the main page to cancel her changes. > She > > > > has to > > > > > > go to the Dashboard page first, and then rollback her changes > from > > > > there. > > > > > > > > > > > > Having an include macro in the default page is absolutely not > > > > intuitive, > > > > > > even if you make it appears more clearly. > > > > > > > > > > > > Thanks, > > > > > > Guillaume > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Thu, Nov 6, 2014 at 2:24 PM, Thomas Mortagne <[email protected]> wrote:

On Thu, Nov 6, 2014 at 1:13 PM, [email protected] <[email protected]> wrote:

...

On 6 Nov 2014 at 12:58:48, Guillaume Louis-Marie Delhumeau (

[email protected](mailto:[email protected])) wrote:

...

...

We had this discussion one year ago with Vincent. He wanted to go in the direction where everything is an application with a proper UI and not necessary in the administration.

Some points on this to be clear:

1) Indeed for discoverability I think it's good to have application

features visible in the app themselves whether it’s for end users, developers or admins. For example the fact that in the Wiki Index, you can have an “Edit Descriptor” button if you’re an admin of that wiki, or the fact that in the AllDocs livetable page, you can delete a doc if you have the permissions. Basically you see actions that you have the right to perform.

...

2) Regarding configuration of apps, I agree that the best place is the

Administration with sections for each app. What I didn’t want to have is to force the users to be admin to be able to access applications. For example at the time the discussions were about the Scheduler app, the Statistics app just to name 2. It was proposed that they be visible/findable only from the Admin screens and that’s what I didn’t like. In the end I’ve made them visible/discoverable by listing them in the Application Panel when the user has admin rights.

...

3) Wiki descriptors are about configuration and I would find it normal

and good to have them in the Main wiki’s administration screens too. This means they could be accesssed both from the Wiki index screen ( point 1) above) and from the Admin UI (point 2) above).

I agree thate there is no reason to choose a single place where you can access the wiki descriptor, it's usefull in both sides. Not to be mixed with the place where the descriptor itself is actually stored which should remain in the main wiki for, I hope, obvious technical reasons (one of them mentionned by Guillaume).

Exactly. I wanted to point that out too, since I get the feeling that Guillaume made it sound like we would be forced to move the wiki descriptor in the local wiki if we want to make it editable from the subwiki's administration too, which is not the case. Also, note that for Workspaces (initial implementation) it was previously possible to edit the subwiki`s descriptor (which was located on the main wiki) from inside the subwiki`s Administration, which was a natural thing to do IMO. I would like to have us be able to do that too with the 'wiki' refactoring since: A) the applications bar is not good for these things (plus it gets crowded really fast and I think it's not a very good idea anyway, except just for a user-configurable 'favorite' apps, but not for *all* apps since it does not make sense). The only purpose of the app bar, IMO, should be for user-favorite apps only, with admin selected/proposed defaults (like we do for the User Directory customization). B) configuring the wiki descriptor is not really something *that* optional once you start deploying. It's not an application that you can or can not have. For the n-th time, I would like to stress out the importance of the wiki module and that it should not be considered as something optional, but part of the wiki model itself, thus, no reason to place it into the 'Applications' section for the same reason why we don`t have Rights or Users in the 'Applications' section; they are part of the model and core features. I hope we have not diverged too much from the topic of this thread, but I do feel this discussion is related, in the end, to being able to set the wiki's homepage from a sensible, reasonable and user discoverable location. Thanks, Eduard

...

Thanks -Vincent

...

Moreover, it is very important to be able to modify a descriptor from

the

...

...

main wiki instead of the subwiki, since if you break it, you might be unable to access your subwiki anymore!

2014-11-06 11:10 GMT+01:00 Marius Dumitru Florea < [email protected]>:

...

On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru wrote:

...

The problem with the current place is that it is not really natural and thus not very discoverable at all.

I have this feeling to. I wanted to edit the descriptor of a subwiki a few days ago and I was surprised I could find anything related in the subwiki administration.

...

If you have to set the homepage, owner, etc of your wiki, you go to administration, but never to "wiki index > edit wiki".

I believe that along this thread we have identified that these settings are valuable for both the main wiki and subwikis so this makes editing the wiki descriptor a valuable and deserving section to be introduced in administration, don`t you agree?

Thanks, Eduard

On Wed, Nov 5, 2014 at 4:38 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2014-11-05 14:43 GMT+01:00 Eduard Moraru :

> Concerning UC3 and UC4, we should not re-invent the wheel. I have just > remembered about the fact that we already have the option of setting the > homepage of a wiki exposed in the wiki's descriptor, so this makes is > already configurable. > > All we need to do now, is to expose this configuration further, in > Administration > Configuration, under Wiki section (just like it was for > workspaces, no idea why we removed it when refactoring to 'wikis'),

About this setting in particular it is because it is part of the wiki descriptor, and we now have only one place to edit these properties.

> where > you can select what is the homepage of your current wiki. Selecting the > owner and basically all the other stuff that you have in a wiki descriptor > should be done at this same level, since these are very important > configurations that one needs to perform for either his main wiki or > subwiki. > > And no, the xwiki-platform-wiki module is not optional (it is part of the > wiki model!), so no point in using a configurable class and throwing it > back in the 'Applications' section. > > This actually goes along the lines of 'Proposal4: Set this page as > homepage' [1], but done in Administration, not on every page, like Vincent > suggested. > > To get the homepage, apps need to do: > $services.wiki.getById($services.wiki.currentWikiId).mainPageReference > Of course, this can be improved to > $services.wiki.currentWikiDescriptor.mainPageReference > > We will be still having the backwards compatibility concerns of P4, however > I am sure that practical solutions (e.g. making Main.WebHome redirect to >

$services.wiki.getById($services.wiki.currentWikiId).mainPageReference,

...

...

...

> etc.) can be found if problems arise in daily use. > > WDYT? > > ---------- > [1] > >

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal4Setthispage...

...

...

...

> > On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET < > [email protected]> wrote: > > > Hi, > > > > 2014-10-28 21:08 GMT+01:00 [email protected] : > > > > > > > > > > > > > > > > > > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET ( > [email protected] > > > (mailto:[email protected])) wrote: > > > > > > > Hi, > > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit : > > > > > > > > > > Hi Vincent, > > > > > > > > > > On Mon, Oct 27, 2014 at 11:05 AM, [email protected] > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru ( [email protected] > > > (mailto: > > > > > > [email protected])) wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > 2 new proposals (P6 and P7) have been made recently. I did not > > yet > > > get > > > > > > the > > > > > > > chance to add comments/analysis on them. Feel free to do it in > > the > > > > > > > meanwhile if anybody wants to. > > > > > > > > > > > > > > A few notes on Jeremie's "Proposal7: DistrbutionWizard sets the > > > > homepage > > > > > > of > > > > > > > a flavor and the Help App teaches users" [2]: > > > > > > > > > > > > > > Personally, I find it a rather elegant solution based on > > > separation of > > > > > > > concerns. However, you need to be aware that it is a > medium/long > > > term > > > > > > > objective. > > > > > > > > > > > > > > The way I understood it is that we delegate the task of > choosing > > a > > > > > > homepage > > > > > > > to the DistributionWizard that will most likely be in charge of > > > > offering > > > > > > > the user flavor options. At that point, the homepage of the > > current > > > > wiki > > > > > > > will be the homepage of the user selected flavor. Optionally, > we > > > can > > > > also > > > > > > > propose to use a blank page as homepage if the user wants, > > however > > > > this > > > > > > > might be a bit of an overkill, since the user can easily edit > the > > > page > > > > > > and > > > > > > > trash everything. > > > > > > > > > > > > The DW should not know at all about any page. It should be up to > > the > > > > > > flavor to define the wiki pages it will contain and install. Each > > > flavor > > > > > > should propose its own home page. > > > > > > > > > > > > > > > > Maybe I did not choose the best words, but the way I understood it > > (and > > > > > tried to reformulate it) was not that the DW explicitly allows you > to > > > > > select a homepage, but that indirectly, through allowing you to > > > install a > > > > > flavor, it will additionally do the job (again, indirectly) of > making > > > you > > > > > choose a homepage (through the flavor you have selected). > > > > > > > > Yes that was the idea, possibly: > > > > - DW doesn't have to know pages or set homepage > > > > - there could be a new wizard, similar to wizards for new page / > space > > > from > > > > template, that allows choosing a kind of homepage (empty, wiki > > concepts, > > > > dashboard, etc) > > > > - a flavor also adds its homepage as a possible "template" > > > > - btw it could be exactly the new space from template page, but with > > more > > > > choices than current (empty / dashboard) > > > > - following a dw run and a flavor installation, this "new Main space > > > > homepage from template" wizard is triggered and displayed (or just > > > proposed > > > > to user through a button or link), and allows user to either choose > > > default > > > > homepage of the flavor, or use another one > > > > - current (or reworked) homepage is just the default home of the > > default > > > > flavor (which is the current XE xar) > > > > > > ok but: > > > > > > 1) it’s complex since it means that a flavor would need to register > some > > > kind of post install script to execute (which is something we don’t > > really > > > have) > > > > > > > Depends, I was thinking more about a specific event like "flavor > installed" > > or "extension installed" or "wiki installed / updated". I'm not sure to > get > > what you would need to do in this post install script ? > > But it could be completely "manual" or just a link at the end of DW to > some > > possible post-install stuff (like, consult help, manage home page, etc). > > > > I'd like to apologize here because my "proposal" was more an idea than a > > well formalized proposal, even if it ended up in the list of proposals, > > it's obvious that it misses some thoughts and clarifications... (I > > understand your -1). > > > > > > > 2) it negates a bit the point of a flavor which is to propose a defined > > > “theme” and thus a defined home page matching that theme > > > > > > > Well, if you consider that current UI of XE is the default xwiki > "flavor", > > this is exactly what it's about when we talk about switching home page > > easily, isn't it ? We want to let user set a home page that doesn't match > > the default theme freely. Obviously this default theme is not very > > "thematic" as it's the default and should be versatile ... > > Home page matching that theme could still be the mostly recommended > choice. > > BTW a flavor, with such mechanism, could provide several "home page" > > variants and not only one, depending on the case. > > If I take the case of a flavor based on the Mail archive (or the mail > > archive extension alone, say), it already provides different views as the > > app home page (timeline, livetable, etc). Currently the switch is done > > through conditional include. Currently that app home page is > > MailArchive.WebHome, if I could register it as a possible home page > > template, it would avoid having to rename it "Main.WebHome" to make it a > > flavor (and potentially destroy existing wiki home page by mistake when > you > > install that extension/flavor), and I could fullfill both installation > > use-cases (of using it as an app among others in some wiki, and as a > > wiki-wide-flavor in another wiki or subwiki), from the same xar bundled > > app. > > Again, here, I talk about possibilities and use-cases that seem logical > or > > interesting to me if I dig into my proposal, but I really don't know if > > it's a good path or even a good idea for xwiki - I may not have the big > > picture :) > > Also, the proposal certainly does not offer any solution for short-term > (if > > you consider it provides options for long-term ;-) ) > > > > > > > 3) it doesn’t solve anything since once you select a default homepage > you > > > still need a way to change it afterwards if you want to change it… > > > > > > > There was the side-idea of the proposal (not well formulated, maybe was > > just in my mind) that this wizard and/or DW could be triggered at any > later > > time by an admin if he wants to replace homepage with some other > "default" > > content. Maybe could be seen as a "personalization" step following a new > > wiki install or upgrade, but that could be triggered at any later time to > > "re-personalize" his wiki. I would put this then also as a feature in > admin > > UI. > > The difference with some other proposals, is that it would not be an > action > > available from the standard UI but limited to a post-install step and the > > admin UI (not like the variant below). > > > > > > > > > > I don’t see how this is much better than having a Admin UI allowing you > > to > > > change the home page you wish to have. However it’s a lot more complex > > (and > > > really marginally better). > > > > > > > Maybe instead of all this, it could be enough to unrelate the "new > > space" > > > > and "apply space homepage template" features ? > > > > So I would just have to call "space / apply template" to replace the > > > > homepage of any space already existing (including Main obviously) ? > > > > > > Yes that’s better already IMO but then it should be a menu option to > > > replace any page content with a page template. > > > > > > > I'm not sure if you talk about an additional option, or an option that > > would replace the "space /apply template" by a more generic "page / apply > > template", but I don't think anyway that a page template is the same > thing > > as a home page template (whether it's a space or wiki home page). You'd > > seldom want to use a blog post as a home page ... > > > > In this variant, there's still the question, if applying such template is > > considered an admin operation or not. If it's an admin operation, you > also > > proposed to start moving those admin actions to the admin UI, which is - > > sort of - what was my proposal about in first place :) (I didn't talk > > specifically about admin UI at that time, but about avoiding to crowd > > standard UI menus with unfrequent/admin operations). > > That being said I don't think it's an admin action, if you need to > protect > > home page, as an admin you can set specific rights and forbid this "apply > > template" to people that don't have those edit rights. I'm not sure > editing > > home page and applying a template should really be different in terms of > > privileges. But applying a template on an existing page or home page, > seems > > to be a rather unfrequent operation. > > > > > > > > > > > > > Thanks > > > -Vincent > > > > > > > > It was just a high level view on the direction to follow, and not a > > > > > specific technical aspect, so no reason to -1 it, right? > > > > > > > > > > > > > > > > BTW there’s also another variation for the home page that hasn’t > > been > > > > > > discussed yet: > > > > > > * Make the home page special by not making it editable (and > without > > > any > > > > > > docextra tabs at the bottom). So no rollback issue/edit > weirdness. > > > > > > * Only admins can change it and only through the Admin UI > > (basically > > > > > > decide which space home page to display on the wiki home page). > > > > > > * Somewhere in the content of the default home page or through > the > > > first > > > > > > time wizard, direct the users to the Sandbox page to try it out > > > editing > > > > > > (since this is what Sandbox is for!) > > > > > > > > > > > > > > > > Adding this too and I think we`re good for going forward with a > vote, > > > > since > > > > > we have plenty of proposals. > > > > > > > > > > Thanks, > > > > > Eduard > > > > > > > > > > > > > > > > > Thanks > > > > > > -Vincent > > > > > > > > > > > > > The task of teaching the user is delegated exclusively to the > > Help > > > > > > > Application, with the note that the application will also be > > > proposed > > > > to > > > > > > > the user to be redirected to, as a final step in the DW (after > > the > > > > > > > installation of the user selected flavor is complete). > > > > > > > > > > > > > > All of this assumes that we have a properly working Flavors > > feature > > > > and > > > > > > > Help Application. However, what should we do in the meanwhile > for > > > the > > > > > > > default XWiki Enterprise UI / Flavor / build? Should we > postpone > > > yet > > > > > > again > > > > > > > any work on the homepage until we have the needed elements to > > > delegate > > > > > > the > > > > > > > problematic aspects, or should we do something about it in the > > > > meanwhile? > > > > > > > > > > > > > > Thanks, > > > > > > > Eduard > > > > > > > > > > > > > > ---------- > > > > > > > [1] > > > http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals > > > > > > > [2] > > > > > > > > > > > > > > > > > > > > > > >

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbution...

...

...

...

> > > > > > > > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" > > > Delhumeau < > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > Hello. > > > > > > > > > > > > > > > > I have again a new argument against using the dashboard and > the > > > > include > > > > > > > > macro in the main page. > > > > > > > > > > > > > > > > When the user uses the "Inline" editor to change some > gadgets, > > > she > > > > can > > > > > > not > > > > > > > > use the rollback action of the main page to cancel her > changes. > > > She > > > > > > has to > > > > > > > > go to the Dashboard page first, and then rollback her changes > > > from > > > > > > there. > > > > > > > > > > > > > > > > Having an include macro in the default page is absolutely not > > > > > > intuitive, > > > > > > > > even if you make it appears more clearly. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Guillaume > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Ok. So as far as I can see, it`s quite clear that the changing of homepage needs to be done from the wiki administration section. It can me done now too (by editing wiki descriptors), but it needs a bit more work until it`s just right for everybody. So UC3/4 are out of the discussion, leaving the remaining Use Cases as the subject of this thread and proposals. Thanks, Eduard P.S.: Please feel free to correct me if I`m wrong and if you have something against a wiki administration section for handling the selection of a homepage. On Mon, Nov 10, 2014 at 4:04 PM, Marius Dumitru Florea < [email protected]> wrote:

On Thu, Nov 6, 2014 at 1:57 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:

...

We had this discussion one year ago with Vincent. He wanted to go in the direction where everything is an application with a proper UI and not necessary in the administration.

...

Moreover, it is very important to be able to modify a descriptor from the main wiki instead of the subwiki, since if you break it, you might be unable to access your subwiki anymore!

It is also very important that a local (subwiki) admin is able to modify (some) fields from the wiki descriptor (like the home page) without having access to the main wiki. The fact that the wiki descriptor is stored in the main wiki is an implementation detail.

Thanks, Marius

...

2014-11-06 11:10 GMT+01:00 Marius Dumitru Florea < [email protected]>:

...

On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru <[email protected]> wrote:

...

The problem with the current place is that it is not really natural

and

...

...

...

thus not very discoverable at all.

I have this feeling to. I wanted to edit the descriptor of a subwiki a few days ago and I was surprised I could find anything related in the subwiki administration.

...

If you have to set the homepage, owner, etc of your wiki, you go to administration, but never to "wiki index > edit wiki".

I believe that along this thread we have identified that these settings are valuable for both the main wiki and subwikis so this makes editing the wiki descriptor a valuable and deserving section to be introduced in administration, don`t you agree?

Thanks, Eduard

On Wed, Nov 5, 2014 at 4:38 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2014-11-05 14:43 GMT+01:00 Eduard Moraru <[email protected]>:

...

Concerning UC3 and UC4, we should not re-invent the wheel. I have just remembered about the fact that we already have the option of setting the homepage of a wiki exposed in the wiki's descriptor, so this makes is already configurable.

All we need to do now, is to expose this configuration further, in Administration > Configuration, under Wiki section (just like it was for workspaces, no idea why we removed it when refactoring to 'wikis'),

About this setting in particular it is because it is part of the wiki descriptor, and we now have only one place to edit these properties.

...

where you can select what is the homepage of your current wiki. Selecting the owner and basically all the other stuff that you have in a wiki descriptor should be done at this same level, since these are very important configurations that one needs to perform for either his main wiki or subwiki.

And no, the xwiki-platform-wiki module is not optional (it is part of the wiki model!), so no point in using a configurable class and throwing it back in the 'Applications' section.

This actually goes along the lines of 'Proposal4: Set this page as homepage' [1], but done in Administration, not on every page, like Vincent suggested.

To get the homepage, apps need to do:

$services.wiki.getById($services.wiki.currentWikiId).mainPageReference

...

Of course, this can be improved to $services.wiki.currentWikiDescriptor.mainPageReference

We will be still having the backwards compatibility concerns of P4, however I am sure that practical solutions (e.g. making Main.WebHome redirect to

$services.wiki.getById($services.wiki.currentWikiId).mainPageReference,

...

etc.) can be found if problems arise in daily use.

WDYT?

---------- [1]

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal4Setthispage...

...

...

...

...

On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET < [email protected]> wrote:

> Hi, > > 2014-10-28 21:08 GMT+01:00 [email protected] <

...

> > > > > > > > > > > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET ( [email protected] > > (mailto:[email protected])) wrote: > > > > > Hi, > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit : > > > > > > > > Hi Vincent, > > > > > > > > On Mon, Oct 27, 2014 at 11:05 AM, [email protected] > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru ( [email protected] > > (mailto: > > > > > [email protected])) wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > 2 new proposals (P6 and P7) have been made recently. I did not > yet > > get > > > > > the > > > > > > chance to add comments/analysis on them. Feel free to do it in > the > > > > > > meanwhile if anybody wants to. > > > > > > > > > > > > A few notes on Jeremie's "Proposal7: DistrbutionWizard sets the > > > homepage > > > > > of > > > > > > a flavor and the Help App teaches users" [2]: > > > > > > > > > > > > Personally, I find it a rather elegant solution based on > > separation of > > > > > > concerns. However, you need to be aware that it is a medium/long > > term > > > > > > objective. > > > > > > > > > > > > The way I understood it is that we delegate the task of choosing > a > > > > > homepage > > > > > > to the DistributionWizard that will most likely be in charge of > > > offering > > > > > > the user flavor options. At that point, the homepage of the > current > > > wiki > > > > > > will be the homepage of the user selected flavor. Optionally, we > > can > > > also > > > > > > propose to use a blank page as homepage if the user wants, > however > > > this > > > > > > might be a bit of an overkill, since the user can easily edit the > > page > > > > > and > > > > > > trash everything. > > > > > > > > > > The DW should not know at all about any page. It should be up to > the > > > > > flavor to define the wiki pages it will contain and install. Each > > flavor > > > > > should propose its own home page. > > > > > > > > > > > > > Maybe I did not choose the best words, but the way I understood it > (and > > > > tried to reformulate it) was not that the DW explicitly allows you to > > > > select a homepage, but that indirectly, through allowing you to > > install a > > > > flavor, it will additionally do the job (again, indirectly) of making > > you > > > > choose a homepage (through the flavor you have selected). > > > > > > Yes that was the idea, possibly: > > > - DW doesn't have to know pages or set homepage > > > - there could be a new wizard, similar to wizards for new page / space > > from > > > template, that allows choosing a kind of homepage (empty, wiki > concepts, > > > dashboard, etc) > > > - a flavor also adds its homepage as a possible "template" > > > - btw it could be exactly the new space from template page, but with > more > > > choices than current (empty / dashboard) > > > - following a dw run and a flavor installation, this "new Main space > > > homepage from template" wizard is triggered and displayed (or just > > proposed > > > to user through a button or link), and allows user to either choose > > default > > > homepage of the flavor, or use another one > > > - current (or reworked) homepage is just the default home of the > default > > > flavor (which is the current XE xar) > > > > ok but: > > > > 1) it’s complex since it means that a flavor would need to register some > > kind of post install script to execute (which is something we don’t > really > > have) > > > > Depends, I was thinking more about a specific event like "flavor installed" > or "extension installed" or "wiki installed / updated". I'm not sure to get > what you would need to do in this post install script ? > But it could be completely "manual" or just a link at the end of DW to some > possible post-install stuff (like, consult help, manage home page, etc). > > I'd like to apologize here because my "proposal" was more an idea than a > well formalized proposal, even if it ended up in the list of proposals, > it's obvious that it misses some thoughts and clarifications... (I > understand your -1). > > > > 2) it negates a bit the point of a flavor which is to propose a defined > > “theme” and thus a defined home page matching that theme > > > > Well, if you consider that current UI of XE is the default xwiki "flavor", > this is exactly what it's about when we talk about switching home page > easily, isn't it ? We want to let user set a home page that doesn't match > the default theme freely. Obviously this default theme is not very > "thematic" as it's the default and should be versatile ... > Home page matching that theme could still be the mostly recommended choice. > BTW a flavor, with such mechanism, could provide several "home page" > variants and not only one, depending on the case. > If I take the case of a flavor based on the Mail archive (or the mail > archive extension alone, say), it already provides different views as the > app home page (timeline, livetable, etc). Currently the switch is done > through conditional include. Currently that app home page is > MailArchive.WebHome, if I could register it as a possible home page > template, it would avoid having to rename it "Main.WebHome" to make it a > flavor (and potentially destroy existing wiki home page by mistake when you > install that extension/flavor), and I could fullfill both installation > use-cases (of using it as an app among others in some wiki, and as a > wiki-wide-flavor in another wiki or subwiki), from the same xar bundled > app. > Again, here, I talk about possibilities and use-cases that seem logical or > interesting to me if I dig into my proposal, but I really don't know if > it's a good path or even a good idea for xwiki - I may not have the big > picture :) > Also, the proposal certainly does not offer any solution for short-term (if > you consider it provides options for long-term ;-) ) > > > > 3) it doesn’t solve anything since once you select a default homepage you > > still need a way to change it afterwards if you want to change it… > > > > There was the side-idea of the proposal (not well formulated, maybe was > just in my mind) that this wizard and/or DW could be triggered at any later > time by an admin if he wants to replace homepage with some other "default" > content. Maybe could be seen as a "personalization" step following a new > wiki install or upgrade, but that could be triggered at any later time to > "re-personalize" his wiki. I would put this then also as a feature in admin > UI. > The difference with some other proposals, is that it would not be an action > available from the standard UI but limited to a post-install step and the > admin UI (not like the variant below). > > > > > > I don’t see how this is much better than having a Admin UI allowing you > to > > change the home page you wish to have. However it’s a lot more complex > (and > > really marginally better). > > > > > Maybe instead of all this, it could be enough to unrelate the "new > space" > > > and "apply space homepage template" features ? > > > So I would just have to call "space / apply template" to replace the > > > homepage of any space already existing (including Main obviously) ? > > > > Yes that’s better already IMO but then it should be a menu option to > > replace any page content with a page template. > > > > I'm not sure if you talk about an additional option, or an option that > would replace the "space /apply template" by a more generic "page / apply > template", but I don't think anyway that a page template is the same thing > as a home page template (whether it's a space or wiki home page). You'd > seldom want to use a blog post as a home page ... > > In this variant, there's still the question, if applying such template is > considered an admin operation or not. If it's an admin operation, you also > proposed to start moving those admin actions to the admin UI, which is

[email protected]>: -

...

> sort of - what was my proposal about in first place :) (I didn't talk > specifically about admin UI at that time, but about avoiding to crowd > standard UI menus with unfrequent/admin operations). > That being said I don't think it's an admin action, if you need to protect > home page, as an admin you can set specific rights and forbid this "apply > template" to people that don't have those edit rights. I'm not sure editing > home page and applying a template should really be different in terms of > privileges. But applying a template on an existing page or home page, seems > to be a rather unfrequent operation. > > > > > > > > Thanks > > -Vincent > > > > > > It was just a high level view on the direction to follow, and not a > > > > specific technical aspect, so no reason to -1 it, right? > > > > > > > > > > > > > BTW there’s also another variation for the home page that hasn’t > been > > > > > discussed yet: > > > > > * Make the home page special by not making it editable (and without > > any > > > > > docextra tabs at the bottom). So no rollback issue/edit weirdness. > > > > > * Only admins can change it and only through the Admin UI > (basically > > > > > decide which space home page to display on the wiki home page). > > > > > * Somewhere in the content of the default home page or through the > > first > > > > > time wizard, direct the users to the Sandbox page to try it out > > editing > > > > > (since this is what Sandbox is for!) > > > > > > > > > > > > > Adding this too and I think we`re good for going forward with a vote, > > > since > > > > we have plenty of proposals. > > > > > > > > Thanks, > > > > Eduard > > > > > > > > > > > > > > Thanks > > > > > -Vincent > > > > > > > > > > > The task of teaching the user is delegated exclusively to the > Help > > > > > > Application, with the note that the application will also be > > proposed > > > to > > > > > > the user to be redirected to, as a final step in the DW (after > the > > > > > > installation of the user selected flavor is complete). > > > > > > > > > > > > All of this assumes that we have a properly working Flavors > feature > > > and > > > > > > Help Application. However, what should we do in the meanwhile for > > the > > > > > > default XWiki Enterprise UI / Flavor / build? Should we postpone > > yet > > > > > again > > > > > > any work on the homepage until we have the needed elements to > > delegate > > > > > the > > > > > > problematic aspects, or should we do something about it in the > > > meanwhile? > > > > > > > > > > > > Thanks, > > > > > > Eduard > > > > > > > > > > > > ---------- > > > > > > [1] > > http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals > > > > > > [2] > > > > > > > > > > > > > > > > >

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbution...

...

...

...

...

> > > > > > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" > > Delhumeau < > > > > > > [email protected]> wrote: > > > > > > > > > > > > > Hello. > > > > > > > > > > > > > > I have again a new argument against using the dashboard and the > > > include > > > > > > > macro in the main page. > > > > > > > > > > > > > > When the user uses the "Inline" editor to change some gadgets, > > she > > > can > > > > > not > > > > > > > use the rollback action of the main page to cancel her changes. > > She > > > > > has to > > > > > > > go to the Dashboard page first, and then rollback her changes > > from > > > > > there. > > > > > > > > > > > > > > Having an include macro in the default page is absolutely not > > > > > intuitive, > > > > > > > even if you make it appears more clearly. > > > > > > > > > > > > > > Thanks, > > > > > > > Guillaume > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs