On Tue, Oct 1, 2013 at 5:09 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
> Hi Eddy! > > 2013/10/1 Eduard Moraru <[email protected]> > > > On Tue, Oct 1, 2013 at 3:25 PM, Guillaume "Louis-Marie" Delhumeau < > > [email protected]> wrote: > > > > > Hi Vincent, > > > > > > My comments below: > > > > > > 2013/10/1 Vincent Massol <[email protected]> > > > > > > > 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? > > > > > > > > > > Yes, but we can refine this concept. We could imagine that hidden wikis > > > should be visible by administrators only. > > > > > > > > > > > > > > > = 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. > > > > > > > > > > OK. > > > > > > > > > > > > > > > = 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? > > > > > > > > > > It is why I meant. > > > > > > > > > > > > > > > * 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? :) > > > > > > > > > > Not for now ;) > > > > > > > > > > > > > > > = 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? > > > > > > > > > > Yes, it is. Because in the future, we will have the notion of > "flavors", > > so > > > we may decide to not use template wiki anymore. I wanted to have a > > minimal > > > wiki-manager module and some optional ones. > > > > > > > > > > > > > > > ** xwiki-platfrom-wiki-user (handle or not the local users) > > > > > *** WikiUsersManager.java > > > > > **** canWikiHasLocalUsers() > > > > > > > > Bad name! Suggestion: hasLocalUsers() or supportsLocalUsers() > > > > > > > > > > I prefer supportsLocalUsers(), because it can return true even if there > > is > > > actually no users in the wiki! > > > > > > > Another suggestion: hasLocalUsersSupport() > > - respects the has* convention for boolean methods > > - leaves room for a hasLocalUsers() method if we might need it > > > > Alternatives: > > - isLocalUsersEnabled() > > - hasLocalUsersEnabled() > > > > Just pick one :) > > > > > > > > > > > > > > > > **** setCanWikiHasLocalUsers() > > > > > > > > Ouch… Suggestion: hasLocalUsers(boolean) or > > supportsLocalUsers(boolean). > > > > > > > > > > > > OK. > > > > > > > Bad suggestion, IMO, using has* to set* something :) > > > > Try: > > - setLocalUsersSupport(boolean) > > - setLocalUsersEnabled(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? > > > > > > > > > > Yes. Someone might want to build a wiki with absolutely no notion of > > users. > > > > > > > What about the notion of members? (from workspaces) > > > > The difference is that we used rights to express members (global users > with > > rights on the current workspace) and the entire UI talks about membership > > and members to a workspace/wiki. > > > > In my proposal, API WikiUsersManager#getWikiUsers() returns both local > users and global users that are members of the wiki. Do you think we should > subdivide this notion? > The discussion was about the membership notion. I`m not sure we should use the term 'users' as in 'getWikiUsers' to express membership, when, in XWiki, a 'user' of a wiki means the user that is local to that wiki. If we have hasLocalUsersSupport() (or whatever we choose) returning 'true', then a call to getLocalUsers() should return the list of local users. However, this should not necessarily be the task of the wiki module, but of some 'xwiki-platform-users-api' module that we should implement in the future to properly implement user management in XWiki at an API level. We`re doing bad in this sector :) For now, I`d suggest that we have: - getLocalUsers() (only local wiki users, to be used together with hasLocalUsersSupport() ) - getMembers() (members of the XWikiAllGroup of the local wiki, since that is the current way we track membership. This will include what you were proposing, both global and local users.) -- I`m not sure at this point about the naming, either 'members' or 'users', since we want to both have a generic solution and to have a good separation of concerns. If we drop the separation of concerns (see above mention of a future 'xwiki-platform-users-api' module), then we can call it 'users' in both cases (farm/workspace) and applications use only one method. Hope this helps, Eduard > > > > > > Hope this helps, > > Eduard > > > > > > > > > ** xwiki-platform-wiki-script (for script services) > > > > *** Wiki.java (only an helper) > > > > **** getDescriptor() > > > > **** getId() > > > > **** getAlias() > > > > **** addAlias() > > > > **** removeAlias() > > > > **** getReference() > > > > **** IsTemplate() > > > > **** setIsTemplate() > > > > **** getOwner() > > > > **** setOwner() > > > > **** canHasLocalUsers() > > > > **** 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). > > > > > > > > > + 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 > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > Thanks, > Louis-Marie > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
