[xwiki-devs] Proposal for 5.3: New Wiki module
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 = Options = * In your wiki, do you want to have the "Home" menu? * In your wiki, do you want to create your own users? = XARs and template = * The home menu is enabled only if the user want it (trivial) * The registration button should redirect to the home wiki depending on the configuration (trivial) * Disable XWiki.AdminRegistrationSheet, XWiki.AdminUsersSheet from the Administration (depending on the configuration) * Create a new UI, partially based on the current WorkspaceManager and WikiManager spaces. = 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-mo...) = 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() ** xwiki-platfrom-wiki-user (handle or not the local users) *** WikiUsersManager.java **** canWikiHasLocalUsers() **** setCanWikiHasLocalUsers() **** getWikiOwner() **** setWikiOwner() **** getMembershipType() (join/invite only/ask to join) **** setMembershipType() **** getWikiUsers() (list of the local users + those who are 'members' of the wiki) ** 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()? ** xwiki-platform-wiki-ui (pages for both the home AND the (sub)wikis) *** ... + 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? Thanks, Louis-Marie
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-mo...)
= 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() **** 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
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-mo...)
= 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!
**** setCanWikiHasLocalUsers()
Ouch… Suggestion: hasLocalUsers(boolean) or supportsLocalUsers(boolean).
OK.
**** 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.
** 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
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-mo...)
= 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. 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
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-mo...)
= 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?
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
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-mo...)
= 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
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-mo...)
= 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
participants (4)
-
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Vincent Massol