On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru <[email protected]> wrote:
> The problem with the current place is that it is not really natural and > thus not very discoverable at all. I have this feeling to. I wanted to edit the descriptor of a subwiki a few days ago and I was surprised I could find anything related in the subwiki administration. > If you have to set the homepage, owner, > etc of your wiki, you go to administration, but never to "wiki index > edit > wiki". > > I believe that along this thread we have identified that these settings are > valuable for both the main wiki and subwikis so this makes editing the wiki > descriptor a valuable and deserving section to be introduced in > administration, don`t you agree? > > Thanks, > Eduard > > On Wed, Nov 5, 2014 at 4:38 PM, Guillaume "Louis-Marie" Delhumeau < > [email protected]> wrote: > >> 2014-11-05 14:43 GMT+01:00 Eduard Moraru <[email protected]>: >> >> > Concerning UC3 and UC4, we should not re-invent the wheel. I have just >> > remembered about the fact that we already have the option of setting the >> > homepage of a wiki exposed in the wiki's descriptor, so this makes is >> > already configurable. >> > >> > All we need to do now, is to expose this configuration further, in >> > Administration > Configuration, under Wiki section (just like it was for >> > workspaces, no idea why we removed it when refactoring to 'wikis'), >> >> >> About this setting in particular it is because it is part of the wiki >> descriptor, and we now have only one place to edit these properties. >> >> >> > where >> > you can select what is the homepage of your current wiki. Selecting the >> > owner and basically all the other stuff that you have in a wiki >> descriptor >> > should be done at this same level, since these are very important >> > configurations that one needs to perform for either his main wiki or >> > subwiki. >> > >> > And no, the xwiki-platform-wiki module is not optional (it is part of the >> > wiki model!), so no point in using a configurable class and throwing it >> > back in the 'Applications' section. >> > >> > This actually goes along the lines of 'Proposal4: Set this page as >> > homepage' [1], but done in Administration, not on every page, like >> Vincent >> > suggested. >> > >> > To get the homepage, apps need to do: >> > $services.wiki.getById($services.wiki.currentWikiId).mainPageReference >> > Of course, this can be improved to >> > $services.wiki.currentWikiDescriptor.mainPageReference >> > >> > We will be still having the backwards compatibility concerns of P4, >> however >> > I am sure that practical solutions (e.g. making Main.WebHome redirect to >> > $services.wiki.getById($services.wiki.currentWikiId).mainPageReference, >> > etc.) can be found if problems arise in daily use. >> > >> > WDYT? >> > >> > ---------- >> > [1] >> > >> > >> http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal4Setthispageashomepage >> > >> > On Wed, Oct 29, 2014 at 6:10 PM, Jeremie BOUSQUET < >> > [email protected]> wrote: >> > >> > > Hi, >> > > >> > > 2014-10-28 21:08 GMT+01:00 [email protected] <[email protected]>: >> > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET ( >> > [email protected] >> > > > (mailto:[email protected])) wrote: >> > > > >> > > > > Hi, >> > > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit : >> > > > > > >> > > > > > Hi Vincent, >> > > > > > >> > > > > > On Mon, Oct 27, 2014 at 11:05 AM, [email protected] >> > > > > > wrote: >> > > > > > >> > > > > > > Hi, >> > > > > > > >> > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru ( >> [email protected] >> > > > (mailto: >> > > > > > > [email protected])) wrote: >> > > > > > > >> > > > > > > > Hi, >> > > > > > > > >> > > > > > > > 2 new proposals (P6 and P7) have been made recently. I did >> not >> > > yet >> > > > get >> > > > > > > the >> > > > > > > > chance to add comments/analysis on them. Feel free to do it >> in >> > > the >> > > > > > > > meanwhile if anybody wants to. >> > > > > > > > >> > > > > > > > A few notes on Jeremie's "Proposal7: DistrbutionWizard sets >> the >> > > > > homepage >> > > > > > > of >> > > > > > > > a flavor and the Help App teaches users" [2]: >> > > > > > > > >> > > > > > > > Personally, I find it a rather elegant solution based on >> > > > separation of >> > > > > > > > concerns. However, you need to be aware that it is a >> > medium/long >> > > > term >> > > > > > > > objective. >> > > > > > > > >> > > > > > > > The way I understood it is that we delegate the task of >> > choosing >> > > a >> > > > > > > homepage >> > > > > > > > to the DistributionWizard that will most likely be in charge >> of >> > > > > offering >> > > > > > > > the user flavor options. At that point, the homepage of the >> > > current >> > > > > wiki >> > > > > > > > will be the homepage of the user selected flavor. Optionally, >> > we >> > > > can >> > > > > also >> > > > > > > > propose to use a blank page as homepage if the user wants, >> > > however >> > > > > this >> > > > > > > > might be a bit of an overkill, since the user can easily edit >> > the >> > > > page >> > > > > > > and >> > > > > > > > trash everything. >> > > > > > > >> > > > > > > The DW should not know at all about any page. It should be up >> to >> > > the >> > > > > > > flavor to define the wiki pages it will contain and install. >> Each >> > > > flavor >> > > > > > > should propose its own home page. >> > > > > > > >> > > > > > >> > > > > > Maybe I did not choose the best words, but the way I understood >> it >> > > (and >> > > > > > tried to reformulate it) was not that the DW explicitly allows >> you >> > to >> > > > > > select a homepage, but that indirectly, through allowing you to >> > > > install a >> > > > > > flavor, it will additionally do the job (again, indirectly) of >> > making >> > > > you >> > > > > > choose a homepage (through the flavor you have selected). >> > > > > >> > > > > Yes that was the idea, possibly: >> > > > > - DW doesn't have to know pages or set homepage >> > > > > - there could be a new wizard, similar to wizards for new page / >> > space >> > > > from >> > > > > template, that allows choosing a kind of homepage (empty, wiki >> > > concepts, >> > > > > dashboard, etc) >> > > > > - a flavor also adds its homepage as a possible "template" >> > > > > - btw it could be exactly the new space from template page, but >> with >> > > more >> > > > > choices than current (empty / dashboard) >> > > > > - following a dw run and a flavor installation, this "new Main >> space >> > > > > homepage from template" wizard is triggered and displayed (or just >> > > > proposed >> > > > > to user through a button or link), and allows user to either choose >> > > > default >> > > > > homepage of the flavor, or use another one >> > > > > - current (or reworked) homepage is just the default home of the >> > > default >> > > > > flavor (which is the current XE xar) >> > > > >> > > > ok but: >> > > > >> > > > 1) it’s complex since it means that a flavor would need to register >> > some >> > > > kind of post install script to execute (which is something we don’t >> > > really >> > > > have) >> > > > >> > > >> > > Depends, I was thinking more about a specific event like "flavor >> > installed" >> > > or "extension installed" or "wiki installed / updated". I'm not sure to >> > get >> > > what you would need to do in this post install script ? >> > > But it could be completely "manual" or just a link at the end of DW to >> > some >> > > possible post-install stuff (like, consult help, manage home page, >> etc). >> > > >> > > I'd like to apologize here because my "proposal" was more an idea than >> a >> > > well formalized proposal, even if it ended up in the list of proposals, >> > > it's obvious that it misses some thoughts and clarifications... (I >> > > understand your -1). >> > > >> > > >> > > > 2) it negates a bit the point of a flavor which is to propose a >> defined >> > > > “theme” and thus a defined home page matching that theme >> > > > >> > > >> > > Well, if you consider that current UI of XE is the default xwiki >> > "flavor", >> > > this is exactly what it's about when we talk about switching home page >> > > easily, isn't it ? We want to let user set a home page that doesn't >> match >> > > the default theme freely. Obviously this default theme is not very >> > > "thematic" as it's the default and should be versatile ... >> > > Home page matching that theme could still be the mostly recommended >> > choice. >> > > BTW a flavor, with such mechanism, could provide several "home page" >> > > variants and not only one, depending on the case. >> > > If I take the case of a flavor based on the Mail archive (or the mail >> > > archive extension alone, say), it already provides different views as >> the >> > > app home page (timeline, livetable, etc). Currently the switch is done >> > > through conditional include. Currently that app home page is >> > > MailArchive.WebHome, if I could register it as a possible home page >> > > template, it would avoid having to rename it "Main.WebHome" to make it >> a >> > > flavor (and potentially destroy existing wiki home page by mistake when >> > you >> > > install that extension/flavor), and I could fullfill both installation >> > > use-cases (of using it as an app among others in some wiki, and as a >> > > wiki-wide-flavor in another wiki or subwiki), from the same xar bundled >> > > app. >> > > Again, here, I talk about possibilities and use-cases that seem logical >> > or >> > > interesting to me if I dig into my proposal, but I really don't know if >> > > it's a good path or even a good idea for xwiki - I may not have the big >> > > picture :) >> > > Also, the proposal certainly does not offer any solution for short-term >> > (if >> > > you consider it provides options for long-term ;-) ) >> > > >> > > >> > > > 3) it doesn’t solve anything since once you select a default homepage >> > you >> > > > still need a way to change it afterwards if you want to change it… >> > > > >> > > >> > > There was the side-idea of the proposal (not well formulated, maybe was >> > > just in my mind) that this wizard and/or DW could be triggered at any >> > later >> > > time by an admin if he wants to replace homepage with some other >> > "default" >> > > content. Maybe could be seen as a "personalization" step following a >> new >> > > wiki install or upgrade, but that could be triggered at any later time >> to >> > > "re-personalize" his wiki. I would put this then also as a feature in >> > admin >> > > UI. >> > > The difference with some other proposals, is that it would not be an >> > action >> > > available from the standard UI but limited to a post-install step and >> the >> > > admin UI (not like the variant below). >> > > >> > > >> > > > >> > > > I don’t see how this is much better than having a Admin UI allowing >> you >> > > to >> > > > change the home page you wish to have. However it’s a lot more >> complex >> > > (and >> > > > really marginally better). >> > > > >> > > > > Maybe instead of all this, it could be enough to unrelate the "new >> > > space" >> > > > > and "apply space homepage template" features ? >> > > > > So I would just have to call "space / apply template" to replace >> the >> > > > > homepage of any space already existing (including Main obviously) ? >> > > > >> > > > Yes that’s better already IMO but then it should be a menu option to >> > > > replace any page content with a page template. >> > > > >> > > >> > > I'm not sure if you talk about an additional option, or an option that >> > > would replace the "space /apply template" by a more generic "page / >> apply >> > > template", but I don't think anyway that a page template is the same >> > thing >> > > as a home page template (whether it's a space or wiki home page). You'd >> > > seldom want to use a blog post as a home page ... >> > > >> > > In this variant, there's still the question, if applying such template >> is >> > > considered an admin operation or not. If it's an admin operation, you >> > also >> > > proposed to start moving those admin actions to the admin UI, which is >> - >> > > sort of - what was my proposal about in first place :) (I didn't talk >> > > specifically about admin UI at that time, but about avoiding to crowd >> > > standard UI menus with unfrequent/admin operations). >> > > That being said I don't think it's an admin action, if you need to >> > protect >> > > home page, as an admin you can set specific rights and forbid this >> "apply >> > > template" to people that don't have those edit rights. I'm not sure >> > editing >> > > home page and applying a template should really be different in terms >> of >> > > privileges. But applying a template on an existing page or home page, >> > seems >> > > to be a rather unfrequent operation. >> > > >> > > >> > > > >> > > > >> > > > Thanks >> > > > -Vincent >> > > > >> > > > > > It was just a high level view on the direction to follow, and >> not a >> > > > > > specific technical aspect, so no reason to -1 it, right? >> > > > > > >> > > > > > >> > > > > > > BTW there’s also another variation for the home page that >> hasn’t >> > > been >> > > > > > > discussed yet: >> > > > > > > * Make the home page special by not making it editable (and >> > without >> > > > any >> > > > > > > docextra tabs at the bottom). So no rollback issue/edit >> > weirdness. >> > > > > > > * Only admins can change it and only through the Admin UI >> > > (basically >> > > > > > > decide which space home page to display on the wiki home page). >> > > > > > > * Somewhere in the content of the default home page or through >> > the >> > > > first >> > > > > > > time wizard, direct the users to the Sandbox page to try it out >> > > > editing >> > > > > > > (since this is what Sandbox is for!) >> > > > > > > >> > > > > > >> > > > > > Adding this too and I think we`re good for going forward with a >> > vote, >> > > > > since >> > > > > > we have plenty of proposals. >> > > > > > >> > > > > > Thanks, >> > > > > > Eduard >> > > > > > >> > > > > > > >> > > > > > > Thanks >> > > > > > > -Vincent >> > > > > > > >> > > > > > > > The task of teaching the user is delegated exclusively to the >> > > Help >> > > > > > > > Application, with the note that the application will also be >> > > > proposed >> > > > > to >> > > > > > > > the user to be redirected to, as a final step in the DW >> (after >> > > the >> > > > > > > > installation of the user selected flavor is complete). >> > > > > > > > >> > > > > > > > All of this assumes that we have a properly working Flavors >> > > feature >> > > > > and >> > > > > > > > Help Application. However, what should we do in the meanwhile >> > for >> > > > the >> > > > > > > > default XWiki Enterprise UI / Flavor / build? Should we >> > postpone >> > > > yet >> > > > > > > again >> > > > > > > > any work on the homepage until we have the needed elements to >> > > > delegate >> > > > > > > the >> > > > > > > > problematic aspects, or should we do something about it in >> the >> > > > > meanwhile? >> > > > > > > > >> > > > > > > > Thanks, >> > > > > > > > Eduard >> > > > > > > > >> > > > > > > > ---------- >> > > > > > > > [1] >> > > > http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals >> > > > > > > > [2] >> > > > > > > > >> > > > > > > >> > > > > >> > > > >> > > >> > >> http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7DistrbutionWizardsetsthehomepageofaflavorandtheHelpAppteachesusers >> > > > > > > > >> > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume "Louis-Marie" >> > > > Delhumeau < >> > > > > > > > [email protected]> wrote: >> > > > > > > > >> > > > > > > > > Hello. >> > > > > > > > > >> > > > > > > > > I have again a new argument against using the dashboard and >> > the >> > > > > include >> > > > > > > > > macro in the main page. >> > > > > > > > > >> > > > > > > > > When the user uses the "Inline" editor to change some >> > gadgets, >> > > > she >> > > > > can >> > > > > > > not >> > > > > > > > > use the rollback action of the main page to cancel her >> > changes. >> > > > She >> > > > > > > has to >> > > > > > > > > go to the Dashboard page first, and then rollback her >> changes >> > > > from >> > > > > > > there. >> > > > > > > > > >> > > > > > > > > Having an include macro in the default page is absolutely >> not >> > > > > > > intuitive, >> > > > > > > > > even if you make it appears more clearly. >> > > > > > > > > >> > > > > > > > > Thanks, >> > > > > > > > > Guillaume >> > > > _______________________________________________ >> > > > devs mailing list >> > > > [email protected] >> > > > http://lists.xwiki.org/mailman/listinfo/devs >> > > > >> > > _______________________________________________ >> > > devs mailing list >> > > [email protected] >> > > http://lists.xwiki.org/mailman/listinfo/devs >> > > >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> > >> >> >> >> -- >> Guillaume Delhumeau ([email protected]) >> Research & Development Engineer at XWiki SAS >> Committer on the XWiki.org project >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
