On Tue, Oct 1, 2013 at 2:16 PM, Vincent Massol <[email protected]> wrote: > Hi Guillaume, > > On Oct 1, 2013, at 12:21 PM, Guillaume Louis-Marie Delhumeau > <[email protected]> wrote: > >> Hi devs ! >> >> In 5.2, we have introduced Workspace Application in XE. Now, we should go >> further and merge Wiki Application with Workspaces. >> >> = New idea = >> * Add a "hidden" field to the Wiki. For example, I would like to be able to >> create wiki: >> ** which can not be seen by others >> ** which does not appear in searches >> ** e.g: workspacetemplate, or on a farm if I don't want people to know that >> I host a company AND its competitor > > So if i understand correctly: > * This "hidden" field would be in the wiki descriptor right? > * If the user selects "show hidden documents" (which might need to be renamed > to something more generic now) the wiki would be visible and appear in > searches/etc, right? > >> = Options = >> * In your wiki, do you want to have the "Home" menu? > > See comments on http://jira.xwiki.org/browse/XWIKI-9518 > >> * In your wiki, do you want to create your own users? > > I would not phrase it like this. Rather: "Allow local users". If enabled then > global users would work too, in addition to the ability to create local users. > >> = XARs and template = >> * The home menu is enabled only if the user want it (trivial) > > How is that different from above (ie http://jira.xwiki.org/browse/XWIKI-9518)? > >> * The registration button should redirect to the home wiki depending on the >> configuration (trivial) > > Why based on configuration? Why not redirect automatically when the user > doesn't allow local users? > >> * Disable XWiki.AdminRegistrationSheet, XWiki.AdminUsersSheet from the >> Administration (depending on the configuration) > > Ok so if the wiki doesn't allow local users then don't show admin options > related to users. Good. > >> * Create a new UI, partially based on the current WorkspaceManager and >> WikiManager spaces. > > Any more details on this? :) > >> = API = >> * Create a new API: xwiki-platform-wiki. >> * The old modules (xwiki-platform-wiki-manager and >> xwiki-platform-workspace) go into legacy, and we mark them as deprecated. >> * The new API will use the new modules of Vincent: >> https://github.com/xwiki/xwiki-platform/compare/feature-resource-and-wiki-modules(wiki-descriptor) >> >> = Proposal for the API = >> * xwiki-platform-wiki >> ** xwiki-platform-wiki-descriptor >> *** xwiki-platform-wiki-descriptor-api >> **** WikiDescriptor.java >> ***** ID >> ***** Alias >> ***** Hidden >> ***** Description? >> ***** Ability to add custom data (where all will be stored) >> **** WikiDescriptorManager.java >> ***** getAll() >> ***** set() >> ***** remove() >> ***** getByWikiAlias() >> ***** getByWikiId() >> ** xwiki-platform-wiki-manager (but this name conflicts with the previous >> module that we put into legacy...) >> *** WikiManager.java >> **** createWiki() (create an empty wiki) >> **** deleteWiki() >> **** copyWiki() >> ** xwiki-platform-wiki-template >> *** WikiTemplateManager.java >> **** setWikiAsTemplate() >> **** unsetWikiAsTemplate() >> **** getWikiTemplates() >> **** isWikiTemplate() > > What is the rationale for 2 modules instead of one for > xwiki-platform-wiki-manager and xwiki-platform-wiki-template? (not saying > it's bad, just curious) > > Is it because you want to see template wiki as something optional? > >> ** xwiki-platfrom-wiki-user (handle or not the local users) >> *** WikiUsersManager.java >> **** canWikiHasLocalUsers() > > Bad name! Suggestion: hasLocalUsers() or supportsLocalUsers() > >> **** setCanWikiHasLocalUsers() > > Ouch… Suggestion: hasLocalUsers(boolean) or supportsLocalUsers(boolean). > >> **** getWikiOwner() >> **** setWikiOwner() >> **** getMembershipType() (join/invite only/ask to join) >> **** setMembershipType() >> **** getWikiUsers() (list of the local users + those who are >> 'members' of the wiki) > > Whether the wiki accepts local users or not should be stored in the wiki > descriptor. > > Since you put this in a separate module, does it mean you want to see it as > some optional module? > >> ** xwiki-platform-wiki-script (for script services) >> *** Wiki.java (only an helper) >> **** getDescriptor() >> **** getId() >> **** getAlias() >> **** addAlias() >> **** removeAlias() >> **** getReference() >> **** IsTemplate() >> **** setIsTemplate() >> **** getOwner() >> **** setOwner()
>> **** canHasLocalUsers() I need this (renamed as suggested by Edy) for http://jira.xwiki.org/browse/XWIKI-9479 . >> **** setCanHasLocalUsers() >> **** getMembershipType() >> **** setMembershipType() >> **** getUsers() >> **** isHidden() >> **** setHidden() >> **** getDescription() >> **** setDescription() >> *** WikiManagerScript.java ("$services.wikimanager" but the name >> conflicts with the previous module...) >> **** getAllWikis() >> **** getHomeWiki() >> **** getWikiByAlias() >> **** getWikiById() >> **** getWikiTemplates() >> **** createWiki() >> **** deleteWiki() >> **** copyWiki() >> **** isWikiExists() >> **** isWikiNameAvailable() >> **** joinWiki()? >> **** askToJoinWiki()? > > -1. All script services should be located in the modules they wrap. > > So if you have 4 modules, I see 4 script services (located in a script > package in those modules). > > You cannot say that the modules are optional and then have a big script > module that contains everything. It'll obviously not work :) > > Example: I don't have xwiki-platfrom-wiki-user JAR, I shouldn't be able to > call $services.<name>.canHasLocalUsers() > >> ** xwiki-platform-wiki-ui (pages for both the home AND the (sub)wikis) >> *** … > > Need to verify that the UI pages are not related to a given module above. If > so then that module should have its own UI module to make it optional. > > To summarize: > * Either the modules above are optional and they need to be fully optional > (api, script service, UI) > * Or they're not optional and why do we need to have so many modules? One > would be enough (with possibly different packages though). I think too that one module is enough in this case for the wiki related APIs. Thanks, Marius > >> + write tests >> + need a migration path >> + in the future: >> * Create a new wiki from a flavor: >> ** instead of creating a wiki from a template, you give an extension ID >> >> If you like this proposal, I will try to implement it as close it is >> possible, but I may change some elements to minimize dependencies. I will >> tell you. >> >> WDYT? > > Sounds good in general. > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
