1 Oct
2013
1 Oct
'13
4:09 p.m.
Hi Eddy!
2013/10/1 Eduard Moraru <enygma2002(a)gmail.com>
On Tue, Oct 1, 2013 at 3:25 PM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> > = 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
> > = 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
> > * Disable
XWiki.AdminRegistrationSheet, XWiki.AdminUsersSheet from the
Not for now ;)
https://github.com/xwiki/xwiki-platform/compare/feature-resource-and-wiki-m…
so
> > ****
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
> 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?
Hi Vincent,
My comments below:
2013/10/1 Vincent Massol <vincent(a)massol.net>
> Hi Guillaume,
> On Oct 1, 2013, at 12:21 PM,
Guillaume Louis-Marie Delhumeau <
> gdelhumeau(a)xwiki.com> wrote:
> > Hi devs !
> > > In 5.2, we have introduced
Workspace Application in XE. Now, we
should
go
know
> 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 that
appear
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 in searches/etc, right?
Yes, but we can refine this concept. We could imagine that hidden wikis
should be visible by administrators only.
then
global users would work too, in addition to the ability to create
local users.
OK.
> the
> > configuration (trivial)
> Why based on configuration? Why not
redirect automatically when the
user
doesn't allow local users?
It is why I meant.
> > 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:
>
> > = 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", we may decide to not use template wiki anymore. I
wanted to have a
minimal
wiki-manager module and some optional ones.
I prefer supportsLocalUsers(), because it can return true even if there
is
** xwiki-platfrom-wiki-user (handle or not the
local users)
*** WikiUsersManager.java
**** canWikiHasLocalUsers()
Bad name! Suggestion: hasLocalUsers() or supportsLocalUsers()
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 :)
OK.
Bad suggestion, IMO, using has* to set* something :)
Try:
- setLocalUsersSupport(boolean)
- setLocalUsersEnabled(boolean)
> descriptor.
> Since you put this in a separate
module, does it mean you want to see
it
> > as some optional module?
Hope this helps,
Eduard
(sub)wikis)
One
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks,
Louis-Marie
** 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 > > *** …
>
> 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? > 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs