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 < [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
