[xwiki-devs] Home Page - Use cases, proposals, what we have until now and what we want to achieve
8 Oct
2014
8 Oct
'14
3:48 p.m.
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
8 Oct
8 Oct
4:03 p.m.
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 <enygma2002(a)gmail.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
4:12 p.m.
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 <dgl(a)softec.lu> 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 <enygma2002(a)gmail.com>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
13 Oct
13 Oct
10:48 a.m.
Bumping this thread so we strike while the iron is hot.
Any notes on the existing proposals? Anything to add, anything to remove?
Is that the best we can do?
If the answers are "no, no, yes" then is it the time to move to a vote with
the current proposals?
Thanks,
Eduard
On Wed, Oct 8, 2014 at 5:12 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
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 <dgl(a)softec.lu> 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 <enygma2002(a)gmail.com>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:27 a.m.
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
4:16 p.m.
Hi all,
After having read all proposals, personally I prefer proposal #1.
To avoid issue with editing dashboard as it is included from another page,
I would clearly remove this inclusion and make Main.WebHome a real
(autonomous) dashboard with no link with Main.Dashboard. There is room for
2 dashboards (the wiki dashboard and the wiki home page dashboard :) ).
I prefer this proposal because it improves long-running "issues" (or
limitations) of the wysiwyg editor, which on another side is great.
I also prefer it because IMHO editing macros should feel natural in XWiki
because they are a great feature and there is / should be nothing technical
with a rendering macro.
For wysiwyg/inline, I'm not sure why, when you are not advanced user, you
can't choose between both. To me "edit" action should default to wysiwyg
(or wiki depending on configuration), and IF there is some content that can
be edited inline, you should have something else to click (button, link,
pencil icon ...) to edit it "inline" and it switches the whole page to
inline mode.
Also "Edit / Inline form" is weird name in some cases, when I edit inline
the dashboard, I don't feel I'm editing a form...
Proposal #2: to me a proper UI for the include macro configuration in
wysiwyg (so, proposal #1), could in the end be very similar to this
proposal (like, I click edit, it opens wysiwyg, I click edit on include
macro, and I can select a page from a list or table or a page suggest or
whatever).
Proposal #3: I like the part about explaining the concepts, but it could be
done without removing the dashboard, in fact it seems to be 2 different
things. Also it's nice to have those descriptions on home page, but when
first user has read them (wether he's the admin or not), when he customize
the page he will remove them and ... they'll be lost for all other users ?
I'd prefer to have a question-mark icon somewhere to click to get some
help, that would start with explaining xwiki concepts, and then provide
some links to go deeper.
By the way it's surprising, on a fresh XWiki install, to see that there is
no "help" entry nowhere in the UI, not any question-mark icon, or help menu
entry. You get some help only once you edit a page, and only on wiki syntax.
There is the "Getting started" link on the default home page, but it
contains mainly a screenshot of the default home page (that I could have
changed already, so for new comers of my site, this getting started would
be confusing) with some numbers, difficult to consult as I have to scroll
to see the numbers and their description.
To me xwiki is not just a site or just a wiki, it's a highly interactive
site, with many features from "basic" to "very advanced": it deserves
a
better help system ;-)
(note: just discovered the help center proposal [1] below, see comments on
proposal #5 also)
Proposal #4: I don't see how it solves issue with editing home page, it
merely simplifies peeking any page as a home page.
Along with proposal #2, I would say that everyone seem to find that there
are too many concepts, too technical, etc, but those proposals continue to
add new concepts on top of existing ones, and are pretty much useless if
it's deadly simple to edit an include macro.
Also I find it buries navigation inside configuration, and destroys habit
of current users about "WebHome is a home page".
It also seems like a workaround, like: "if it's hard to edit a page, peek
another one".
Proposal #5: I really like the Help Center proposal [1] in fact :) But I
think it's // with other proposals in fact, having more help won't solve
home page editing issues, but it could greatly improve overall end-user
experience (in any case).
BR,
Jeremie
[1] - http://design.xwiki.org/xwiki/bin/view/Improvements/HelpCenter
2014-10-13 11:27 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com>gt;:
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
14 Oct
14 Oct
11:40 a.m.
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
24 Oct
24 Oct
9:17 p.m.
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 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/HomepageProposal7Distrbutio…
On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
27 Oct
27 Oct
10:05 a.m.
Hi,
On 24 Oct 2014 at 21:18:31, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) 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/HomepageProposal7Distrbutio…
On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
28 Oct
28 Oct
7:39 p.m.
Hi Vincent,
On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi,
On 24 Oct 2014 at 21:18:31, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) wrote:
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).
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?
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!)
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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/HomepageProposal7Distrbutio…
On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:28 p.m.
Hi,
Le 28 oct. 2014 19:39, "Eduard Moraru" <enygma2002(a)gmail.com> a écrit :
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) ?
Hi Vincent,
On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
> Hi,
>
> On 24 Oct 2014 at 21:18:31, Eduard Moraru (enygma2002(a)gmail.com(mailto:
> enygma2002(a)gmail.com)) 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.
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?
since
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, 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/HomepageProposal7Distrbutio…
> >
> > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" Delhumeau
<
> > gdelhumeau(a)xwiki.com> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs > 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:08 p.m.
On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET
(jeremie.bousquet@gmail.com(mailto:jeremie.bousquet@gmail.com)) wrote:
Hi,
Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
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)
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
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…
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).
Hi Vincent,
On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
wrote:
> Hi,
>
> On 24 Oct 2014 at 21:18:31, Eduard Moraru (enygma2002(a)gmail.com(mailto:
> enygma2002(a)gmail.com)) 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 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.
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?
since
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, 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/HomepageProposal7Distrbutio…
> >
> > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" Delhumeau
<
> > gdelhumeau(a)xwiki.com> 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
29 Oct
29 Oct
5:10 p.m.
Hi,
2014-10-28 21:08 GMT+01:00 vincent(a)massol.net <vincent(a)massol.net>et>:
On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (jeremie.bousquet(a)gmail.com
(mailto:jeremie.bousquet@gmail.com)) wrote:
separation
of
can
from
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).
Hi,
Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
>
> Hi Vincent,
>
> On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
> wrote:
>
> > Hi,
> >
> > On 24 Oct 2014 at 21:18:31, Eduard Moraru (enygma2002(a)gmail.com
(mailto:
> > enygma2002(a)gmail.com)) 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 > > > 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 also
page
> > 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 > > 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 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)
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).
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.
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.
Thanks
-Vincent
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
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbutio…
she
> 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, to
the
> > 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 > > > 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] > >
[2]
> >
>
> > >
> > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie"
Delhumeau <
> >
gdelhumeau(a)xwiki.com> 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, 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5 Nov
5 Nov
2:43 p.m.
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'), 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/HomepageProposal4Setthispag…
On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com> wrote:
Hi,
2014-10-28 21:08 GMT+01:00 vincent(a)massol.net <vincent(a)massol.net>et>:
separation
of
a
however
the
(and
from
> template, that allows choosing a kind of homepage (empty, wiki concepts,
default
really
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.
(basically
Help
the
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbutio…
she
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (jeremie.bousquet(a)gmail.com
(mailto:jeremie.bousquet@gmail.com)) wrote:
yet
Hi,
Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
>
> Hi Vincent,
>
> On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
> wrote:
>
> > Hi,
> >
> > On 24 Oct 2014 at 21:18:31, Eduard Moraru (enygma2002(a)gmail.com
(mailto:
> > > enygma2002(a)gmail.com)) wrote:
> > >
> > > > Hi,
> > > >
> > > > 2 new proposals (P6 and P7) have been made recently. I did not 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 > > > 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
> > > 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, 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 > >
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 >
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 > 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 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 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.
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 > >
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 > >
> 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 > > > > 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] > >
[2]
> >
>
> >
>
> > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie"
Delhumeau <
> >
gdelhumeau(a)xwiki.com> 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, 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:38 p.m.
2014-11-05 14:43 GMT+01:00 Eduard Moraru <enygma2002(a)gmail.com>om>:
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/HomepageProposal4Setthispag…
On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com> wrote:
medium/long
the
(and
> > > tried to reformulate it) was not that the DW explicitly allows you
to
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
installed"
later
the
the
for
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbutio…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi,
2014-10-28 21:08 GMT+01:00 vincent(a)massol.net <vincent(a)massol.net>et>:
>
>
>
>
>
> On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
jeremie.bousquet(a)gmail.com
(mailto:jeremie.bousquet@gmail.com)) wrote:
yet
Hi,
Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
>
> Hi Vincent,
>
> On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
> wrote:
>
> > Hi,
> >
> > On 24 Oct 2014 at 21:18:31, Eduard Moraru (enygma2002(a)gmail.com
(mailto:
> > > enygma2002(a)gmail.com)) wrote:
> > >
> > > > Hi,
> > > >
> > > > 2 new proposals (P6 and P7) have been made recently. I did not 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 > term
> > > > > objective.
> > > > >
> > > > > The way I understood it is that we delegate the task of
choosing
a
we
> > > 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,
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
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 > > > 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 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 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).
"flavor",
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 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 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'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
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.
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.
without
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 > 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 > 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 > > > > 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
> 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]
> > >
> >
> > > > >
> > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume
"Louis-Marie"
> Delhumeau <
> > > > > gdelhumeau(a)xwiki.com> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> > 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6 Nov
6 Nov
10 a.m.
The problem with the current place is that it is not really natural and
thus not very discoverable at all. 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 <
gdelhumeau(a)xwiki.com> wrote:
2014-11-05 14:43 GMT+01:00 Eduard Moraru
<enygma2002(a)gmail.com>om>:
of
we
the
> > page
> > > > > and
> > > > > > trash everything.
> > > > >
> > > > > The DW should not know at all about any page. It should be up
to
some
installed"
etc).
"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
later
new
the
is
-
"apply
of
not a
the
(after
the
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbutio…
changes
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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/HomepageProposal4Setthispag…
On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com> wrote:
enygma2002(a)gmail.com
Hi,
2014-10-28 21:08 GMT+01:00 vincent(a)massol.net <vincent(a)massol.net>et>:
>
>
>
>
>
> On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
jeremie.bousquet(a)gmail.com
> > (mailto:jeremie.bousquet@gmail.com)) wrote:
> >
> > > Hi,
> > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
> > > >
> > > > Hi Vincent,
> > > >
> > > > On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru ( > > (mailto:
> > > > > enygma2002(a)gmail.com)) 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 > offering
> > > > the user flavor options. At that point, the homepage of the
current
> > wiki
> > > > > will be the homepage of the user selected flavor. Optionally,
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
> > > > > 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
with
> > > 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 > 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 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 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, >
> 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 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 > 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 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
> 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 > 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
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
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
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 > > > > 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 > 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
the
for
> > > > 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
> 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
> meanwhile?
> > > >
> > > > Thanks,
> > > > Eduard
> > > >
> > > > ----------
> > > > [1]
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals
> > > > [2]
> > > >
> > >
>
> >
> > >
> > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume
"Louis-Marie"
> Delhumeau <
> > > > > gdelhumeau(a)xwiki.com> 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
> > 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:10 a.m.
On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru <enygma2002(a)gmail.com> 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 <
gdelhumeau(a)xwiki.com> wrote:
2014-11-05 14:43 GMT+01:00 Eduard Moraru
<enygma2002(a)gmail.com>om>:
of
to
etc).
match
the
new
the
is
-
"apply
of
not a
(after
the
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbutio…
changes
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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/HomepageProposal4Setthispag…
On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com> wrote:
enygma2002(a)gmail.com
Hi,
2014-10-28 21:08 GMT+01:00 vincent(a)massol.net <vincent(a)massol.net>et>:
>
>
>
>
>
> On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
jeremie.bousquet(a)gmail.com
> > (mailto:jeremie.bousquet@gmail.com)) wrote:
> >
> > > Hi,
> > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
> > > >
> > > > Hi Vincent,
> > > >
> > > > On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru ( > > (mailto:
> > > > > enygma2002(a)gmail.com)) 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 > >
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
> 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
with
> > > 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 > 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, >
> 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 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 > 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
> 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 > 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
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
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
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 > > > > 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
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
> >
meanwhile?
> > > > >
> > > > > Thanks,
> > > > > Eduard
> > > > >
> > > > > ----------
> > > > > [1]
> http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals
> > > > > [2]
> > > > >
> > > >
> >
>
> >
> > >
> > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume
"Louis-Marie"
> Delhumeau <
> > > > > gdelhumeau(a)xwiki.com> 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
> > 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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:57 p.m.
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!
2014-11-06 11:10 GMT+01:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
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 <
gdelhumeau(a)xwiki.com> wrote:
> 2014-11-05 14:43 GMT+01:00 Eduard Moraru <enygma2002(a)gmail.com>om>:
>
> > 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/HomepageProposal4Setthispag…
> >
>> > On Wed, Oct 29,
2014 at 6:10 PM, Jeremie BOUSQUET <
>> > jeremie.bousquet(a)gmail.com> wrote:
> >
>> > > Hi,
>> > >
>> > > 2014-10-28 21:08 GMT+01:00 vincent(a)massol.net
<vincent(a)massol.net>et>:
>> > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
>> > jeremie.bousquet(a)gmail.com
>> > > > (mailto:jeremie.bousquet@gmail.com)) wrote:
>> > > >
>> > > > > Hi,
>> > > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
>> > > > > >
>> > > > > > Hi Vincent,
>> > > > > >
>> > > > > > On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru (
>> enygma2002(a)gmail.com
>> > > > (mailto:
>> > > > > > > enygma2002(a)gmail.com)) 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/HomepageProposal7Distrbutio…
> > > > > > > >
> > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume
"Louis-Marie"
> > > > Delhumeau <
> > > > > > > > gdelhumeau(a)xwiki.com> 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
>> > > > devs(a)xwiki.org
>> > > > http://lists.xwiki.org/mailman/listinfo/devs
>> > > >
>> > > _______________________________________________
>> > > devs mailing list
>> > > devs(a)xwiki.org
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> > >
>> > _______________________________________________
>> > devs mailing list
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>>
>>
>>
>> --
>> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:13 p.m.
On 6 Nov 2014 at 12:58:48, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) 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 <
mariusdumitru.florea(a)xwiki.com>gt;:
On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru
wrote:
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 <
gdelhumeau(a)xwiki.com> 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/HomepageProposal4Setthispag…
> >
>> > On Wed, Oct 29,
2014 at 6:10 PM, Jeremie BOUSQUET <
>> > jeremie.bousquet(a)gmail.com> wrote:
> >
>> > > Hi,
>> > >
>> > > 2014-10-28 21:08 GMT+01:00 vincent(a)massol.net :
>> > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
>> > jeremie.bousquet(a)gmail.com
>> > > > (mailto:jeremie.bousquet@gmail.com)) wrote:
>> > > >
>> > > > > Hi,
>> > > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
>> > > > > >
>> > > > > > Hi Vincent,
>> > > > > >
>> > > > > > On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru (
>> enygma2002(a)gmail.com
>> > > > (mailto:
>> > > > > > > enygma2002(a)gmail.com)) 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/HomepageProposal7Distrbutio…
> > > > > > > >
> > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume
"Louis-Marie"
> > > > Delhumeau <
> > > > > > > > gdelhumeau(a)xwiki.com> 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
>> > > > devs(a)xwiki.org
>> > > > http://lists.xwiki.org/mailman/listinfo/devs
>> > > >
>> > > _______________________________________________
>> > > devs mailing list
>> > > devs(a)xwiki.org
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> > >
>> > _______________________________________________
>> > devs mailing list
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>>
>>
>>
>> --
>> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:24 p.m.
On Thu, Nov 6, 2014 at 1:13 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:
On 6 Nov 2014 at 12:58:48, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
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).
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
--
Thomas Mortagne
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 <
mariusdumitru.florea(a)xwiki.com>gt;:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru
wrote:
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 <
gdelhumeau(a)xwiki.com> 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/HomepageProposal4Setthispag…
> >
>> > On Wed, Oct 29,
2014 at 6:10 PM, Jeremie BOUSQUET <
>> > jeremie.bousquet(a)gmail.com> wrote:
> >
>> > > Hi,
>> > >
>> > > 2014-10-28 21:08 GMT+01:00 vincent(a)massol.net :
>> > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
>> > jeremie.bousquet(a)gmail.com
>> > > > (mailto:jeremie.bousquet@gmail.com)) wrote:
>> > > >
>> > > > > Hi,
>> > > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
>> > > > > >
>> > > > > > Hi Vincent,
>> > > > > >
>> > > > > > On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru (
>> enygma2002(a)gmail.com
>> > > > (mailto:
>> > > > > > > enygma2002(a)gmail.com)) 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/HomepageProposal7Distrbutio…
> > > > > > > >
> > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume
"Louis-Marie"
> > > > Delhumeau <
> > > > > > > > gdelhumeau(a)xwiki.com> 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
>> > > > devs(a)xwiki.org
>> > > > http://lists.xwiki.org/mailman/listinfo/devs
>> > > >
>> > > _______________________________________________
>> > > devs mailing list
>> > > devs(a)xwiki.org
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> > >
>> > _______________________________________________
>> > devs mailing list
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>>
>>
>>
>> --
>> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8 Nov
8 Nov
2:31 p.m.
On Thu, Nov 6, 2014 at 2:24 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Nov 6, 2014 at 1:13 PM, vincent(a)massol.net
<vincent(a)massol.net>
wrote:
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.
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
On 6 Nov 2014 at 12:58:48, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) 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
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).
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 <
> mariusdumitru.florea(a)xwiki.com>gt;:
>
> > 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
<
> > > gdelhumeau(a)xwiki.com> 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/HomepageProposal4Setthispag…
> > >> >
> > >> > On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET <
> > >> > jeremie.bousquet(a)gmail.com> wrote:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > 2014-10-28 21:08 GMT+01:00 vincent(a)massol.net :
> > >> > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
> > >> > jeremie.bousquet(a)gmail.com
> > >> > > > (mailto:jeremie.bousquet@gmail.com)) wrote:
> > >> > > >
> > >> > > > > Hi,
> > >> > > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a
écrit :
> > >> > > > > >
> > >> > > > > > Hi Vincent,
> > >> > > > > >
> > >> > > > > > On Mon, Oct 27, 2014 at 11:05 AM,
vincent(a)massol.net
> > >> > > > > > wrote:
> > >> > > > > >
> > >> > > > > > > Hi,
> > >> > > > > > >
> > >> > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru
(
> > >> enygma2002(a)gmail.com
> > >> > > > (mailto:
> > >> > > > > > > enygma2002(a)gmail.com)) 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/HomepageProposal7Distrbutio…
> > >> > > > > > >
>
> > >> > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM,
Guillaume
"Louis-Marie"
> > >> > > > Delhumeau <
> > >> > > > > > > > gdelhumeau(a)xwiki.com> 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
>> > > > devs(a)xwiki.org
>> > > > http://lists.xwiki.org/mailman/listinfo/devs
>> > > >
>> > > _______________________________________________
>> > > devs mailing list
>> > > devs(a)xwiki.org
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> > >
>> > _______________________________________________
>> > devs mailing list
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>>
>>
>>
>> --
>> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10 Nov
10 Nov
3:04 p.m.
On Thu, Nov 6, 2014 at 1:57 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> 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 <
mariusdumitru.florea(a)xwiki.com>gt;:
On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 <
gdelhumeau(a)xwiki.com> wrote:
> 2014-11-05 14:43 GMT+01:00 Eduard Moraru <enygma2002(a)gmail.com>om>:
>
> > 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/HomepageProposal4Setthispag…
> >
>> > On Wed, Oct 29,
2014 at 6:10 PM, Jeremie BOUSQUET <
>> > jeremie.bousquet(a)gmail.com> wrote:
> >
>> > > Hi,
>> > >
>> > > 2014-10-28 21:08 GMT+01:00 vincent(a)massol.net
<vincent(a)massol.net>et>:
>> > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
>> > jeremie.bousquet(a)gmail.com
>> > > > (mailto:jeremie.bousquet@gmail.com)) wrote:
>> > > >
>> > > > > Hi,
>> > > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
>> > > > > >
>> > > > > > Hi Vincent,
>> > > > > >
>> > > > > > On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru (
>> enygma2002(a)gmail.com
>> > > > (mailto:
>> > > > > > > enygma2002(a)gmail.com)) 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/HomepageProposal7Distrbutio…
> > > > > > > >
> > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume
"Louis-Marie"
> > > > Delhumeau <
> > > > > > > > gdelhumeau(a)xwiki.com> 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
>> > > > devs(a)xwiki.org
>> > > > http://lists.xwiki.org/mailman/listinfo/devs
>> > > >
>> > > _______________________________________________
>> > > devs mailing list
>> > > devs(a)xwiki.org
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> > >
>> > _______________________________________________
>> > devs mailing list
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>>
>>
>>
>> --
>> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:27 p.m.
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 <
mariusdumitru.florea(a)xwiki.com> wrote:
On Thu, Nov 6, 2014 at 1:57 PM, Guillaume
"Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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 <
mariusdumitru.florea(a)xwiki.com>gt;:
> On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru <enygma2002(a)gmail.com>
> 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
<
> > gdelhumeau(a)xwiki.com> wrote:
> >
> >> 2014-11-05 14:43 GMT+01:00 Eduard Moraru <enygma2002(a)gmail.com>om>:
> >>
> >> > 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/HomepageProposal4Setthispag…
> >> >
> >> > On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET <
> >> > jeremie.bousquet(a)gmail.com> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > 2014-10-28 21:08 GMT+01:00 vincent(a)massol.net <
vincent(a)massol.net>gt;:
> >> > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
> >> > jeremie.bousquet(a)gmail.com
> >> > > > (mailto:jeremie.bousquet@gmail.com)) wrote:
> >> > > >
> >> > > > > Hi,
> >> > > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit
:
> >> > > > > >
> >> > > > > > Hi Vincent,
> >> > > > > >
> >> > > > > > On Mon, Oct 27, 2014 at 11:05 AM,
vincent(a)massol.net
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > Hi,
> >> > > > > > >
> >> > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru (
> >> enygma2002(a)gmail.com
> >> > > > (mailto:
> >> > > > > > > enygma2002(a)gmail.com)) 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/HomepageProposal7Distrbutio…
> >> > > > > > > >
> >> > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM,
Guillaume
"Louis-Marie"
> >> > > > Delhumeau <
> >> > > > > > > > gdelhumeau(a)xwiki.com> 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
> > > > devs(a)xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3598
days inactive
3631
days old
22 comments
7 participants
participants (7)
-
Denis Gervalle -
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Jeremie BOUSQUET -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net