Ok. So as far as I can see, it`s quite clear that the changing of homepage needs to be done from the wiki administration section. It can me done now too (by editing wiki descriptors), but it needs a bit more work until it`s just right for everybody.
So UC3/4 are out of the discussion, leaving the remaining Use Cases as the subject of this thread and proposals. Thanks, Eduard P.S.: Please feel free to correct me if I`m wrong and if you have something against a wiki administration section for handling the selection of a homepage. On Mon, Nov 10, 2014 at 4:04 PM, Marius Dumitru Florea < [email protected]> wrote: > On Thu, Nov 6, 2014 at 1:57 PM, Guillaume "Louis-Marie" Delhumeau > <[email protected]> wrote: > > We had this discussion one year ago with Vincent. He wanted to go in the > > direction where everything is an application with a proper UI and not > > necessary in the administration. > > > > > Moreover, it is very important to be able to modify a descriptor from the > > main wiki instead of the subwiki, since if you break it, you might be > > unable to access your subwiki anymore! > > It is also very important that a local (subwiki) admin is able to > modify (some) fields from the wiki descriptor (like the home page) > without having access to the main wiki. The fact that the wiki > descriptor is stored in the main wiki is an implementation detail. > > Thanks, > Marius > > > > > > > 2014-11-06 11:10 GMT+01:00 Marius Dumitru Florea < > > [email protected]>: > > > >> On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru <[email protected]> > >> wrote: > >> > >> > The problem with the current place is that it is not really natural > and > >> > thus not very discoverable at all. > >> > >> I have this feeling to. I wanted to edit the descriptor of a subwiki a > >> few days ago and I was surprised I could find anything related in the > >> subwiki administration. > >> > >> > If you have to set the homepage, owner, > >> > etc of your wiki, you go to administration, but never to "wiki index > > >> edit > >> > wiki". > >> > > >> > I believe that along this thread we have identified that these > settings > >> are > >> > valuable for both the main wiki and subwikis so this makes editing the > >> wiki > >> > descriptor a valuable and deserving section to be introduced in > >> > administration, don`t you agree? > >> > > >> > Thanks, > >> > Eduard > >> > > >> > On Wed, Nov 5, 2014 at 4:38 PM, Guillaume "Louis-Marie" Delhumeau < > >> > [email protected]> wrote: > >> > > >> >> 2014-11-05 14:43 GMT+01:00 Eduard Moraru <[email protected]>: > >> >> > >> >> > Concerning UC3 and UC4, we should not re-invent the wheel. I have > just > >> >> > remembered about the fact that we already have the option of > setting > >> the > >> >> > homepage of a wiki exposed in the wiki's descriptor, so this makes > is > >> >> > already configurable. > >> >> > > >> >> > All we need to do now, is to expose this configuration further, in > >> >> > Administration > Configuration, under Wiki section (just like it > was > >> for > >> >> > workspaces, no idea why we removed it when refactoring to 'wikis'), > >> >> > >> >> > >> >> About this setting in particular it is because it is part of the wiki > >> >> descriptor, and we now have only one place to edit these properties. > >> >> > >> >> > >> >> > where > >> >> > you can select what is the homepage of your current wiki. Selecting > >> the > >> >> > owner and basically all the other stuff that you have in a wiki > >> >> descriptor > >> >> > should be done at this same level, since these are very important > >> >> > configurations that one needs to perform for either his main wiki > or > >> >> > subwiki. > >> >> > > >> >> > And no, the xwiki-platform-wiki module is not optional (it is part > of > >> the > >> >> > wiki model!), so no point in using a configurable class and > throwing > >> it > >> >> > back in the 'Applications' section. > >> >> > > >> >> > This actually goes along the lines of 'Proposal4: Set this page as > >> >> > homepage' [1], but done in Administration, not on every page, like > >> >> Vincent > >> >> > suggested. > >> >> > > >> >> > To get the homepage, apps need to do: > >> >> > > $services.wiki.getById($services.wiki.currentWikiId).mainPageReference > >> >> > Of course, this can be improved to > >> >> > $services.wiki.currentWikiDescriptor.mainPageReference > >> >> > > >> >> > We will be still having the backwards compatibility concerns of P4, > >> >> however > >> >> > I am sure that practical solutions (e.g. making Main.WebHome > redirect > >> to > >> >> > > >> $services.wiki.getById($services.wiki.currentWikiId).mainPageReference, > >> >> > etc.) can be found if problems arise in daily use. > >> >> > > >> >> > WDYT? > >> >> > > >> >> > ---------- > >> >> > [1] > >> >> > > >> >> > > >> >> > >> > http://design.xwiki.org/xwiki/bin/view/Proposal/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 > >> > > > > > > > > -- > > 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
