6 Nov
2014
6 Nov
'14
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