7 Oct
2013
7 Oct
'13
10:49 a.m.
Hi.
In this thread, I want to propose you the tiniest API that we need to
handle multiwiki. All other features (users, templates, workspaces...) will
be on other modules, because I think it is better for the extensibility.
The new module will be based on the xwiki-platform-wiki-descriptor-api
module, that I will rename to xwiki-platform-wiki-api. The
WikiDescriptorManager becomes WikiManager and handle both descriptors and
databases.
This API will permit:
* to create a wiki
* to remove a wiki
* to list all wikis (returning a list of descriptors)
* ...
You can see the code of that proposal there:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
The most important is to decide what the API must look like. The
implementation can still be modified afterwards.
I hope you like it,
Louis-Marie
7 Oct
7 Oct
3:34 p.m.
Hi Guilllaume,
1) What is the point of the WikiDescriptorAlias class if it just holds and
returns a string?
Also, the only method in the WikiDescriptorManager that works with aliases
accepts a String instead of the WikiDescriptorAlias class, so this means
that the class is useless:
WikiDescriptor getByWikiAlias(String wikiAlias) throws WikiManagerException;
2) WikiManager:
The methods wikiIdExists and and isWikiIdAvailable do the same thing, they
just call it differently. Use only one, like wikiExists().
Also, since it's a WikiManager, so the "wiki" part is in the name of the
class, we get it that it deals with wikis. You could remove the "wiki" part
from method names, like:
- create instead of createWiki
- delete instead of deleteWiki
- exists instead of existsWiki
- so on...
Note on the naming of methods:
I`ve noticed a rather annoying thing in the way the methods are named. So
you have a class that is say... WikiDescriptor.
3) WikiManager:
What is the point of these 2 methods?
void setDescriptor(WikiDescriptor descriptor);
void removeDescriptor(WikiDescriptor descriptor);
Looking at the implementation, I see that you`re handling descriptors
(setting/deleting) whithout corelating it to the wikis. I mean, if you
remove a descriptor, then you must remove the wiki too, and that is the
task of the WikiManager.delete() method.
4) Don`t use implementation details. Improve the interface (API) if there
is information you`re missing:
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
5) DefaultWikiManager.createDescritptor
Since you have a WikiDescriptorBuilder class, maybe that is where the logic
of creating/building the descriptor's details (objects, document) and where
the logic of extracting the document name from wiki name and viceversa
should be located.
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
6) DefaultWikiManager.getByWikiId
Again seeing the logic of wikiID-to-document. It should be located in a
single place and not spread in multiple places. Use a method of the
WikiManager class or of the DescriptorBuilder class.
7) WikiManagerScriptService:
- deleteWiki: Why do you need Admin right to delete a wiki when you did not
need it in order to create it? That`s bad. We should probably have a
deleteWiki right as well. Also, consider the workspaces use case when user
create and delete wikis/workspaces when they want to and when they are done
with them.
- context key for exceptions "lastexception2" is not the best of choices.
Try something like "wikiException" instead, or even just
"lastexception"
like it was before (if we consider this as a best practice). What's the
reason for "lastexception2"?
As a general note, I fail to see the added value of this module at this
point. I mean, the whole point was to have both the functionality of
WikiManager and Workspaces. I get it that it's a work in progress and that
it's at the first stages, but you need to touch those points before it
becomes relevant. Not that it's bad, just that it's not much there to see
at this point.
Hope this helps,
Eduard
On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Hi.
In this thread, I want to propose you the tiniest API that we need to
handle multiwiki. All other features (users, templates, workspaces...) will
be on other modules, because I think it is better for the extensibility.
The new module will be based on the xwiki-platform-wiki-descriptor-api
module, that I will rename to xwiki-platform-wiki-api. The
WikiDescriptorManager becomes WikiManager and handle both descriptors and
databases.
This API will permit:
* to create a wiki
* to remove a wiki
* to list all wikis (returning a list of descriptors)
* ...
You can see the code of that proposal there:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
The most important is to decide what the API must look like. The
implementation can still be modified afterwards.
I hope you like it,
Louis-Marie
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:33 p.m.
Hi Eddy.
First, thanks for your answer.
2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
Hi Guilllaume,
1) What is the point of the WikiDescriptorAlias class if it just holds and
returns a string?
Also, the only method in the WikiDescriptorManager
that works with aliases
accepts a String instead of the WikiDescriptorAlias class, so this means
that the class is useless:
WikiDescriptor getByWikiAlias(String wikiAlias) throws
WikiManagerException;
I did not really think about it, I just take the work done by Vincent on
wiki descriptors.
2) WikiManager:
The methods wikiIdExists and and isWikiIdAvailable do the same thing, they
just call it differently. Use only one, like wikiExists().
I should have added the javadoc about that. This is what I have in mind :
- wikiExists(String wikiOd) as you said
- wikiAvailable(String wikiId) that checks if the wiki id is valid and free
(that means that there is no existing database with that name -- not
necessary related to XWiki).
It is not implemented yet.
Also, since it's a WikiManager, so the "wiki" part is in the name of the
class, we get it that it deals with wikis. You could remove the "wiki" part
from method names, like:
- create instead of createWiki
- delete instead of deleteWiki
- exists instead of existsWiki
- so on...
I agree. I'll change it ;)
Note on the naming of methods:
I`ve noticed a rather annoying thing in the way the methods are named. So
you have a class that is say... WikiDescriptor.
Indeed, but a Wiki class would not contain something else than a
descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
3) WikiManager:
What is the point of these 2 methods?
void setDescriptor(WikiDescriptor descriptor);
void removeDescriptor(WikiDescriptor descriptor);
Looking at the implementation, I see that you`re handling descriptors
(setting/deleting) whithout corelating it to the wikis. I mean, if you
remove a descriptor, then you must remove the wiki too, and that is the
task of the WikiManager.delete() method.
I have keeped them because it is used in the descriptors implementation of
Vincent. But I agree that it is weird to have it in the API.
4) Don`t use implementation details. Improve the interface (API) if there
is information you`re missing:
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I disagree.
In this code, I need to have the document related to the descriptor. It
depends on the current implementation, because we can imagine an
implementation where the descriptors are not stored in the wiki. So I won't
add a getDocument() in the API, but I need it in my implementation.
5) DefaultWikiManager.createDescritptor
Since you have a WikiDescriptorBuilder class, maybe that is where the logic
of creating/building the descriptor's details (objects, document) and where
the logic of extracting the document name from wiki name and viceversa
should be located.
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I agree, I will move that code into WikiDescriptorBuilder.
6) DefaultWikiManager.getByWikiId
Again seeing the logic of wikiID-to-document. It should be located in a
single place and not spread in multiple places. Use a method of the
WikiManager class or of the DescriptorBuilder class.
OK.
7) WikiManagerScriptService:
- deleteWiki: Why do you need Admin right to delete a wiki when you did not
need it in order to create it? That`s bad. We should probably have a
deleteWiki right as well.
It is a temporary solution in my implementation.
The problem is: who has the right to remove a wiki ?
- his owner? But we don't have the notion of owner in this API. It belongs
to the wiki-users module to handle this concept.
- someone who has the CREATE_WIKI right? That means every person who has
the CREATE_WIKI right can also delete any existing wiki?
- someone who as the DELETE_WIKI right? Why not, but we need to make a vote
for adding this new right.
So, in my first implementation, I have used the admin right.
Also, consider the workspaces use case when user
create and delete wikis/workspaces when they want to and when they are done
with them.
To me, it belongs to the future wiki-user module.
- context key for exceptions
"lastexception2" is not the best of choices.
Try something like "wikiException" instead, or even just
"lastexception"
like it was before (if we consider this as a best practice). What's the
reason for "lastexception2"?
It's a bad commit. I have setted this name for debugging reason.
As a general note, I fail to see the added value of this module at this
point. I mean, the whole point was to have both the functionality of
WikiManager and Workspaces. I get it that it's a work in progress and that
it's at the first stages, but you need to touch those points before it
becomes relevant. Not that it's bad, just that it's not much there to see
at this point.
The idea is to split in different simple modules, that enable us to easily
add a new feature or to depends on a module without depending on the whole
core. I try to reduce the dependencies while I design the modules.
Hope this helps,
Eduard
Thanks Eduard!
Louis-Marie
On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Hi.
In this thread, I want to propose you the tiniest API that we need to
handle multiwiki. All other features (users, templates, workspaces...)
will
be on other modules, because I think it is better
for the extensibility.
The new module will be based on the xwiki-platform-wiki-descriptor-api
module, that I will rename to xwiki-platform-wiki-api. The
WikiDescriptorManager becomes WikiManager and handle both descriptors and
databases.
This API will permit:
* to create a wiki
* to remove a wiki
* to list all wikis (returning a list of descriptors)
* ...
You can see the code of that proposal there:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
The most important is to decide what the API must look like. The
implementation can still be modified afterwards.
I hope you like it,
Louis-Marie
_______________________________________________
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
5:17 p.m.
Thanks to your advices (Eddy and Thomas), I propose you a clean version:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
I have only changed the API, not the implementation.
I think it starts to be clean.
2013/10/7 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
Hi Eddy.
First, thanks for your answer.
2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
Hi Guilllaume,
1) What is the point of the WikiDescriptorAlias class if it just holds and
returns a string?
Also, the only method in the
WikiDescriptorManager that works with aliases
accepts a String instead of the WikiDescriptorAlias class, so this means
that the class is useless:
WikiDescriptor getByWikiAlias(String wikiAlias) throws
WikiManagerException;
I did not really think about it, I just take the work done by Vincent on
wiki descriptors.
2) WikiManager:
The methods wikiIdExists and and isWikiIdAvailable do the same thing, they
just call it differently. Use only one, like wikiExists().
I should have added the javadoc about that. This is what I have in mind :
- wikiExists(String wikiOd) as you said
- wikiAvailable(String wikiId) that checks if the wiki id is valid and
free (that means that there is no existing database with that name -- not
necessary related to XWiki).
It is not implemented yet.
Also, since it's a WikiManager, so the "wiki" part is in the name of the
class, we get it that it deals with wikis. You could remove the "wiki"
part
from method names, like:
- create instead of createWiki
- delete instead of deleteWiki
- exists instead of existsWiki
- so on...
I agree. I'll change it ;)
Note on the naming of methods:
I`ve noticed a rather annoying thing in the way the methods are named. So
you have a class that is say... WikiDescriptor.
Indeed, but a Wiki class would not contain something else than a
descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
3) WikiManager:
What is the point of these 2 methods?
void setDescriptor(WikiDescriptor descriptor);
void removeDescriptor(WikiDescriptor descriptor);
Looking at the implementation, I see that you`re handling descriptors
(setting/deleting) whithout corelating it to the wikis. I mean, if you
remove a descriptor, then you must remove the wiki too, and that is the
task of the WikiManager.delete() method.
I have keeped them because it is used in the descriptors implementation of
Vincent. But I agree that it is weird to have it in the API.
4) Don`t use implementation details. Improve the interface (API) if there
is information you`re missing:
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I disagree.
In this code, I need to have the document related to the descriptor. It
depends on the current implementation, because we can imagine an
implementation where the descriptors are not stored in the wiki. So I won't
add a getDocument() in the API, but I need it in my implementation.
5) DefaultWikiManager.createDescritptor
Since you have a WikiDescriptorBuilder class, maybe that is where the
logic
of creating/building the descriptor's details (objects, document) and
where
the logic of extracting the document name from wiki name and viceversa
should be located.
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I agree, I will move that code into WikiDescriptorBuilder.
6) DefaultWikiManager.getByWikiId
Again seeing the logic of wikiID-to-document. It should be located in a
single place and not spread in multiple places. Use a method of the
WikiManager class or of the DescriptorBuilder class.
OK.
7) WikiManagerScriptService:
- deleteWiki: Why do you need Admin right to delete a wiki when you did
not
need it in order to create it? That`s bad. We should probably have a
deleteWiki right as well.
It is a temporary solution in my implementation.
The problem is: who has the right to remove a wiki ?
- his owner? But we don't have the notion of owner in this API. It belongs
to the wiki-users module to handle this concept.
- someone who has the CREATE_WIKI right? That means every person who has
the CREATE_WIKI right can also delete any existing wiki?
- someone who as the DELETE_WIKI right? Why not, but we need to make a
vote for adding this new right.
So, in my first implementation, I have used the admin right.
Also, consider the workspaces use case when user
create and delete wikis/workspaces when they want to and when they are
done
with them.
To me, it belongs to the future wiki-user module.
- context key for exceptions
"lastexception2" is not the best of choices.
Try something like "wikiException" instead, or even just
"lastexception"
like it was before (if we consider this as a best practice). What's the
reason for "lastexception2"?
It's a bad commit. I have setted this name for debugging reason.
As a general note, I fail to see the added value of this module at this
point. I mean, the whole point was to have both the functionality of
WikiManager and Workspaces. I get it that it's a work in progress and that
it's at the first stages, but you need to touch those points before it
becomes relevant. Not that it's bad, just that it's not much there to see
at this point.
The idea is to split in different simple modules, that enable us to easily
add a new feature or to depends on a module without depending on the whole
core. I try to reduce the dependencies while I design the modules.
Hope this helps,
Eduard
Thanks Eduard!
Louis-Marie
On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Hi.
In this thread, I want to propose you the tiniest API that we need to
handle multiwiki. All other features (users, templates, workspaces...)
will
be on other modules, because I think it is better
for the extensibility.
The new module will be based on the xwiki-platform-wiki-descriptor-api
module, that I will rename to xwiki-platform-wiki-api. The
WikiDescriptorManager becomes WikiManager and handle both descriptors
and
databases.
This API will permit:
* to create a wiki
* to remove a wiki
* to list all wikis (returning a list of descriptors)
* ...
You can see the code of that proposal there:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
The most important is to decide what the API must look like. The
implementation can still be modified afterwards.
I hope you like it,
Louis-Marie
_______________________________________________
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
5:29 p.m.
Before writing extensions the API need to be extensible and we don't
see it in your current API ;) This needs to be there before validating
this API.
On Mon, Oct 7, 2013 at 5:17 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
Thanks to your advices (Eddy and Thomas), I propose
you a clean version:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
I have only changed the API, not the implementation.
I think it starts to be clean.
2013/10/7 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
--
Thomas Mortagne
Hi Eddy.
First, thanks for your answer.
2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi Guilllaume,
1) What is the point of the WikiDescriptorAlias class if it just holds and
returns a string?
Also, the only method in the
WikiDescriptorManager that works with aliases
accepts a String instead of the WikiDescriptorAlias class, so this means
that the class is useless:
WikiDescriptor getByWikiAlias(String wikiAlias) throws
WikiManagerException;
I did not really think about it, I just take the work done by Vincent on
wiki descriptors.
2) WikiManager:
The methods wikiIdExists and and isWikiIdAvailable do the same thing, they
just call it differently. Use only one, like wikiExists().
I should have added the javadoc about that. This is what I have in mind :
- wikiExists(String wikiOd) as you said
- wikiAvailable(String wikiId) that checks if the wiki id is valid and
free (that means that there is no existing database with that name -- not
necessary related to XWiki).
It is not implemented yet.
Also, since it's a WikiManager, so the "wiki" part is in the name of the
class, we get it that it deals with wikis. You could remove the "wiki"
part
from method names, like:
- create instead of createWiki
- delete instead of deleteWiki
- exists instead of existsWiki
- so on...
I agree. I'll change it ;)
Note on the naming of methods:
I`ve noticed a rather annoying thing in the way the methods are named. So
you have a class that is say... WikiDescriptor.
Indeed, but a Wiki class would not contain something else than a
descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
3) WikiManager:
What is the point of these 2 methods?
void setDescriptor(WikiDescriptor descriptor);
void removeDescriptor(WikiDescriptor descriptor);
Looking at the implementation, I see that you`re handling descriptors
(setting/deleting) whithout corelating it to the wikis. I mean, if you
remove a descriptor, then you must remove the wiki too, and that is the
task of the WikiManager.delete() method.
I have keeped them because it is used in the descriptors implementation of
Vincent. But I agree that it is weird to have it in the API.
4) Don`t use implementation details. Improve the interface (API) if there
is information you`re missing:
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I disagree.
In this code, I need to have the document related to the descriptor. It
depends on the current implementation, because we can imagine an
implementation where the descriptors are not stored in the wiki. So I won't
add a getDocument() in the API, but I need it in my implementation.
5) DefaultWikiManager.createDescritptor
Since you have a WikiDescriptorBuilder class, maybe that is where the
logic
of creating/building the descriptor's details (objects, document) and
where
the logic of extracting the document name from wiki name and viceversa
should be located.
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I agree, I will move that code into WikiDescriptorBuilder.
6) DefaultWikiManager.getByWikiId
Again seeing the logic of wikiID-to-document. It should be located in a
single place and not spread in multiple places. Use a method of the
WikiManager class or of the DescriptorBuilder class.
OK.
7) WikiManagerScriptService:
- deleteWiki: Why do you need Admin right to delete a wiki when you did
not
need it in order to create it? That`s bad. We should probably have a
deleteWiki right as well.
It is a temporary solution in my implementation.
The problem is: who has the right to remove a wiki ?
- his owner? But we don't have the notion of owner in this API. It belongs
to the wiki-users module to handle this concept.
- someone who has the CREATE_WIKI right? That means every person who has
the CREATE_WIKI right can also delete any existing wiki?
- someone who as the DELETE_WIKI right? Why not, but we need to make a
vote for adding this new right.
So, in my first implementation, I have used the admin right.
Also, consider the workspaces use case when user
create and delete wikis/workspaces when they want to and when they are
done
with them.
To me, it belongs to the future wiki-user module.
- context key for exceptions
"lastexception2" is not the best of choices.
Try something like "wikiException" instead, or even just
"lastexception"
like it was before (if we consider this as a best practice). What's the
reason for "lastexception2"?
It's a bad commit. I have setted this name for debugging reason.
As a general note, I fail to see the added value of this module at this
point. I mean, the whole point was to have both the functionality of
WikiManager and Workspaces. I get it that it's a work in progress and that
it's at the first stages, but you need to touch those points before it
becomes relevant. Not that it's bad, just that it's not much there to see
at this point.
The idea is to split in different simple modules, that enable us to easily
add a new feature or to depends on a module without depending on the whole
core. I try to reduce the dependencies while I design the modules.
Hope this helps,
Eduard
Thanks Eduard!
Louis-Marie
On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Hi.
In this thread, I want to propose you the tiniest API that we need to
handle multiwiki. All other features (users, templates, workspaces...)
will
be on other modules, because I think it is better
for the extensibility.
The new module will be based on the xwiki-platform-wiki-descriptor-api
module, that I will rename to xwiki-platform-wiki-api. The
WikiDescriptorManager becomes WikiManager and handle both descriptors
and
databases.
This API will permit:
* to create a wiki
* to remove a wiki
* to list all wikis (returning a list of descriptors)
* ...
You can see the code of that proposal there:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
The most important is to decide what the API must look like. The
implementation can still be modified afterwards.
I hope you like it,
Louis-Marie
_______________________________________________
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
5:38 p.m.
What I propose for the extensibility:
- anyone can extends the Wiki class.
- each module will have its own XWikiServerClassDocumentInitializer, that
add custom fields into the XWikiServerClass document.
- the minimal XWikiServerClassDocumentInitializer will only contain a few
fields.
2013/10/7 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
Before writing extensions the API need to be
extensible and we don't
see it in your current API ;) This needs to be there before validating
this API.
On Mon, Oct 7, 2013 at 5:17 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks to your advices (Eddy and Thomas), I
propose you a clean version:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
I have only changed the API, not the implementation.
I think it starts to be clean.
2013/10/7 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
> Hi Eddy.
>
> First, thanks for your answer.
>
> 2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
>
>> Hi Guilllaume,
>>
>> 1) What is the point of the WikiDescriptorAlias class if it just holds
and
>> returns a string?
>>
>
>> Also, the only method in the WikiDescriptorManager that works with
aliases
>> accepts a String instead of the
WikiDescriptorAlias class, so this
means
>> that the class is useless:
>>
>> WikiDescriptor getByWikiAlias(String wikiAlias) throws
>> WikiManagerException;
>>
>
> I did not really think about it, I just take the work done by Vincent on
> wiki descriptors.
>
>
>> 2) WikiManager:
>>
>> The methods wikiIdExists and and isWikiIdAvailable do the same thing,
they
>> just call it differently. Use only one,
like wikiExists().
>>
>
> I should have added the javadoc about that. This is what I have in mind
:
> - wikiExists(String wikiOd) as you said
> - wikiAvailable(String wikiId) that checks if the wiki id is valid and
> free (that means that there is no existing database with that name --
not
> necessary related to XWiki).
>
> It is not implemented yet.
>
>
>>
>> Also, since it's a WikiManager, so the "wiki" part is in the name
of
the
>> class, we get it that it deals with
wikis. You could remove the "wiki"
>> part
>> from method names, like:
>> - create instead of createWiki
>> - delete instead of deleteWiki
>> - exists instead of existsWiki
>> - so on...
>>
>
> I agree. I'll change it ;)
>
>
>>
>> Note on the naming of methods:
>> I`ve noticed a rather annoying thing in the way the methods are named.
So
>> you have a class that is say...
WikiDescriptor.
>>
>
> Indeed, but a Wiki class would not contain something else than a
> descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
>
>
>>
>> 3) WikiManager:
>>
>> What is the point of these 2 methods?
>>
>> void setDescriptor(WikiDescriptor descriptor);
>>
>> void removeDescriptor(WikiDescriptor descriptor);
>>
>> Looking at the implementation, I see that you`re handling descriptors
>> (setting/deleting) whithout corelating it to the wikis. I mean, if you
>> remove a descriptor, then you must remove the wiki too, and that is the
>> task of the WikiManager.delete() method.
>>
>
> I have keeped them because it is used in the descriptors implementation
of
> Vincent. But I agree that it is weird to have
it in the API.
>
>
>>
>> 4) Don`t use implementation details. Improve the interface (API) if
there
>> is information you`re missing:
>>
>>
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
>>
>
> I disagree.
> In this code, I need to have the document related to the descriptor. It
> depends on the current implementation, because we can imagine an
> implementation where the descriptors are not stored in the wiki. So I
won't
> add a getDocument() in the API, but I need it
in my implementation.
>
>
>>
>> 5) DefaultWikiManager.createDescritptor
>> Since you have a WikiDescriptorBuilder class, maybe that is where the
>> logic
>> of creating/building the descriptor's details (objects, document) and
>> where
>> the logic of extracting the document name from wiki name and viceversa
>> should be located.
>>
>>
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
>>
>
> I agree, I will move that code into WikiDescriptorBuilder.
>
>
>>
>> 6) DefaultWikiManager.getByWikiId
>> Again seeing the logic of wikiID-to-document. It should be located in a
>> single place and not spread in multiple places. Use a method of the
>> WikiManager class or of the DescriptorBuilder class.
>>
>
> OK.
>
>
>>
>> 7) WikiManagerScriptService:
>> - deleteWiki: Why do you need Admin right to delete a wiki when you did
>> not
>> need it in order to create it? That`s bad. We should probably have a
>> deleteWiki right as well.
>
>
> It is a temporary solution in my implementation.
> The problem is: who has the right to remove a wiki ?
> - his owner? But we don't have the notion of owner in this API. It
belongs
> to the wiki-users module to handle this
concept.
> - someone who has the CREATE_WIKI right? That means every person who has
> the CREATE_WIKI right can also delete any existing wiki?
> - someone who as the DELETE_WIKI right? Why not, but we need to make a
> vote for adding this new right.
>
> So, in my first implementation, I have used the admin right.
>
>
>> Also, consider the workspaces use case when user
>> create and delete wikis/workspaces when they want to and when they are
>> done
>> with them.
>>
>
> To me, it belongs to the future wiki-user module.
>
>
>> - context key for exceptions "lastexception2" is not the best of
choices.
>> Try something like
"wikiException" instead, or even just
"lastexception"
>> like it was before (if we consider this
as a best practice). What's the
>> reason for "lastexception2"?
>>
>>
> It's a bad commit. I have setted this name for debugging reason.
>
>
>>
>> As a general note, I fail to see the added value of this module at this
>> point. I mean, the whole point was to have both the functionality of
>> WikiManager and Workspaces. I get it that it's a work in progress and
that
>> it's at the first stages, but you
need to touch those points before it
>> becomes relevant. Not that it's bad, just that it's not much there to
see
>> at this point.
>>
>
> The idea is to split in different simple modules, that enable us to
easily
> add a new feature or to depends on a module
without depending on the
whole
> core. I try to reduce the dependencies while
I design the modules.
>
>
>>
>> Hope this helps,
>> Eduard
>>
>>
> Thanks Eduard!
>
> Louis-Marie
>
>
>>
>> On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau
<
>> gdelhumeau(a)xwiki.com> wrote:
>>
>> > Hi.
>> >
>> > In this thread, I want to propose you the tiniest API that we need to
>> > handle multiwiki. All other features (users, templates,
workspaces...)
>> will
>> > be on other modules, because I think it is better for the
extensibility.
>> >
>> > The new module will be based on the
xwiki-platform-wiki-descriptor-api
>> > module, that I will rename to
xwiki-platform-wiki-api. The
>> > WikiDescriptorManager becomes WikiManager and handle both descriptors
>> and
>> > databases.
>> >
>> > This API will permit:
>> > * to create a wiki
>> > * to remove a wiki
>> > * to list all wikis (returning a list of descriptors)
>> > * ...
>> >
>> > You can see the code of that proposal there:
>> >
>> >
>>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
>
> The most important is to decide what the API must look like. The
> implementation can still be modified afterwards.
>
> I hope you like it,
>
> Louis-Marie
> _______________________________________________
> 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
6:12 p.m.
On Mon, Oct 7, 2013 at 5:38 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
What I propose for the extensibility:
- anyone can extends the Wiki class.
- each module will have its own XWikiServerClassDocumentInitializer, that
add custom fields into the XWikiServerClass document.
- the minimal XWikiServerClassDocumentInitializer will only contain a few
fields.
That's not extension. I was expecting a generic way to access and
modify descriptor properties. The "extensions" you are talking about
are going to be completely independents modules that directly
manipulate xobjects and they will have to provide their own complete
API, do there own caching of descriptors etc, extending Wiki class is
pretty useless for them.
2013/10/7 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
--
Thomas Mortagne
Before writing extensions the API need to be
extensible and we don't
see it in your current API ;) This needs to be there before validating
this API.
On Mon, Oct 7, 2013 at 5:17 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
--
Thomas Mortagne
_______________________________________________
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 to your advices (Eddy and Thomas), I
propose you a clean version:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
I have only changed the API, not the implementation.
I think it starts to be clean.
2013/10/7 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
> Hi Eddy.
>
> First, thanks for your answer.
>
> 2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
>
>> Hi Guilllaume,
>>
>> 1) What is the point of the WikiDescriptorAlias class if it just holds
and
>> returns a string?
>>
>
>> Also, the only method in the WikiDescriptorManager that works with
aliases
>> accepts a String instead of the
WikiDescriptorAlias class, so this
means
>> that the class is useless:
>>
>> WikiDescriptor getByWikiAlias(String wikiAlias) throws
>> WikiManagerException;
>>
>
> I did not really think about it, I just take the work done by Vincent on
> wiki descriptors.
>
>
>> 2) WikiManager:
>>
>> The methods wikiIdExists and and isWikiIdAvailable do the same thing,
they
>> just call it differently. Use only one,
like wikiExists().
>>
>
> I should have added the javadoc about that. This is what I have in mind
:
> - wikiExists(String wikiOd) as you said
> - wikiAvailable(String wikiId) that checks if the wiki id is valid and
> free (that means that there is no existing database with that name --
not
> necessary related to XWiki).
>
> It is not implemented yet.
>
>
>>
>> Also, since it's a WikiManager, so the "wiki" part is in the name
of
the
>> class, we get it that it deals with
wikis. You could remove the "wiki"
>> part
>> from method names, like:
>> - create instead of createWiki
>> - delete instead of deleteWiki
>> - exists instead of existsWiki
>> - so on...
>>
>
> I agree. I'll change it ;)
>
>
>>
>> Note on the naming of methods:
>> I`ve noticed a rather annoying thing in the way the methods are named.
So
>> you have a class that is say...
WikiDescriptor.
>>
>
> Indeed, but a Wiki class would not contain something else than a
> descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
>
>
>>
>> 3) WikiManager:
>>
>> What is the point of these 2 methods?
>>
>> void setDescriptor(WikiDescriptor descriptor);
>>
>> void removeDescriptor(WikiDescriptor descriptor);
>>
>> Looking at the implementation, I see that you`re handling descriptors
>> (setting/deleting) whithout corelating it to the wikis. I mean, if you
>> remove a descriptor, then you must remove the wiki too, and that is the
>> task of the WikiManager.delete() method.
>>
>
> I have keeped them because it is used in the descriptors implementation
of
> Vincent. But I agree that it is weird to have
it in the API.
>
>
>>
>> 4) Don`t use implementation details. Improve the interface (API) if
there
>> is information you`re missing:
>>
>>
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
>>
>
> I disagree.
> In this code, I need to have the document related to the descriptor. It
> depends on the current implementation, because we can imagine an
> implementation where the descriptors are not stored in the wiki. So I
won't
> add a getDocument() in the API, but I need it
in my implementation.
>
>
>>
>> 5) DefaultWikiManager.createDescritptor
>> Since you have a WikiDescriptorBuilder class, maybe that is where the
>> logic
>> of creating/building the descriptor's details (objects, document) and
>> where
>> the logic of extracting the document name from wiki name and viceversa
>> should be located.
>>
>>
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
>>
>
> I agree, I will move that code into WikiDescriptorBuilder.
>
>
>>
>> 6) DefaultWikiManager.getByWikiId
>> Again seeing the logic of wikiID-to-document. It should be located in a
>> single place and not spread in multiple places. Use a method of the
>> WikiManager class or of the DescriptorBuilder class.
>>
>
> OK.
>
>
>>
>> 7) WikiManagerScriptService:
>> - deleteWiki: Why do you need Admin right to delete a wiki when you did
>> not
>> need it in order to create it? That`s bad. We should probably have a
>> deleteWiki right as well.
>
>
> It is a temporary solution in my implementation.
> The problem is: who has the right to remove a wiki ?
> - his owner? But we don't have the notion of owner in this API. It
belongs
> to the wiki-users module to handle this
concept.
> - someone who has the CREATE_WIKI right? That means every person who has
> the CREATE_WIKI right can also delete any existing wiki?
> - someone who as the DELETE_WIKI right? Why not, but we need to make a
> vote for adding this new right.
>
> So, in my first implementation, I have used the admin right.
>
>
>> Also, consider the workspaces use case when user
>> create and delete wikis/workspaces when they want to and when they are
>> done
>> with them.
>>
>
> To me, it belongs to the future wiki-user module.
>
>
>> - context key for exceptions "lastexception2" is not the best of
choices.
>> Try something like
"wikiException" instead, or even just
"lastexception"
>> like it was before (if we consider this
as a best practice). What's the
>> reason for "lastexception2"?
>>
>>
> It's a bad commit. I have setted this name for debugging reason.
>
>
>>
>> As a general note, I fail to see the added value of this module at this
>> point. I mean, the whole point was to have both the functionality of
>> WikiManager and Workspaces. I get it that it's a work in progress and
that
>> it's at the first stages, but you
need to touch those points before it
>> becomes relevant. Not that it's bad, just that it's not much there to
see
>> at this point.
>>
>
> The idea is to split in different simple modules, that enable us to
easily
> add a new feature or to depends on a module
without depending on the
whole
> core. I try to reduce the dependencies while
I design the modules.
>
>
>>
>> Hope this helps,
>> Eduard
>>
>>
> Thanks Eduard!
>
> Louis-Marie
>
>
>>
>> On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau
<
>> gdelhumeau(a)xwiki.com> wrote:
>>
>> > Hi.
>> >
>> > In this thread, I want to propose you the tiniest API that we need to
>> > handle multiwiki. All other features (users, templates,
workspaces...)
>> will
>> > be on other modules, because I think it is better for the
extensibility.
>> >
>> > The new module will be based on the
xwiki-platform-wiki-descriptor-api
>> > module, that I will rename to
xwiki-platform-wiki-api. The
>> > WikiDescriptorManager becomes WikiManager and handle both descriptors
>> and
>> > databases.
>> >
>> > This API will permit:
>> > * to create a wiki
>> > * to remove a wiki
>> > * to list all wikis (returning a list of descriptors)
>> > * ...
>> >
>> > You can see the code of that proposal there:
>> >
>> >
>>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
> >
> > The most important is to decide what the API must look like. The
> > implementation can still be modified afterwards.
> >
> > I hope you like it,
> >
> > Louis-Marie
> > _______________________________________________
> > 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
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:44 p.m.
I can add the possibility to have custom data stored in a map. But how
should we store it in the wiki?
2013/10/7 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
On Mon, Oct 7, 2013 at 5:38 PM, Guillaume
"Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
What I propose for the extensibility:
- anyone can extends the Wiki class.
- each module will have its own XWikiServerClassDocumentInitializer, that
add custom fields into the XWikiServerClass document.
- the minimal XWikiServerClassDocumentInitializer will only contain a few
fields.
That's not extension. I was expecting a generic way to access and
modify descriptor properties. The "extensions" you are talking about
are going to be completely independents modules that directly
manipulate xobjects and they will have to provide their own complete
API, do there own caching of descriptors etc, extending Wiki class is
pretty useless for them.
2013/10/7 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
> Before writing extensions the API need to be extensible and we don't
> see it in your current API ;) This needs to be there before validating
> this API.
>
> On Mon, Oct 7, 2013 at 5:17 PM, Guillaume "Louis-Marie" Delhumeau
> <gdelhumeau(a)xwiki.com> wrote:
> > Thanks to your advices (Eddy and Thomas), I propose you a clean
version:
> >
>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
> >
> > I have only changed the API, not the implementation.
> >
> > I think it starts to be clean.
> >
> >
> > 2013/10/7 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
> >
> >> Hi Eddy.
> >>
> >> First, thanks for your answer.
> >>
> >> 2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
> >>
> >>> Hi Guilllaume,
> >>>
> >>> 1) What is the point of the WikiDescriptorAlias class if it just
holds
> and
> >>> returns a string?
> >>>
> >>
> >>> Also, the only method in the WikiDescriptorManager that works with
> aliases
> >>> accepts a String instead of the WikiDescriptorAlias class, so this
> means
> >>> that the class is useless:
> >>>
> >>> WikiDescriptor getByWikiAlias(String wikiAlias) throws
> >>> WikiManagerException;
> >>>
> >>
> >> I did not really think about it, I just take the work done by
Vincent
on
> >> wiki descriptors.
> >>
> >>
> >>> 2) WikiManager:
> >>>
> >>> The methods wikiIdExists and and isWikiIdAvailable do the same
thing,
> they
> >>> just call it differently. Use only one, like wikiExists().
> >>>
> >>
> >> I should have added the javadoc about that. This is what I have in
mind
> :
> >> - wikiExists(String wikiOd) as you said
> >> - wikiAvailable(String wikiId) that checks if the wiki id is valid
and
> >> free (that means that there is no
existing database with that name --
> not
> >> necessary related to XWiki).
> >>
> >> It is not implemented yet.
> >>
> >>
> >>>
> >>> Also, since it's a WikiManager, so the "wiki" part is in
the name of
> the
> >>> class, we get it that it deals with wikis. You could remove the
"wiki"
> >>> part
> >>> from method names, like:
> >>> - create instead of createWiki
> >>> - delete instead of deleteWiki
> >>> - exists instead of existsWiki
> >>> - so on...
> >>>
> >>
> >> I agree. I'll change it ;)
> >>
> >>
> >>>
> >>> Note on the naming of methods:
> >>> I`ve noticed a rather annoying thing in the way the methods are
named.
> So
> >>> you have a class that is say... WikiDescriptor.
> >>>
> >>
> >> Indeed, but a Wiki class would not contain something else than a
> >> descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
> >>
> >>
> >>>
> >>> 3) WikiManager:
> >>>
> >>> What is the point of these 2 methods?
> >>>
> >>> void setDescriptor(WikiDescriptor descriptor);
> >>>
> >>> void removeDescriptor(WikiDescriptor descriptor);
> >>>
> >>> Looking at the implementation, I see that you`re handling
descriptors
> >>> (setting/deleting) whithout
corelating it to the wikis. I mean, if
you
> >>> remove a descriptor, then you
must remove the wiki too, and that is
the
> >>> task of the WikiManager.delete()
method.
> >>>
> >>
> >> I have keeped them because it is used in the descriptors
implementation
> of
> >> Vincent. But I agree that it is weird to have it in the API.
> >>
> >>
> >>>
> >>> 4) Don`t use implementation details. Improve the interface (API) if
> there
> >>> is information you`re missing:
> >>>
> >>>
>
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
> >>>
> >>
> >> I disagree.
> >> In this code, I need to have the document related to the descriptor.
It
> >> depends on the current
implementation, because we can imagine an
> >> implementation where the descriptors are not stored in the wiki. So I
> won't
> >> add a getDocument() in the API, but I need it in my implementation.
> >>
> >>
> >>>
> >>> 5) DefaultWikiManager.createDescritptor
> >>> Since you have a WikiDescriptorBuilder class, maybe that is where
the
> >>> logic
> >>> of creating/building the descriptor's details (objects, document)
and
> >>> where
> >>> the logic of extracting the document name from wiki name and
viceversa
> >>> should be located.
> >>>
> >>>
>
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
> >>>
> >>
> >> I agree, I will move that code into WikiDescriptorBuilder.
> >>
> >>
> >>>
> >>> 6) DefaultWikiManager.getByWikiId
> >>> Again seeing the logic of wikiID-to-document. It should be located
in a
> >>> single place and not spread in
multiple places. Use a method of the
> >>> WikiManager class or of the DescriptorBuilder class.
> >>>
> >>
> >> OK.
> >>
> >>
> >>>
> >>> 7) WikiManagerScriptService:
> >>> - deleteWiki: Why do you need Admin right to delete a wiki when you
did
> >>> not
> >>> need it in order to create it? That`s bad. We should probably have a
> >>> deleteWiki right as well.
> >>
> >>
> >> It is a temporary solution in my implementation.
> >> The problem is: who has the right to remove a wiki ?
> >> - his owner? But we don't have the notion of owner in this API. It
> belongs
> >> to the wiki-users module to handle this concept.
> >> - someone who has the CREATE_WIKI right? That means every person who
has
> >> the CREATE_WIKI right can also
delete any existing wiki?
> >> - someone who as the DELETE_WIKI right? Why not, but we need to make
a
> >> vote for adding this new right.
> >>
> >> So, in my first implementation, I have used the admin right.
> >>
> >>
> >>> Also, consider the workspaces use case when user
> >>> create and delete wikis/workspaces when they want to and when they
are
> >>> done
> >>> with them.
> >>>
> >>
> >> To me, it belongs to the future wiki-user module.
> >>
> >>
> >>> - context key for exceptions "lastexception2" is not the best
of
> choices.
> >>> Try something like "wikiException" instead, or even just
> "lastexception"
> >>> like it was before (if we consider this as a best practice). What's
the
> >>> reason for
"lastexception2"?
> >>>
> >>>
> >> It's a bad commit. I have setted this name for debugging reason.
> >>
> >>
> >>>
> >>> As a general note, I fail to see the added value of this module at
this
> >>> point. I mean, the whole point
was to have both the functionality of
> >>> WikiManager and Workspaces. I get it that it's a work in progress
and
> that
> >>> it's at the first stages, but you need to touch those points before
it
> >>> becomes relevant. Not that
it's bad, just that it's not much there
to
> see
> >>> at this point.
> >>>
> >>
> >> The idea is to split in different simple modules, that enable us to
> easily
> >> add a new feature or to depends on a module without depending on the
> whole
> >> core. I try to reduce the dependencies while I design the modules.
> >>
> >>
> >>>
> >>> Hope this helps,
> >>> Eduard
> >>>
> >>>
> >> Thanks Eduard!
> >>
> >> Louis-Marie
> >>
> >>
> >>>
> >>> On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie"
Delhumeau <
> >>> gdelhumeau(a)xwiki.com> wrote:
> >>>
> >>> > Hi.
> >>> >
> >>> > In this thread, I want to propose you the tiniest API that we
need to
> >>> > handle multiwiki. All other
features (users, templates,
> workspaces...)
> >>> will
> >>> > be on other modules, because I think it is better for the
> extensibility.
> >>> >
> >>> > The new module will be based on the
> xwiki-platform-wiki-descriptor-api
> >>> > module, that I will rename to xwiki-platform-wiki-api. The
> >>> > WikiDescriptorManager becomes WikiManager and handle both
descriptors
> >>> and
> >>> > databases.
> >>> >
> >>> > This API will permit:
> >>> > * to create a wiki
> >>> > * to remove a wiki
> >>> > * to list all wikis (returning a list of descriptors)
> >>> > * ...
> >>> >
> >>> > You can see the code of that proposal there:
> >>> >
> >>> >
> >>>
>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
>> >
>> > The most important is to decide what the API must look like. The
>> > implementation can still be modified afterwards.
>> >
>> > I hope you like it,
>> >
>> > Louis-Marie
>> > _______________________________________________
>> > 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
>>
>
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:11 p.m.
First of all, you should probably come up with some plausible use cases for
extending this API and then build it with them in mind. Maybe I`ve missed
some discussions, but right now I just don`t see it.
On Mon, Oct 7, 2013 at 7:44 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
I can add the possibility to have custom data stored
in a map. But how
should we store it in the wiki?
2013/10/7 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
--
Wiki?
is
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
the
before
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
--
Thomas Mortagne
_______________________________________________
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
On Mon, Oct 7, 2013 at 5:38 PM, Guillaume
"Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
> What I propose for the extensibility:
>
> - anyone can extends the Wiki class.
> - each module will have its own XWikiServerClassDocumentInitializer,
that
> add custom fields into the XWikiServerClass
document.
> - the minimal XWikiServerClassDocumentInitializer will only contain a
few
fields.
That's not extension. I was expecting a generic way to access and
modify descriptor properties. The "extensions" you are talking about
are going to be completely independents modules that directly
manipulate xobjects and they will have to provide their own complete
API, do there own caching of descriptors etc, extending Wiki class is
pretty useless for them.
2013/10/7 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
> Before writing extensions the API need to be extensible and we don't
> see it in your current API ;) This needs to be there before validating
> this API.
>
> On Mon, Oct 7, 2013 at 5:17 PM, Guillaume "Louis-Marie" Delhumeau
> <gdelhumeau(a)xwiki.com> wrote:
> > Thanks to your advices (Eddy and Thomas), I propose you a clean
version:
> >
>
> >
> > I have only changed the API, not the implementation.
> >
> > I think it starts to be clean.
> >
> >
> > 2013/10/7 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
> >
> >> Hi Eddy.
> >>
> >> First, thanks for your answer.
> >>
> >> 2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
> >>
> >>> Hi Guilllaume,
> >>>
> >>> 1) What is the point of the WikiDescriptorAlias class if it just
holds
> and
> >>> returns a string?
> >>>
> >>
> >>> Also, the only method in the WikiDescriptorManager that works with
> aliases
> >>> accepts a String instead of the WikiDescriptorAlias class, so this
> means
> >>> that the class is useless:
> >>>
> >>> WikiDescriptor getByWikiAlias(String wikiAlias) throws
> >>> WikiManagerException;
> >>>
> >>
> >> I did not really think about it, I just take the work done by
Vincent
on
> >> wiki descriptors.
> >>
> >>
> >>> 2) WikiManager:
> >>>
> >>> The methods wikiIdExists and and isWikiIdAvailable do the same
thing,
> they
> >>> just call it differently. Use only one, like wikiExists().
> >>>
> >>
> >> I should have added the javadoc about that. This is what I have in
mind
> :
> >> - wikiExists(String wikiOd) as you said
> >> - wikiAvailable(String wikiId) that checks if the wiki id is valid
and
>> >> free (that means that there is no existing database with that name
>> not
>> >> necessary related to XWiki).
>> >>
>> >> It is not implemented yet.
>> >>
>> >>
>> >>>
>> >>> Also, since it's a WikiManager, so the "wiki" part is
in the name
of
> the
> >>> class, we get it that it deals with wikis. You could remove the
"wiki"
> >>> part
> >>> from method names, like:
> >>> - create instead of createWiki
> >>> - delete instead of deleteWiki
> >>> - exists instead of existsWiki
> >>> - so on...
> >>>
> >>
> >> I agree. I'll change it ;)
> >>
> >>
> >>>
> >>> Note on the naming of methods:
> >>> I`ve noticed a rather annoying thing in the way the methods are
named.
>> So
>> >>> you have a class that is say... WikiDescriptor.
>> >>>
>> >>
>> >> Indeed, but a Wiki class would not contain something else than a
>> >> descriptor. I don't know what to do. Renaming WikiDescriptor to
>
>>
> >>
> >>>
> >>> 3) WikiManager:
> >>>
> >>> What is the point of these 2 methods?
> >>>
> >>> void setDescriptor(WikiDescriptor descriptor);
> >>>
> >>> void removeDescriptor(WikiDescriptor descriptor);
> >>>
> >>> Looking at the implementation, I see that you`re handling
descriptors
> >>> (setting/deleting) whithout
corelating it to the wikis. I mean, if
you
>> >>> remove a descriptor, then you must remove the wiki too, and that
the
if
> >>> task of the WikiManager.delete()
method.
> >>>
> >>
> >> I have keeped them because it is used in the descriptors
implementation
>> of
>> >> Vincent. But I agree that it is weird to have it in the API.
>> >>
>> >>
>> >>>
>> >>> 4) Don`t use implementation details. Improve the interface (API)
>
there
> >>> is information you`re missing:
> >>>
> >>>
>
>> >>>
>> >>
>> >> I disagree.
>> >> In this code, I need to have the document related to the
descriptor.
It
>> >> depends on the current implementation, because we can imagine an
>> >> implementation where the descriptors are not stored in the wiki.
So I
>
won't
> >> add a getDocument() in the API, but I need it in my implementation.
> >>
> >>
> >>>
> >>> 5) DefaultWikiManager.createDescritptor
> >>> Since you have a WikiDescriptorBuilder class, maybe that is where
the
> >>> logic
> >>> of creating/building the descriptor's details (objects, document)
and
> >>> where
> >>> the logic of extracting the document name from wiki name and
viceversa
> >>> should be located.
> >>>
> >>>
>
>
>>>
> >>
> >> I agree, I will move that code into WikiDescriptorBuilder.
> >>
> >>
> >>>
> >>> 6) DefaultWikiManager.getByWikiId
> >>> Again seeing the logic of wikiID-to-document. It should be located
in a
>> >>> single place and not spread in multiple places. Use a method of
>> >>> WikiManager class or of the
DescriptorBuilder class.
>> >>>
>> >>
>> >> OK.
>> >>
>> >>
>> >>>
>> >>> 7) WikiManagerScriptService:
>> >>> - deleteWiki: Why do you need Admin right to delete a wiki when
you
did
>> >>> not
>> >>> need it in order to create it? That`s bad. We should probably
have a
>> >>> deleteWiki right as well.
>> >>
>> >>
>> >> It is a temporary solution in my implementation.
>> >> The problem is: who has the right to remove a wiki ?
>> >> - his owner? But we don't have the notion of owner in this API. It
>> belongs
>> >> to the wiki-users module to handle this concept.
>> >> - someone who has the CREATE_WIKI right? That means every person
who
has
>> >> the CREATE_WIKI right can also delete any existing wiki?
>> >> - someone who as the DELETE_WIKI right? Why not, but we need to
make
a
What's
> >> vote for adding this new right.
> >>
> >> So, in my first implementation, I have used the admin right.
> >>
> >>
> >>> Also, consider the workspaces use case when user
> >>> create and delete wikis/workspaces when they want to and when they
are
>> >>> done
>> >>> with them.
>> >>>
>> >>
>> >> To me, it belongs to the future wiki-user module.
>> >>
>> >>
>> >>> - context key for exceptions "lastexception2" is not the
best of
>> choices.
>> >>> Try something like "wikiException" instead, or even just
>> "lastexception"
>> >>> like it was before (if we consider this as a best practice). the
of
> >>> reason for
"lastexception2"?
> >>>
> >>>
> >> It's a bad commit. I have setted this name for debugging reason.
> >>
> >>
> >>>
> >>> As a general note, I fail to see the added value of this module at
this
>> >>> point. I mean, the whole point was to have both the functionality
>
>>> WikiManager and Workspaces. I get it that it's a work in progress
and
>> that
>> >>> it's at the first stages, but you need to touch those points
it
the
> >>> becomes relevant. Not that
it's bad, just that it's not much there
to
>> see
>> >>> at this point.
>> >>>
>> >>
>> >> The idea is to split in different simple modules, that enable us to
>> easily
>> >> add a new feature or to depends on a module without depending on >> whole
>> >> core. I try to reduce the dependencies while I design the modules.
>> >>
>> >>
>> >>>
>> >>> Hope this helps,
>> >>> Eduard
>> >>>
>> >>>
>> >> Thanks Eduard!
>> >>
>> >> Louis-Marie
>> >>
>> >>
>> >>>
>> >>> On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie"
Delhumeau <
>
>>> gdelhumeau(a)xwiki.com> wrote:
> >>>
> >>> > Hi.
> >>> >
> >>> > In this thread, I want to propose you the tiniest API that we
need to
> >>> > handle multiwiki. All other
features (users, templates,
> workspaces...)
> >>> will
> >>> > be on other modules, because I think it is better for the
> extensibility.
> >>> >
> >>> > The new module will be based on the
> xwiki-platform-wiki-descriptor-api
> >>> > module, that I will rename to xwiki-platform-wiki-api. The
> >>> > WikiDescriptorManager becomes WikiManager and handle both
descriptors
> >>> and
> >>> > databases.
> >>> >
> >>> > This API will permit:
> >>> > * to create a wiki
> >>> > * to remove a wiki
> >>> > * to list all wikis (returning a list of descriptors)
> >>> > * ...
> >>> >
> >>> > You can see the code of that proposal there:
> >>> >
> >>> >
> >>>
>
>>> >
>>> > The most important is to decide what the API must look like. The
>>> > implementation can still be modified afterwards.
>>> >
>>> > I hope you like it,
>>> >
>>> > Louis-Marie
>>> > _______________________________________________
>>> > 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
>>>
>>
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
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 
8 Oct
8 Oct
8:53 a.m.
Hi Guillaume,
I also don't see the point of a typed WikiAlias for now and in
Wiki#getWikiId() the "Wiki" is redundant. Why not simply Wiki#getId()
and Wiki#getAlias()? And what is the difference between 'wikiAlias'
and 'descriptorAliases' (no javadoc)? If a wiki can have multiple
aliases then why not keep just a list and handle the first item
differently if needed (like ServletRequest#getParameter() vs.
ServletRequest#getParameterValues()).
In WikiManager#getAll() javadoc I see "(except the main one)". Is this
the only method that must treat (by contract) the main wiki
differently? How do getById() and exists() behave for instance
regarding the main wiki? The javadoc on an interface / API is very
important as it indicates what the implementation should do. So it
must state very clear any special use cases.
Hope this helps,
Marius
On Mon, Oct 7, 2013 at 6:17 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
Thanks to your advices (Eddy and Thomas), I propose
you a clean version:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
I have only changed the API, not the implementation.
I think it starts to be clean.
2013/10/7 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
Hi Eddy.
First, thanks for your answer.
2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi Guilllaume,
1) What is the point of the WikiDescriptorAlias class if it just holds and
returns a string?
Also, the only method in the
WikiDescriptorManager that works with aliases
accepts a String instead of the WikiDescriptorAlias class, so this means
that the class is useless:
WikiDescriptor getByWikiAlias(String wikiAlias) throws
WikiManagerException;
I did not really think about it, I just take the work done by Vincent on
wiki descriptors.
2) WikiManager:
The methods wikiIdExists and and isWikiIdAvailable do the same thing, they
just call it differently. Use only one, like wikiExists().
I should have added the javadoc about that. This is what I have in mind :
- wikiExists(String wikiOd) as you said
- wikiAvailable(String wikiId) that checks if the wiki id is valid and
free (that means that there is no existing database with that name -- not
necessary related to XWiki).
It is not implemented yet.
Also, since it's a WikiManager, so the "wiki" part is in the name of the
class, we get it that it deals with wikis. You could remove the "wiki"
part
from method names, like:
- create instead of createWiki
- delete instead of deleteWiki
- exists instead of existsWiki
- so on...
I agree. I'll change it ;)
Note on the naming of methods:
I`ve noticed a rather annoying thing in the way the methods are named. So
you have a class that is say... WikiDescriptor.
Indeed, but a Wiki class would not contain something else than a
descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
3) WikiManager:
What is the point of these 2 methods?
void setDescriptor(WikiDescriptor descriptor);
void removeDescriptor(WikiDescriptor descriptor);
Looking at the implementation, I see that you`re handling descriptors
(setting/deleting) whithout corelating it to the wikis. I mean, if you
remove a descriptor, then you must remove the wiki too, and that is the
task of the WikiManager.delete() method.
I have keeped them because it is used in the descriptors implementation of
Vincent. But I agree that it is weird to have it in the API.
4) Don`t use implementation details. Improve the interface (API) if there
is information you`re missing:
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I disagree.
In this code, I need to have the document related to the descriptor. It
depends on the current implementation, because we can imagine an
implementation where the descriptors are not stored in the wiki. So I won't
add a getDocument() in the API, but I need it in my implementation.
5) DefaultWikiManager.createDescritptor
Since you have a WikiDescriptorBuilder class, maybe that is where the
logic
of creating/building the descriptor's details (objects, document) and
where
the logic of extracting the document name from wiki name and viceversa
should be located.
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I agree, I will move that code into WikiDescriptorBuilder.
6) DefaultWikiManager.getByWikiId
Again seeing the logic of wikiID-to-document. It should be located in a
single place and not spread in multiple places. Use a method of the
WikiManager class or of the DescriptorBuilder class.
OK.
7) WikiManagerScriptService:
- deleteWiki: Why do you need Admin right to delete a wiki when you did
not
need it in order to create it? That`s bad. We should probably have a
deleteWiki right as well.
It is a temporary solution in my implementation.
The problem is: who has the right to remove a wiki ?
- his owner? But we don't have the notion of owner in this API. It belongs
to the wiki-users module to handle this concept.
- someone who has the CREATE_WIKI right? That means every person who has
the CREATE_WIKI right can also delete any existing wiki?
- someone who as the DELETE_WIKI right? Why not, but we need to make a
vote for adding this new right.
So, in my first implementation, I have used the admin right.
Also, consider the workspaces use case when user
create and delete wikis/workspaces when they want to and when they are
done
with them.
To me, it belongs to the future wiki-user module.
- context key for exceptions
"lastexception2" is not the best of choices.
Try something like "wikiException" instead, or even just
"lastexception"
like it was before (if we consider this as a best practice). What's the
reason for "lastexception2"?
It's a bad commit. I have setted this name for debugging reason.
As a general note, I fail to see the added value of this module at this
point. I mean, the whole point was to have both the functionality of
WikiManager and Workspaces. I get it that it's a work in progress and that
it's at the first stages, but you need to touch those points before it
becomes relevant. Not that it's bad, just that it's not much there to see
at this point.
The idea is to split in different simple modules, that enable us to easily
add a new feature or to depends on a module without depending on the whole
core. I try to reduce the dependencies while I design the modules.
Hope this helps,
Eduard
Thanks Eduard!
Louis-Marie
On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Hi.
In this thread, I want to propose you the tiniest API that we need to
handle multiwiki. All other features (users, templates, workspaces...)
will
be on other modules, because I think it is better
for the extensibility.
The new module will be based on the xwiki-platform-wiki-descriptor-api
module, that I will rename to xwiki-platform-wiki-api. The
WikiDescriptorManager becomes WikiManager and handle both descriptors
and
databases.
This API will permit:
* to create a wiki
* to remove a wiki
* to list all wikis (returning a list of descriptors)
* ...
You can see the code of that proposal there:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
The most important is to decide what the API must look like. The
implementation can still be modified afterwards.
I hope you like it,
Louis-Marie
_______________________________________________
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
9:09 a.m.
On Tue, Oct 8, 2013 at 8:53 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Hi Guillaume,
I also don't see the point of a typed WikiAlias for now and in
Wiki#getWikiId() the "Wiki" is redundant. Why not simply Wiki#getId()
and Wiki#getAlias()?
And what is the difference between
'wikiAlias'
and 'descriptorAliases' (no javadoc)? If a wiki can have multiple
aliases then why not keep just a list and handle the first item
differently if needed (like ServletRequest#getParameter() vs.
ServletRequest#getParameterValues()).
Same for me, this does not make much sense. The wiki has a list of
aliases and the URL factory happen to use the first one. Either you
keep only the list of you rename wikiAlias into default alias to be
extra safe on what should be used when generating a URL but in all
cases the list should contain all aliases, the default/first one
included.
In WikiManager#getAll() javadoc I see "(except the main one)".Is this
the only method that must treat (by contract) the main wiki
differently? How do getById() and exists() behave for instance
regarding the main wiki?
The javadoc on an interface / API is very
important as it indicates what the implementation should do. So it
must state very clear any special use cases.
+1 the most important is the Javadoc, you would probably get less questions ;)
Hope this helps,
Marius
On Mon, Oct 7, 2013 at 6:17 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
--
Thomas Mortagne
Thanks to your advices (Eddy and Thomas), I
propose you a clean version:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
I have only changed the API, not the implementation.
I think it starts to be clean.
2013/10/7 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi Eddy.
First, thanks for your answer.
2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi Guilllaume,
1) What is the point of the WikiDescriptorAlias class if it just holds and
returns a string?
Also, the only method in the
WikiDescriptorManager that works with aliases
accepts a String instead of the WikiDescriptorAlias class, so this means
that the class is useless:
WikiDescriptor getByWikiAlias(String wikiAlias) throws
WikiManagerException;
I did not really think about it, I just take the work done by Vincent on
wiki descriptors.
2) WikiManager:
The methods wikiIdExists and and isWikiIdAvailable do the same thing, they
just call it differently. Use only one, like wikiExists().
I should have added the javadoc about that. This is what I have in mind :
- wikiExists(String wikiOd) as you said
- wikiAvailable(String wikiId) that checks if the wiki id is valid and
free (that means that there is no existing database with that name -- not
necessary related to XWiki).
It is not implemented yet.
Also, since it's a WikiManager, so the "wiki" part is in the name of the
class, we get it that it deals with wikis. You could remove the "wiki"
part
from method names, like:
- create instead of createWiki
- delete instead of deleteWiki
- exists instead of existsWiki
- so on...
I agree. I'll change it ;)
Note on the naming of methods:
I`ve noticed a rather annoying thing in the way the methods are named. So
you have a class that is say... WikiDescriptor.
Indeed, but a Wiki class would not contain something else than a
descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
3) WikiManager:
What is the point of these 2 methods?
void setDescriptor(WikiDescriptor descriptor);
void removeDescriptor(WikiDescriptor descriptor);
Looking at the implementation, I see that you`re handling descriptors
(setting/deleting) whithout corelating it to the wikis. I mean, if you
remove a descriptor, then you must remove the wiki too, and that is the
task of the WikiManager.delete() method.
I have keeped them because it is used in the descriptors implementation of
Vincent. But I agree that it is weird to have it in the API.
4) Don`t use implementation details. Improve the interface (API) if there
is information you`re missing:
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I disagree.
In this code, I need to have the document related to the descriptor. It
depends on the current implementation, because we can imagine an
implementation where the descriptors are not stored in the wiki. So I won't
add a getDocument() in the API, but I need it in my implementation.
5) DefaultWikiManager.createDescritptor
Since you have a WikiDescriptorBuilder class, maybe that is where the
logic
of creating/building the descriptor's details (objects, document) and
where
the logic of extracting the document name from wiki name and viceversa
should be located.
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I agree, I will move that code into WikiDescriptorBuilder.
6) DefaultWikiManager.getByWikiId
Again seeing the logic of wikiID-to-document. It should be located in a
single place and not spread in multiple places. Use a method of the
WikiManager class or of the DescriptorBuilder class.
OK.
7) WikiManagerScriptService:
- deleteWiki: Why do you need Admin right to delete a wiki when you did
not
need it in order to create it? That`s bad. We should probably have a
deleteWiki right as well.
It is a temporary solution in my implementation.
The problem is: who has the right to remove a wiki ?
- his owner? But we don't have the notion of owner in this API. It belongs
to the wiki-users module to handle this concept.
- someone who has the CREATE_WIKI right? That means every person who has
the CREATE_WIKI right can also delete any existing wiki?
- someone who as the DELETE_WIKI right? Why not, but we need to make a
vote for adding this new right.
So, in my first implementation, I have used the admin right.
Also, consider the workspaces use case when user
create and delete wikis/workspaces when they want to and when they are
done
with them.
To me, it belongs to the future wiki-user module.
- context key for exceptions
"lastexception2" is not the best of choices.
Try something like "wikiException" instead, or even just
"lastexception"
like it was before (if we consider this as a best practice). What's the
reason for "lastexception2"?
It's a bad commit. I have setted this name for debugging reason.
As a general note, I fail to see the added value of this module at this
point. I mean, the whole point was to have both the functionality of
WikiManager and Workspaces. I get it that it's a work in progress and that
it's at the first stages, but you need to touch those points before it
becomes relevant. Not that it's bad, just that it's not much there to see
at this point.
The idea is to split in different simple modules, that enable us to easily
add a new feature or to depends on a module without depending on the whole
core. I try to reduce the dependencies while I design the modules.
Hope this helps,
Eduard
Thanks Eduard!
Louis-Marie
On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> Hi.
>
> In this thread, I want to propose you the tiniest API that we need to
> handle multiwiki. All other features (users, templates, workspaces...)
will
> be on other modules, because I think it is better for the extensibility.
>
> The new module will be based on the xwiki-platform-wiki-descriptor-api
> module, that I will rename to xwiki-platform-wiki-api. The
> WikiDescriptorManager becomes WikiManager and handle both descriptors
and
> databases.
>
> This API will permit:
> * to create a wiki
> * to remove a wiki
> * to list all wikis (returning a list of descriptors)
> * ...
>
> You can see the code of that proposal there:
>
>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
>
> The most important is to decide what the API must look like. The
> implementation can still be modified afterwards.
>
> I hope you like it,
>
> Louis-Marie
> _______________________________________________
> 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
3:41 p.m.
Thanks for all your answers.
I continue to iterate until we reach something nice. You can see the work
there:
https://github.com/gdelhumeau/xwiki-platform/tree/feature-wiki-properties-g…
I think my mistakes until now was the fact that I didn't want to deviate
too much from the wiki-descriptor module of Vincent. But now, I understand
it is better to make something new.
Now, the API has a complete javadoc.
= Modularity =
== Reduce responsibility ==
The first advantage of creating several modules is to reduce the
responsibility of each module. I want one API to handle the wiki creation
and basic management, one API for the template feature (which could be
optional as soon as we have flavors), and one API for the ability to
manager users (both the farm and the workspaces use-cases). I think it's a
good thing to avoid creating a new oldcore. I know this module is too
simple yet to be comparable with oldcore, but I try to design things in
this way.
== Reduce dependencies ==
The second advantage, is that I try to reduce the dependencies for each
module. That means, if a module only needs the list of wikis (and a lot of
modules needs it), they won't have plenty of dependencies.
For example, the extension manager needs the list of all wikis, but doesn't
care about theirs users, the templates, etc... So it does not need to
depend on the users module, etc...
== About WikiPropertiesGroup ==
The idea behind this new class is to easily add custom properties in the
descriptor for new modules. Each module provides its own
WikiPropertiesGroupProvider that load and save custom properties for the
wiki. Then, it would be easy to get a property:
wikiDescriptor.get("template").get("isTemplate") or (in velocity)
$wikiDescriptor.template.isTemplate. But we can also create typed wrappers
that access to theses properties.
Actually, in the WikiManager, we have a cache that avoid to look at the
database every time a module needs a descriptor. By using theses properties
groups, we can extend what a descriptor is and make good use of the cache
without re-implementing it in every modules.
= Misc =
* I have replace getByWikiId() by getById() and so on...
* getAll() will now return the main wiki as well.
* Aliases are now normal string, and the default alias is stored in the
same list than the other alias.
* WikiDescriptor is now the name used, not "Wiki".
* I have added an hidden field in the descriptor.
* I have added an ownerId field in the descriptor.
* I have added a main page field in the descriptor.
* We may need a WikiManager#getMainWiki(), WDYT?
* There is no implementation for all of this, right now, I'm waiting for
the API to be defined.
Thanks,
Louis-Marie
2013/10/8 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
On Tue, Oct 8, 2013 at 8:53 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi Guillaume,
I also don't see the point of a typed WikiAlias for now and in
Wiki#getWikiId() the "Wiki" is redundant. Why not simply Wiki#getId()
and Wiki#getAlias()?
And what is the difference between
'wikiAlias'
and 'descriptorAliases' (no javadoc)? If a wiki can have multiple
aliases then why not keep just a list and handle the first item
differently if needed (like ServletRequest#getParameter() vs.
ServletRequest#getParameterValues()).
Same for me, this does not make much sense. The wiki has a list of
aliases and the URL factory happen to use the first one. Either you
keep only the list of you rename wikiAlias into default alias to be
extra safe on what should be used when generating a URL but in all
cases the list should contain all aliases, the default/first one
included.
In WikiManager#getAll() javadoc I see "(except the main one)".Is this
the only method that must treat (by contract) the main wiki
differently? How do getById() and exists() behave for instance
regarding the main wiki?
The javadoc on an interface / API is very
important as it indicates what the implementation should do. So it
must state very clear any special use cases.
+1 the most important is the Javadoc, you would probably get less
questions ;)
Hope this helps,
Marius
On Mon, Oct 7, 2013 at 6:17 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
> Thanks to your advices (Eddy and Thomas), I propose you a clean version:
>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
>
> I have only changed the API, not the implementation.
>
> I think it starts to be clean.
>
>
> 2013/10/7 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
>
>> Hi Eddy.
>>
>> First, thanks for your answer.
>>
>> 2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
>>
>>> Hi Guilllaume,
>>>
>>> 1) What is the point of the WikiDescriptorAlias class if it just
holds
and
>>> returns a string?
>>>
>>
>>> Also, the only method in the WikiDescriptorManager that works with
aliases
>>> accepts a String instead of the
WikiDescriptorAlias class, so this
means
>>> that the class is useless:
>>>
>>> WikiDescriptor getByWikiAlias(String wikiAlias) throws
>>> WikiManagerException;
>>>
>>
>> I did not really think about it, I just take the work done by Vincent
on
>> wiki descriptors.
>>
>>
>>> 2) WikiManager:
>>>
>>> The methods wikiIdExists and and isWikiIdAvailable do the same thing,
they
>>> just call it differently. Use only
one, like wikiExists().
>>>
>>
>> I should have added the javadoc about that. This is what I have in
mind :
>> - wikiExists(String wikiOd) as you said
>> - wikiAvailable(String wikiId) that checks if the wiki id is valid and
>> free (that means that there is no existing database with that name --
not
>> necessary related to XWiki).
>>
>> It is not implemented yet.
>>
>>
>>>
>>> Also, since it's a WikiManager, so the "wiki" part is in the
name of
the
>>> class, we get it that it deals with
wikis. You could remove the "wiki"
>>> part
>>> from method names, like:
>>> - create instead of createWiki
>>> - delete instead of deleteWiki
>>> - exists instead of existsWiki
>>> - so on...
>>>
>>
>> I agree. I'll change it ;)
>>
>>
>>>
>>> Note on the naming of methods:
>>> I`ve noticed a rather annoying thing in the way the methods are
named.
So
>>> you have a class that is say...
WikiDescriptor.
>>>
>>
>> Indeed, but a Wiki class would not contain something else than a
>> descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
>>
>>
>>>
>>> 3) WikiManager:
>>>
>>> What is the point of these 2 methods?
>>>
>>> void setDescriptor(WikiDescriptor descriptor);
>>>
>>> void removeDescriptor(WikiDescriptor descriptor);
>>>
>>> Looking at the implementation, I see that you`re handling descriptors
>>> (setting/deleting) whithout corelating it to the wikis. I mean, if you
>>> remove a descriptor, then you must remove the wiki too, and that is
the
>>> task of the WikiManager.delete()
method.
>>>
>>
>> I have keeped them because it is used in the descriptors
implementation
of
>> Vincent. But I agree that it is weird to
have it in the API.
>>
>>
>>>
>>> 4) Don`t use implementation details. Improve the interface (API) if
there
>>> is information you`re missing:
>>>
>>>
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
>>>
>>
>> I disagree.
>> In this code, I need to have the document related to the descriptor. It
>> depends on the current implementation, because we can imagine an
>> implementation where the descriptors are not stored in the wiki. So I
won't
>> add a getDocument() in the API, but I
need it in my implementation.
>>
>>
>>>
>>> 5) DefaultWikiManager.createDescritptor
>>> Since you have a WikiDescriptorBuilder class, maybe that is where the
>>> logic
>>> of creating/building the descriptor's details (objects, document) and
>>> where
>>> the logic of extracting the document name from wiki name and viceversa
>>> should be located.
>>>
>>>
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
>>>
>>
>> I agree, I will move that code into WikiDescriptorBuilder.
>>
>>
>>>
>>> 6) DefaultWikiManager.getByWikiId
>>> Again seeing the logic of wikiID-to-document. It should be located in
a
>>> single place and not spread in
multiple places. Use a method of the
>>> WikiManager class or of the DescriptorBuilder class.
>>>
>>
>> OK.
>>
>>
>>>
>>> 7) WikiManagerScriptService:
>>> - deleteWiki: Why do you need Admin right to delete a wiki when you
did
>>> not
>>> need it in order to create it? That`s bad. We should probably have a
>>> deleteWiki right as well.
>>
>>
>> It is a temporary solution in my implementation.
>> The problem is: who has the right to remove a wiki ?
>> - his owner? But we don't have the notion of owner in this API. It
belongs
>> to the wiki-users module to handle this
concept.
>> - someone who has the CREATE_WIKI right? That means every person who
has
>> the CREATE_WIKI right can also delete any
existing wiki?
>> - someone who as the DELETE_WIKI right? Why not, but we need to make a
>> vote for adding this new right.
>>
>> So, in my first implementation, I have used the admin right.
>>
>>
>>> Also, consider the workspaces use case when user
>>> create and delete wikis/workspaces when they want to and when they are
>>> done
>>> with them.
>>>
>>
>> To me, it belongs to the future wiki-user module.
>>
>>
>>> - context key for exceptions "lastexception2" is not the best of
choices.
>>> Try something like
"wikiException" instead, or even just
"lastexception"
>>> like it was before (if we consider
this as a best practice). What's
the
>>> reason for
"lastexception2"?
>>>
>>>
>> It's a bad commit. I have setted this name for debugging reason.
>>
>>
>>>
>>> As a general note, I fail to see the added value of this module at
this
>>> point. I mean, the whole point was to
have both the functionality of
>>> WikiManager and Workspaces. I get it that it's a work in progress and
that
>>> it's at the first stages, but you
need to touch those points before it
>>> becomes relevant. Not that it's bad, just that it's not much there to
see
>>> at this point.
>>>
>>
>> The idea is to split in different simple modules, that enable us to
easily
>> add a new feature or to depends on a
module without depending on the
whole
>> core. I try to reduce the dependencies
while I design the modules.
>>
>>
>>>
>>> Hope this helps,
>>> Eduard
>>>
>>>
>> Thanks Eduard!
>>
>> Louis-Marie
>>
>>
>>>
>>> On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau
<
>>> gdelhumeau(a)xwiki.com> wrote:
>>>
>>> > Hi.
>>> >
>>> > In this thread, I want to propose you the tiniest API that we need
to
>>> > handle multiwiki. All other
features (users, templates,
workspaces...)
>>> will
>>> > be on other modules, because I think it is better for the
extensibility.
>>> >
>>> > The new module will be based on the
xwiki-platform-wiki-descriptor-api
>>> > module, that I will rename to
xwiki-platform-wiki-api. The
>>> > WikiDescriptorManager becomes WikiManager and handle both
descriptors
>>> and
>>> > databases.
>>> >
>>> > This API will permit:
>>> > * to create a wiki
>>> > * to remove a wiki
>>> > * to list all wikis (returning a list of descriptors)
>>> > * ...
>>> >
>>> > You can see the code of that proposal there:
>>> >
>>> >
>>>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
> >
> > The most important is to decide what the API must look like. The
> > implementation can still be modified afterwards.
> >
> > I hope you like it,
> >
> > Louis-Marie
> > _______________________________________________
> > 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
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9 Oct
9 Oct
2:15 p.m.
Hi,
On Tue, Oct 8, 2013 at 4:41 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Thanks for all your answers.
I continue to iterate until we reach something nice. You can see the work
there:
https://github.com/gdelhumeau/xwiki-platform/tree/feature-wiki-properties-g…
I think my mistakes until now was the fact that I didn't want to deviate
too much from the wiki-descriptor module of Vincent. But now, I understand
it is better to make something new.
Now, the API has a complete javadoc.
= Modularity =
== Reduce responsibility ==
The first advantage of creating several modules is to reduce the
responsibility of each module. I want one API to handle the wiki creation
and basic management, one API for the template feature (which could be
optional as soon as we have flavors),
This transition will most certainly require some considerable refactoring
and possibly some method deprecating, for which we already have a strategy,
at least for the workspaces UI.
Basically, you`d right now be using a $services.wiki.createWiki('newWiki')
to create the wiki followed by a
$services.wikiTemplate.apply('someWikiTemplateName', 'newWiki') to
initialize the wiki with content.
When we`d have flavours, you`d probably follow the creation step with a
$services.extension.install('someFlavourExtensionID', 'newWiki') to
initialize the wiki with the content of a flavour extension.
We`d probably also want to keep the option of importing the content from a
XAR, so that might be a option too.
So this wikiTemplate service would probably contain some methods like:
- create/convert (since the argument would probably be a wikiID to mark as
template. The content of that wiki would have previously be initialized
from an extension of from a XAR)
- list/getAll (wikis marked as templates)
- delete/revert (remove the template mark, resulting in a regular wiki once
again)
- isTemplate (wikiID)
- apply (as seen above, copy the content to an empty wiki)
Side Note1: It could get a bit ugly fast when having to list wikis. What do
you do with templates? What do users see, what do admins see if you plan to
have a single view(UI) for everything? Probably 2 UIs would fit best
(similar to what we have not with WikiManagerUI and WorkspacesUI). The
WikiManager part would probably go in the main wiki's administration (for
admins) and the WorkspacesUI part would be in the main wiki's WikiIndex
(for users).
Side Note2: While thinking about templates, I thought that we might need
some "copy" and "rename" methods for the WikiManager API, since they
might
operations that the user might want to perform without having to use
templates or some other weird operations.
and one API for the ability to
manager users (both the farm and the workspaces
use-cases).
Do you mean operations like:
- join
- leave
- invite
- acceptInvitation
- cancelInvitation
- getMembers
- isMember
- etc, all the stuff that it's now written as velocity code in the
workspaces-ui pages?
If so, than this could be indeed a useful script service to lighten up the
velocity pages that are full of duplicate code.
However, for the farm use case I don`t see any applications of this
service, since the farm use case would be using the same tools that are
currently available to the main wiki.
I think it's a
good thing to avoid creating a new oldcore. I know
this module is too
simple yet to be comparable with oldcore, but I try to design things in
this way.
== Reduce dependencies ==
The second advantage, is that I try to reduce the dependencies for each
module. That means, if a module only needs the list of wikis (and a lot of
modules needs it), they won't have plenty of dependencies.
For example, the extension manager needs the list of all wikis, but doesn't
care about theirs users, the templates, etc... So it does not need to
depend on the users module, etc...
== About WikiPropertiesGroup ==
The idea behind this new class is to easily add custom properties in the
descriptor for new modules. Each module provides its own
WikiPropertiesGroupProvider that load and save custom properties for the
wiki. Then, it would be easy to get a property:
wikiDescriptor.get("template").get("isTemplate") or (in velocity)
$wikiDescriptor.template.isTemplate. But we can also create typed wrappers
that access to theses properties.
Care to provide other (practical) examples of where such properties might
be useful?
Actually, in the WikiManager, we have a cache that avoid to look at the
database every time a module needs a descriptor. By using theses properties
groups, we can extend what a descriptor is and make good use of the cache
without re-implementing it in every modules.
= Misc =
* I have replace getByWikiId() by getById() and so on...
* getAll() will now return the main wiki as well.
* Aliases are now normal string, and the default alias is stored in the
same list than the other alias.
* WikiDescriptor is now the name used, not "Wiki".
* I have added an hidden field in the descriptor.
* I have added an ownerId field in the descriptor.
* I have added a main page field in the descriptor.
* We may need a WikiManager#getMainWiki(), WDYT?
We have $xcontext.mainWikiName that we use everywhere. Maybe it won`t hurt
to have a "cleaner" way of getting the main wiki's descriptor/name without
relying on the deprecated XWikiContext.
Thanks,
Eduard
P.S.: Excuse my rant above on technical details/API. In the absence of
better details, I had to imagine/picture it for myself to better understand
what you meant :)
* There is no implementation for all of this, right now, I'm waiting for
the API to be defined.
Thanks,
Louis-Marie
2013/10/8 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
thing,
"wiki"
descriptors
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
the
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
and
--
Thomas Mortagne
_______________________________________________
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
On Tue, Oct 8, 2013 at 8:53 AM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
version:
Hi Guillaume,
I also don't see the point of a typed WikiAlias for now and in
Wiki#getWikiId() the "Wiki" is redundant. Why not simply Wiki#getId()
and Wiki#getAlias()?
And what is the difference between
'wikiAlias'
and 'descriptorAliases' (no javadoc)? If a wiki can have multiple
aliases then why not keep just a list and handle the first item
differently if needed (like ServletRequest#getParameter() vs.
ServletRequest#getParameterValues()).
Same for me, this does not make much sense. The wiki has a list of
aliases and the URL factory happen to use the first one. Either you
keep only the list of you rename wikiAlias into default alias to be
extra safe on what should be used when generating a URL but in all
cases the list should contain all aliases, the default/first one
included.
In WikiManager#getAll() javadoc I see "(except the main one)".Is this
the only method that must treat (by contract) the main wiki
differently? How do getById() and exists() behave for instance
regarding the main wiki?
The javadoc on an interface / API is very
important as it indicates what the implementation should do. So it
must state very clear any special use cases.
+1 the most important is the Javadoc, you would probably get less
questions ;)
>
> Hope this helps,
> Marius
>
> On Mon, Oct 7, 2013 at 6:17 PM, Guillaume "Louis-Marie" Delhumeau
> <gdelhumeau(a)xwiki.com> wrote:
>> Thanks to your advices (Eddy and Thomas), I propose you a clean >
>
> I have only changed the API, not the implementation.
>
> I think it starts to be clean.
>
>
> 2013/10/7 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
>
>> Hi Eddy.
>>
>> First, thanks for your answer.
>>
>> 2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
>>
>>> Hi Guilllaume,
>>>
>>> 1) What is the point of the WikiDescriptorAlias class if it just
holds
and
>>> returns a string?
>>>
>>
>>> Also, the only method in the WikiDescriptorManager that works with
aliases
>>> accepts a String instead of the
WikiDescriptorAlias class, so this
means
>>> that the class is useless:
>>>
>>> WikiDescriptor getByWikiAlias(String wikiAlias) throws
>>> WikiManagerException;
>>>
>>
>> I did not really think about it, I just take the work done by Vincent
on
>>> wiki descriptors.
>>>
>>>
>>>> 2) WikiManager:
>>>>
>>>> The methods wikiIdExists and and isWikiIdAvailable do the same they
and
>>> just call it differently. Use only
one, like wikiExists().
>>>
>>
>> I should have added the javadoc about that. This is what I have in
mind :
>>> - wikiExists(String wikiOd) as you said
>>> - wikiAvailable(String wikiId) that checks if the wiki id is valid >>
free (that means that there is no existing database with that name --
not
>> necessary related to XWiki).
>>
>> It is not implemented yet.
>>
>>
>>>
>>> Also, since it's a WikiManager, so the "wiki" part is in the
name of
the
>>>> class, we get it that it deals with wikis. You could remove the
>>> part
>>> from method names, like:
>>> - create instead of createWiki
>>> - delete instead of deleteWiki
>>> - exists instead of existsWiki
>>> - so on...
>>>
>>
>> I agree. I'll change it ;)
>>
>>
>>>
>>> Note on the naming of methods:
>>> I`ve noticed a rather annoying thing in the way the methods are
named.
So
>>>> you have a class that is say... WikiDescriptor.
>>>>
>>>
>>> Indeed, but a Wiki class would not contain something else than a
>>> descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
>>>
>>>
>>>>
>>>> 3) WikiManager:
>>>>
>>>> What is the point of these 2 methods?
>>>>
>>>> void setDescriptor(WikiDescriptor descriptor);
>>>>
>>>> void removeDescriptor(WikiDescriptor descriptor);
>>>>
>>>> Looking at the implementation, I see that you`re handling >>>> (setting/deleting) whithout
corelating it to the wikis. I mean, if
you
>>> remove a descriptor, then you must remove the wiki too, and that is
the
>>> task of the WikiManager.delete()
method.
>>>
>>
>> I have keeped them because it is used in the descriptors
implementation
of
>> Vincent. But I agree that it is weird to
have it in the API.
>>
>>
>>>
>>> 4) Don`t use implementation details. Improve the interface (API) if
there
>>> is information you`re missing:
>>>
>>>
>>>>
>>>
>>> I disagree.
>>> In this code, I need to have the document related to the descriptor.
It
>>
depends on the current implementation, because we can imagine an
>> implementation where the descriptors are not stored in the wiki. So I
won't
>>> add a getDocument() in the API, but I need it in my implementation.
>>>
>>>
>>>>
>>>> 5) DefaultWikiManager.createDescritptor
>>>> Since you have a WikiDescriptorBuilder class, maybe that is where >>>> logic
>>>> of creating/building the descriptor's details (objects, document)
and
>>>> where
>>>> the logic of extracting the document name from wiki name and
viceversa
>>> should be located.
>>>
>>>
>>>>
>>>
>>> I agree, I will move that code into WikiDescriptorBuilder.
>>>
>>>
>>>>
>>>> 6) DefaultWikiManager.getByWikiId
>>>> Again seeing the logic of wikiID-to-document. It should be located
in
a
a
>>> single place and not spread in
multiple places. Use a method of the
>>> WikiManager class or of the DescriptorBuilder class.
>>>
>>
>> OK.
>>
>>
>>>
>>> 7) WikiManagerScriptService:
>>> - deleteWiki: Why do you need Admin right to delete a wiki when you
did
>>> not
>>> need it in order to create it? That`s bad. We should probably have a
>>> deleteWiki right as well.
>>
>>
>> It is a temporary solution in my implementation.
>> The problem is: who has the right to remove a wiki ?
>> - his owner? But we don't have the notion of owner in this API. It
belongs
>> to the wiki-users module to handle this
concept.
>> - someone who has the CREATE_WIKI right? That means every person who
has
>>> the CREATE_WIKI right can also delete any existing wiki?
>>> - someone who as the DELETE_WIKI right? Why not, but we need to make >>> vote for adding this new right.
>>>
>>> So, in my first implementation, I have used the admin right.
>>>
>>>
>>>> Also, consider the workspaces use case when user
>>>> create and delete wikis/workspaces when they want to and when they
are
>>> done
>>> with them.
>>>
>>
>> To me, it belongs to the future wiki-user module.
>>
>>
>>> - context key for exceptions "lastexception2" is not the best of
choices.
>>> Try something like
"wikiException" instead, or even just
"lastexception"
>>> like it was before (if we consider
this as a best practice). What's
the
>>> reason for
"lastexception2"?
>>>
>>>
>> It's a bad commit. I have setted this name for debugging reason.
>>
>>
>>>
>>> As a general note, I fail to see the added value of this module at
this
>>>> point. I mean, the whole point was to have both the functionality of
>>>> WikiManager and Workspaces. I get it that it's a work in progress
that
>>>> it's at the first stages, but you need to touch those points before
it
>>>> becomes relevant. Not that
it's bad, just that it's not much there
to
see
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
>>> at this point.
>>>
>>
>> The idea is to split in different simple modules, that enable us to
easily
>> add a new feature or to depends on a
module without depending on the
whole
>> core. I try to reduce the dependencies
while I design the modules.
>>
>>
>>>
>>> Hope this helps,
>>> Eduard
>>>
>>>
>> Thanks Eduard!
>>
>> Louis-Marie
>>
>>
>>>
>>> On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau
<
>>> gdelhumeau(a)xwiki.com> wrote:
>>>
>>> > Hi.
>>> >
>>> > In this thread, I want to propose you the tiniest API that we need
to
>>> > handle multiwiki. All other
features (users, templates,
workspaces...)
>>> will
>>> > be on other modules, because I think it is better for the
extensibility.
>>> >
>>> > The new module will be based on the
xwiki-platform-wiki-descriptor-api
>>> > module, that I will rename to
xwiki-platform-wiki-api. The
>>> > WikiDescriptorManager becomes WikiManager and handle both
descriptors
>>> and
>>> > databases.
>>> >
>>> > This API will permit:
>>> > * to create a wiki
>>> > * to remove a wiki
>>> > * to list all wikis (returning a list of descriptors)
>>> > * ...
>>> >
>>> > You can see the code of that proposal there:
>>> >
>>> >
>>>
>> >
>> > The most important is to decide what the API must look like. The
>> > implementation can still be modified afterwards.
>> >
>> > I hope you like it,
>> >
>> > Louis-Marie
>> > _______________________________________________
>> > 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
>>
>
>
_______________________________________________
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
10 Oct
10 Oct
10:46 a.m.
Hi Eduard,
2013/10/9 Eduard Moraru <enygma2002(a)gmail.com>
I agree.
Hi,
On Tue, Oct 8, 2013 at 4:41 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Currently, the workspaces UI is a kind of a hack. WorkspaceManager.Install
create a new template where we install a standard XAR UI + Workspace
Template Feature (that overwrites some standard pages) + delete some pages
that we don't need, etc... It forces us to ask the user to create
workspacetemplate first, it does not work out of the box. And we need to
have 2 distinct XARs to handle the 2 use-cases: farm and workspaces. It is
definitively not clean.
When talking with Vincent about this, we decided that it would be better to
create a unique XAR that handle the 2 use-cases. It will just look at the
wiki configuration to know if we have local users or not, what is the
membership type of the wiki, etc...
So, I apologize to not having talk here about that. I think that we should,
indeed, refactor a lot of things to have a very clean multiwiki feature in
5.3.
Thanks for all your answers.
I continue to iterate until we reach something nice. You can see the work
there:
https://github.com/gdelhumeau/xwiki-platform/tree/feature-wiki-properties-g…
I think my mistakes until now was the fact that I didn't want to deviate
too much from the wiki-descriptor module of Vincent. But now, I
understand
it is better to make something new.
Now, the API has a complete javadoc.
= Modularity =
== Reduce responsibility ==
The first advantage of creating several modules is to reduce the
responsibility of each module. I want one API to handle the wiki creation
and basic management, one API for the template feature (which could be
optional as soon as we have flavors),
This transition will most certainly require some considerable refactoring
and possibly some method deprecating, for which we already have a strategy,
at least for the workspaces UI.
Basically, you`d right now be using a $services.wiki.createWiki('newWiki')
to create the wiki followed by a
$services.wikiTemplate.apply('someWikiTemplateName', 'newWiki') to
initialize the wiki with content.
When we`d have flavours, you`d probably follow the creation step with a
$services.extension.install('someFlavourExtensionID', 'newWiki') to
initialize the wiki with the content of a flavour extension.
We`d probably also want to keep the option of importing the content from a
XAR, so that might be a option too.
So this wikiTemplate service would probably contain some methods like:
- create/convert (since the argument would probably be a wikiID to mark as
template. The content of that wiki would have previously be initialized
from an extension of from a XAR)
I have proposed setTemplate(boolean template);
- list/getAll (wikis marked as templates)
- delete/revert (remove the template mark, resulting in a regular wiki once
again)
- isTemplate (wikiID)
- apply (as seen above, copy the content to an empty wiki)
I was thinking about createWikiFromTemplate() instead, but maybe it does
not provide enough flexibility.
Side Note1: It could get a bit ugly fast when having to list wikis. What do
you do with templates? What do users see, what do admins see if you plan to
have a single view(UI) for everything? Probably 2 UIs would fit best
(similar to what we have not with WikiManagerUI and WorkspacesUI). The
WikiManager part would probably go in the main wiki's administration (for
admins) and the WorkspacesUI part would be in the main wiki's WikiIndex
(for users).
That is an interesting question. I did not think that much about the UI
until now. I wanted to have a clean API first.
Side Note2: While thinking about templates, I thought that we might need
some "copy" and "rename" methods for the WikiManager API, since they
might
operations that the user might want to perform without having to use
templates or some other weird operations.
- Rename would be hard to implement (copy the wiki and delete it?)
- What "copy a wiki" means? Should we copy the history of every pages too?
Should we copy the recycle bin? I did not want to provide a copy feature
because of these questions. The template feature actually does a copy
operation but with its own opinion concerning this aspects : no history
copied, no recycle bin.
and one API for the ability to
I think it's the only way to have a clean code, and will probably make it
easier to have only 1 XAR for the 2 use-cases.
manager users (both the farm and the workspaces
use-cases).
Do you mean operations like:
- join
- leave
- invite
- acceptInvitation
- cancelInvitation
- getMembers
- isMember
- etc, all the stuff that it's now written as velocity code in the
workspaces-ui pages?
If so, than this could be indeed a useful script service to lighten up the
velocity pages that are full of duplicate code.
However, for the farm use case I don`t see any
applications of this
service, since the farm use case would be using the same tools that are
currently available to the main wiki.
I think it's a
Imagine a new Activity Stream that needs to store information about each
wiki, like "the main AS should index the events of this wiki" or "users of
that wiki can send a message to main users", etc... Where AS should store
this information? WikiPropertyGroup is good for that.
The membership type and the "enable local users" could be stored there too.
Ludo told me that clients would like to disable extension manager in
(sub)wiki, or to restrict it to main admins only. If we decide to implement
this, we could store the EM configuration in the property groups...
I think it is easy to implement and could be very useful for a lot of
use-cases that we don't even imagine yet. In my opinion, having this
flexibility can not be bad.
good thing to avoid creating a new oldcore. I
know this module is too
simple yet to be comparable with oldcore, but I try to design things in
this way.
== Reduce dependencies ==
The second advantage, is that I try to reduce the dependencies for each
module. That means, if a module only needs the list of wikis (and a lot
of
modules needs it), they won't have plenty of
dependencies.
For example, the extension manager needs the list of all wikis, but
doesn't
care about theirs users, the templates, etc... So
it does not need to
depend on the users module, etc...
== About WikiPropertiesGroup ==
The idea behind this new class is to easily add custom properties in the
descriptor for new modules. Each module provides its own
WikiPropertiesGroupProvider that load and save custom properties for the
wiki. Then, it would be easy to get a property:
wikiDescriptor.get("template").get("isTemplate") or (in velocity)
$wikiDescriptor.template.isTemplate. But we can also create typed
wrappers
that access to theses properties.
Care to provide other (practical) examples of where such properties might
be useful?
Actually, in the WikiManager, we have a cache that avoid to look at the
database every time a module needs a descriptor. By using theses
properties
groups, we can extend what a descriptor is and
make good use of the cache
without re-implementing it in every modules.
= Misc =
* I have replace getByWikiId() by getById() and so on...
* getAll() will now return the main wiki as well.
* Aliases are now normal string, and the default alias is stored in the
same list than the other alias.
* WikiDescriptor is now the name used, not "Wiki".
* I have added an hidden field in the descriptor.
* I have added an ownerId field in the descriptor.
* I have added a main page field in the descriptor.
* We may need a WikiManager#getMainWiki(), WDYT?
We have $xcontext.mainWikiName that we use everywhere. Maybe it won`t hurt
to have a "cleaner" way of getting the main wiki's descriptor/name without
relying on the deprecated XWikiContext.
Thanks,
Eduard
P.S.: Excuse my rant above on technical details/API. In the absence of
better details, I had to imagine/picture it for myself to better understand
what you meant :)
I am new to this way of working. I am used to work alone, and for very
specific use cases. I try to improve my communication.
It is not very easy, because some peoples suggest me something while others
advise me the opposite!
Thanks for your concern,
Louis-Marie
* There is no implementation for all of this, right now, I'm waiting for
--
Wiki?
is
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
the
before
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
_______________________________________________
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
the API to be defined.
Thanks,
Louis-Marie
2013/10/8 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
On Tue, Oct 8, 2013 at 8:53 AM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
version:
Hi Guillaume,
I also don't see the point of a typed WikiAlias for now and in
Wiki#getWikiId() the "Wiki" is redundant. Why not simply Wiki#getId()
and Wiki#getAlias()?
And what is the difference between
'wikiAlias'
and 'descriptorAliases' (no javadoc)? If a wiki can have multiple
aliases then why not keep just a list and handle the first item
differently if needed (like ServletRequest#getParameter() vs.
ServletRequest#getParameterValues()).
Same for me, this does not make much sense. The wiki has a list of
aliases and the URL factory happen to use the first one. Either you
keep only the list of you rename wikiAlias into default alias to be
extra safe on what should be used when generating a URL but in all
cases the list should contain all aliases, the default/first one
included.
In WikiManager#getAll() javadoc I see "(except the main one)".Is this
the only method that must treat (by contract) the main wiki
differently? How do getById() and exists() behave for instance
regarding the main wiki?
The javadoc on an interface / API is very
important as it indicates what the implementation should do. So it
must state very clear any special use cases.
+1 the most important is the Javadoc, you would probably get less
questions ;)
>
> Hope this helps,
> Marius
>
> On Mon, Oct 7, 2013 at 6:17 PM, Guillaume "Louis-Marie" Delhumeau
> <gdelhumeau(a)xwiki.com> wrote:
>> Thanks to your advices (Eddy and Thomas), I propose you a clean >
> >>
> >> I have only changed the API, not the implementation.
> >>
> >> I think it starts to be clean.
> >>
> >>
> >> 2013/10/7 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
> >>
> >>> Hi Eddy.
> >>>
> >>> First, thanks for your answer.
> >>>
> >>> 2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
> >>>
> >>>> Hi Guilllaume,
> >>>>
> >>>> 1) What is the point of the WikiDescriptorAlias class if it just
> holds and
> >>>> returns a string?
> >>>>
> >>>
> >>>> Also, the only method in the WikiDescriptorManager that works with
> aliases
> >>>> accepts a String instead of the WikiDescriptorAlias class, so this
> means
> >>>> that the class is useless:
> >>>>
> >>>> WikiDescriptor getByWikiAlias(String wikiAlias) throws
> >>>> WikiManagerException;
> >>>>
> >>>
> >>> I did not really think about it, I just take the work done by
Vincent
on
>>> wiki descriptors.
>>>
>>>
>>>> 2) WikiManager:
>>>>
>>>> The methods wikiIdExists and and isWikiIdAvailable do the same
thing,
they
and
> >>> free (that means that there is no existing database with that name
>>> just call it differently. Use only
one, like wikiExists().
>>>
>>
>> I should have added the javadoc about that. This is what I have in
mind :
>>> - wikiExists(String wikiOd) as you said
>>> - wikiAvailable(String wikiId) that checks if the wiki id is valid > not
> >>> necessary related to XWiki).
> >>>
> >>> It is not implemented yet.
> >>>
> >>>
> >>>>
> >>>> Also, since it's a WikiManager, so the "wiki" part is
in the name
of
the
>>>> class, we get it that it deals with wikis. You could remove the
"wiki"
> >>>> part
> >>>> from method names, like:
> >>>> - create instead of createWiki
> >>>> - delete instead of deleteWiki
> >>>> - exists instead of existsWiki
> >>>> - so on...
> >>>>
> >>>
> >>> I agree. I'll change it ;)
> >>>
> >>>
> >>>>
> >>>> Note on the naming of methods:
> >>>> I`ve noticed a rather annoying thing in the way the methods are
> named. So
> >>>> you have a class that is say... WikiDescriptor.
> >>>>
> >>>
> >>> Indeed, but a Wiki class would not contain something else than a
> >>> descriptor. I don't know what to do. Renaming WikiDescriptor to
>>>
>>>
>>>>
>>>> 3) WikiManager:
>>>>
>>>> What is the point of these 2 methods?
>>>>
>>>> void setDescriptor(WikiDescriptor descriptor);
>>>>
>>>> void removeDescriptor(WikiDescriptor descriptor);
>>>>
>>>> Looking at the implementation, I see that you`re handling
descriptors
>>>> (setting/deleting) whithout
corelating it to the wikis. I mean, if
you
> >>>> remove a descriptor, then you must remove the wiki too, and that
> the
> >>>> task of the WikiManager.delete() method.
> >>>>
> >>>
> >>> I have keeped them because it is used in the descriptors
> implementation of
> >>> Vincent. But I agree that it is weird to have it in the API.
> >>>
> >>>
> >>>>
> >>>> 4) Don`t use implementation details. Improve the interface (API)
if
there
>>> is information you`re missing:
>>>
>>>
> >>>>
> >>>
> >>> I disagree.
> >>> In this code, I need to have the document related to the
descriptor.
It
> >>> depends on the current implementation, because we can imagine an
> >>> implementation where the descriptors are not stored in the wiki.
So I
won't
>>> add a getDocument() in the API, but I need it in my implementation.
>>>
>>>
>>>>
>>>> 5) DefaultWikiManager.createDescritptor
>>>> Since you have a WikiDescriptorBuilder class, maybe that is where
the
>>>> logic
>>>> of creating/building the descriptor's details (objects, document)
and
>>>> where
>>>> the logic of extracting the document name from wiki name and
viceversa
>>> should be located.
>>>
>>>
>>>>
>>>
>>> I agree, I will move that code into WikiDescriptorBuilder.
>>>
>>>
>>>>
>>>> 6) DefaultWikiManager.getByWikiId
>>>> Again seeing the logic of wikiID-to-document. It should be located
in
> a
> >>>> single place and not spread in multiple places. Use a method of
> >>>> WikiManager class or of the
DescriptorBuilder class.
> >>>>
> >>>
> >>> OK.
> >>>
> >>>
> >>>>
> >>>> 7) WikiManagerScriptService:
> >>>> - deleteWiki: Why do you need Admin right to delete a wiki when
you
> did
> >>>> not
> >>>> need it in order to create it? That`s bad. We should probably
have a
> >>>> deleteWiki right as well.
> >>>
> >>>
> >>> It is a temporary solution in my implementation.
> >>> The problem is: who has the right to remove a wiki ?
> >>> - his owner? But we don't have the notion of owner in this API. It
> belongs
> >>> to the wiki-users module to handle this concept.
> >>> - someone who has the CREATE_WIKI right? That means every person
who
> has
> >>> the CREATE_WIKI right can also delete any existing wiki?
> >>> - someone who as the DELETE_WIKI right? Why not, but we need to
make
a
What's
>>> vote for adding this new right.
>>>
>>> So, in my first implementation, I have used the admin right.
>>>
>>>
>>>> Also, consider the workspaces use case when user
>>>> create and delete wikis/workspaces when they want to and when they
are
> >>>> done
> >>>> with them.
> >>>>
> >>>
> >>> To me, it belongs to the future wiki-user module.
> >>>
> >>>
> >>>> - context key for exceptions "lastexception2" is not the
best of
> choices.
> >>>> Try something like "wikiException" instead, or even just
> "lastexception"
> >>>> like it was before (if we consider this as a best practice). > the
> >>>> reason for "lastexception2"?
> >>>>
> >>>>
> >>> It's a bad commit. I have setted this name for debugging reason.
> >>>
> >>>
> >>>>
> >>>> As a general note, I fail to see the added value of this module at
> this
> >>>> point. I mean, the whole point was to have both the functionality
of
>>>> WikiManager and Workspaces. I get it that it's a work in progress
and
> that
> >>>> it's at the first stages, but you need to touch those points
it
the
>>>> becomes relevant. Not that
it's bad, just that it's not much there
to
> see
> >>>> at this point.
> >>>>
> >>>
> >>> The idea is to split in different simple modules, that enable us to
> easily
> >>> add a new feature or to depends on a module without depending on > whole
> >>> core. I try to reduce the dependencies while I design the modules.
> >>>
> >>>
> >>>>
> >>>> Hope this helps,
> >>>> Eduard
> >>>>
> >>>>
> >>> Thanks Eduard!
> >>>
> >>> Louis-Marie
> >>>
> >>>
> >>>>
> >>>> On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie"
Delhumeau <
> >>>> gdelhumeau(a)xwiki.com>
wrote:
> >>>>
> >>>> > Hi.
> >>>> >
> >>>> > In this thread, I want to propose you the tiniest API that we
need
to
>>> > handle multiwiki. All other
features (users, templates,
workspaces...)
>>> will
>>> > be on other modules, because I think it is better for the
extensibility.
>>> >
>>> > The new module will be based on the
xwiki-platform-wiki-descriptor-api
>>> > module, that I will rename to
xwiki-platform-wiki-api. The
>>> > WikiDescriptorManager becomes WikiManager and handle both
descriptors
>>> and
>>> > databases.
>>> >
>>> > This API will permit:
>>> > * to create a wiki
>>> > * to remove a wiki
>>> > * to list all wikis (returning a list of descriptors)
>>> > * ...
>>> >
>>> > You can see the code of that proposal there:
>>> >
>>> >
>>>
>>> >
>>> > The most important is to decide what the API must look like. The
>>> > implementation can still be modified afterwards.
>>> >
>>> > I hope you like it,
>>> >
>>> > Louis-Marie
>>> > _______________________________________________
>>> > 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
>>>
>>
>>
> _______________________________________________
> 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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11 Oct
11 Oct
4:41 p.m.
Hi,
On Thu, Oct 10, 2013 at 11:46 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
creation
strategy,
Neither does wiki manager work out of the box. The current technical
limitations require that the user first creates a template wiki that is
used in the creation of new wikis/workspaces.
Didn`t you mention something earlier about separation of concerns? :)
No, just rename the database and the descriptor. Is there any limitation to
that?
Imagine a new Activity Stream that needs to store information about each
wiki, like "the main AS should index the events of this wiki" or "users
of
that wiki can send a message to main users", etc... Where AS should store
this information? WikiPropertyGroup is good for that.
The membership type and the "enable local users" could be stored there too.
Ludo told me that clients would like to disable extension manager in
(sub)wiki, or to restrict it to main admins only. If we decide to implement
this, we could store the EM configuration in the property groups...
I think it is easy to implement and could be very useful for a lot of
use-cases that we don't even imagine yet. In my opinion, having this
flexibility can not be bad.
Technical note: Looking at the code, I can`t see these WikiPropertyGroups
being handled anywhere. I imagine that you would have to delegate the task
of creating WikiDescriptor instances to the WikiManager which will, in
turn, be in charge of querying all the WikiPropertyGroupProviders and
populating the new WikiDescriptor with these properties before returning it
to the caller.
You speak of WikiPropertyGroup as a storage location. However, in the code,
I see that each provider is supposed to save the properties itself, so it
is in charge of picking a physical location for these properties to be
stored. The WikiDescriptor would only be a logical location where
applications might store and read information/properties **about** the
wiki. When an application would store a new property for a wiki in a
certain property group, that group's provider will be in charge of
physically storing the value in the location where that group's properties
are physically stored.
It would be an interesting idea, but I find that it would be much more
productive as a generic service of its own and not just limited to wikis.
It is easy to imagine the need for such a service in the case of users.
Applications might want to store/query properties for the current user,
maybe for the current space and so on. For users, right now we`re storing
stuff in the user profile. For wikis, we`d probably store it in
XWikiPreferences, SpacePreferences for spaces and so on.
Maybe something a bit like what we do with ConfiguratinSource, but targeted
on certain entities (wikis, users, etc)
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
...however, what I don`t like about ConfigurationSource is that it is
ReadOnly.
Would be a shame to spend the effort and not to make it a generic solution.
WDYT?
cache
hurt
One solution would be to use a common communication channel, like the
mailing list, instead of 1-to-1 talks. This way suggestions can be
discussed and evaluated, mine included :)
And, as usual, sometimes you just have to bite the bullet and make the
decision for yourself instead of waiting forever for answers/solutions from
the list/someone. Things can always be improved in future iterations, but
having nothing to show is never a good thing :)
-Eduard
Hi Eduard,
2013/10/9 Eduard Moraru <enygma2002(a)gmail.com>
https://github.com/gdelhumeau/xwiki-platform/tree/feature-wiki-properties-g…
Side note: I`ve noticed that you have 2 branches where you work, both
feature-wiki-properties-group that you`ve linked to now and new-wiki-api
that you`ve linked to in the initial post. Please use only one since it`s
already quite confusing and hard to follow.
Hi,
On Tue, Oct 8, 2013 at 4:41 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> Thanks for all your answers.
>
> I continue to iterate until we reach something nice. You can see the
work
there:
>
> I think my mistakes until now was the fact that I didn't want to
deviate
too much
from the wiki-descriptor module of Vincent. But now, I
understand
> it is better to make something new.
>
> Now, the API has a complete javadoc.
>
> = Modularity =
> == Reduce responsibility ==
>
> The first advantage of creating several modules is to reduce the
> responsibility of each module. I want one API to handle the wiki and basic
management, one API for the template feature (which could be
optional as soon as we have flavors),
This transition will most certainly require some considerable refactoring
and possibly some method deprecating, for which we already have a at least for the workspaces UI.
Currently, the workspaces UI is a kind of a hack. WorkspaceManager.Install
create a new template where we install a standard XAR UI + Workspace
Template Feature (that overwrites some standard pages) + delete some pages
that we don't need, etc... It forces us to ask the user to create
workspacetemplate first, it does not work out of the box. And we need to
have 2 distinct XARs to handle the 2 use-cases: farm and workspaces. It is
definitively not clean.
When talking with Vincent about this, we decided that it would be better to
create a unique XAR that handle the 2 use-cases.
But again, this does not fix the "out-of-the-box" issue.
It will just look at the
wiki configuration to know if we have local users or not, what is the
membership type of the wiki, etc...
The idea was that an admin could come with his own customized XAR that
would then be "adapted" to be used as a workspace template, if the admin
did not already do that. It was not desired that the user be limited to the
standard XE xar, since that would have been rather easy to implement and
automatically "install".
So, I apologize to not having talk here about that. I
think that we should,
indeed, refactor a lot of things to have a very clean multiwiki feature in
5.3.
Maybe setTemplate(String wikiID) as in,
$services.wikiTemplate.setTemplate('someWiki')
...or even setTemplate(String wikiID, boolean isTemplate) to avoid having a
second removeTemplate(String wikiID) method.
Basically, you`d right now be using a
$services.wiki.createWiki('newWiki')
to create the wiki followed by a
$services.wikiTemplate.apply('someWikiTemplateName', 'newWiki') to
initialize the wiki with content.
When we`d have flavours, you`d probably follow the creation step with a
$services.extension.install('someFlavourExtensionID', 'newWiki') to
initialize the wiki with the content of a flavour extension.
We`d probably also want to keep the option of importing the content from
a
XAR, so that might be a option too.
So this wikiTemplate service would probably contain some methods like:
- create/convert (since the argument would probably be a wikiID to mark
as
template. The content of that wiki would have
previously be initialized
from an extension of from a XAR)
I have proposed setTemplate(boolean template);
- list/getAll (wikis marked as templates)
- delete/revert (remove the template mark, resulting in a regular wiki
once
again)
- isTemplate (wikiID)
- apply (as seen above, copy the content to an empty wiki)
I was thinking about createWikiFromTemplate() instead, but maybe it does
not provide enough flexibility.
Side Note1: It could get a bit ugly fast when having to list wikis. What
do
you do with templates? What do users see, what do
admins see if you plan
to
have a single view(UI) for everything? Probably 2
UIs would fit best
(similar to what we have not with WikiManagerUI and WorkspacesUI). The
WikiManager part would probably go in the main wiki's administration (for
admins) and the WorkspacesUI part would be in the main wiki's WikiIndex
(for users).
That is an interesting question. I did not think that much about the UI
until now. I wanted to have a clean API first.
Side Note2: While thinking about templates, I thought that we might need
some "copy" and "rename" methods for the WikiManager API, since they
might
operations that the user might want to perform
without having to use
templates or some other weird operations.
- Rename would be hard to implement (copy the wiki and delete it?)
- What "copy a wiki" means? Should we copy
the history of every pages too?
Should we copy the recycle bin? I did not want to provide a copy feature
because of these questions. The template feature actually does a copy
operation but with its own opinion concerning this aspects : no history
copied, no recycle bin.
1-to-1 copy of the source wiki. This means everything.
Sure, there might be some applications that use custom mapping and add some
tables to the source database that might not be copied in the process. But,
if we have no way of detecting and copying this data, I think it's not a
bit problem. History and recycle bin are core notions of which we have full
control so they should not be an issue.
Anyway, since we`re reviewing these processes and thinking about them now,
maybe we should do it right. Copy and Rename are basic operations that
should not miss from any data model. We should *at least* include them in
the API and implement them when time allows (and expose them in the UI when
implemented). It would be a shame to have yet another half baked API.
and one API for the ability to
the
manager users (both the farm and the workspaces
use-cases).
Do you mean operations like:
- join
- leave
- invite
- acceptInvitation
- cancelInvitation
- getMembers
- isMember
- etc, all the stuff that it's now written as velocity code in the
workspaces-ui pages?
If so, than this could be indeed a useful script service to lighten up velocity pages that are full of duplicate code.
I think it's the only way to have a clean code, and will probably make it
easier to have only 1 XAR for the 2 use-cases.
However, for the farm use case I don`t see any
applications of this
service, since the farm use case would be using the same tools that are
currently available to the main wiki.
I think it's a
the
good thing to avoid creating a new oldcore. I
know this module is too
simple yet to be comparable with oldcore, but I try to design things in
this way.
== Reduce dependencies ==
The second advantage, is that I try to reduce the dependencies for each
module. That means, if a module only needs the list of wikis (and a lot
of
modules needs it), they won't have plenty of
dependencies.
For example, the extension manager needs the list of all wikis, but
doesn't
> care about theirs users, the templates, etc... So it does not need to
> depend on the users module, etc...
>
> == About WikiPropertiesGroup ==
>
> The idea behind this new class is to easily add custom properties in > descriptor for new modules. Each module
provides its own
> WikiPropertiesGroupProvider that load and save custom properties for
the
wiki.
Then, it would be easy to get a property:
wikiDescriptor.get("template").get("isTemplate") or (in velocity)
$wikiDescriptor.template.isTemplate. But we can also create typed
wrappers
that access to theses properties.
Care to provide other (practical) examples of where such properties might
be useful?
Actually, in the WikiManager, we have a cache that avoid to look at the
database every time a module needs a descriptor. By using theses
properties
> groups, we can extend what a descriptor is and make good use of the without
re-implementing it in every modules.
= Misc =
* I have replace getByWikiId() by getById() and so on...
* getAll() will now return the main wiki as well.
* Aliases are now normal string, and the default alias is stored in the
same list than the other alias.
* WikiDescriptor is now the name used, not "Wiki".
* I have added an hidden field in the descriptor.
* I have added an ownerId field in the descriptor.
* I have added a main page field in the descriptor.
* We may need a WikiManager#getMainWiki(), WDYT?
We have $xcontext.mainWikiName that we use everywhere. Maybe it won`t to have a "cleaner" way of getting the
main wiki's descriptor/name
without
relying on the deprecated XWikiContext.
I agree.
Thanks,
Eduard
P.S.: Excuse my rant above on technical details/API. In the absence of
better details, I had to imagine/picture it for myself to better
understand
what you meant :)
I am new to this way of working. I am used to work alone, and for very
specific use cases. I try to improve my communication.
It is not very easy, because some peoples suggest me something while others
advise me the opposite!
Thanks for your concern,
Louis-Marie
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
with
in
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
implementation.
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
It
they
at
there
modules.
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
_______________________________________________
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
* There is no implementation for all of this, right now, I'm waiting for
> the API to be defined.
>
> Thanks,
> Louis-Marie
>
>
>
>
> 2013/10/8 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
>
> > On Tue, Oct 8, 2013 at 8:53 AM, Marius Dumitru Florea
> > <mariusdumitru.florea(a)xwiki.com> wrote:
> > > Hi Guillaume,
> > >
> > > I also don't see the point of a typed WikiAlias for now and in
> > > Wiki#getWikiId() the "Wiki" is redundant. Why not simply
Wiki#getId()
> > > and Wiki#getAlias()?
> >
> > > And what is the difference between 'wikiAlias'
> > > and 'descriptorAliases' (no javadoc)? If a wiki can have multiple
> > > aliases then why not keep just a list and handle the first item
> > > differently if needed (like ServletRequest#getParameter() vs.
> > > ServletRequest#getParameterValues()).
> >
> > Same for me, this does not make much sense. The wiki has a list of
> > aliases and the URL factory happen to use the first one. Either you
> > keep only the list of you rename wikiAlias into default alias to be
> > extra safe on what should be used when generating a URL but in all
> > cases the list should contain all aliases, the default/first one
> > included.
> >
> > >
> > > In WikiManager#getAll() javadoc I see "(except the main one)".Is
this
> the only method that must treat (by contract) the
main wiki
> differently? How do getById() and exists() behave for instance
> regarding the main wiki?
> The javadoc on an interface / API is very
> important as it indicates what the implementation should do. So it
> must state very clear any special use cases.
+1 the most important is the Javadoc, you would probably get less
questions ;)
>
> Hope this helps,
> Marius
>
> On Mon, Oct 7, 2013 at 6:17 PM, Guillaume "Louis-Marie" Delhumeau
> <gdelhumeau(a)xwiki.com> wrote:
>> Thanks to your advices (Eddy and Thomas), I propose you a clean
version:
>>
>
>>
> >> I have only changed the API, not the implementation.
> >>
> >> I think it starts to be clean.
> >>
> >>
> >> 2013/10/7 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com
> > >>
> > >>> Hi Eddy.
> > >>>
> > >>> First, thanks for your answer.
> > >>>
> > >>> 2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
> > >>>
> > >>>> Hi Guilllaume,
> > >>>>
> > >>>> 1) What is the point of the WikiDescriptorAlias class if it
just
> > holds and
> > >>>> returns a string?
> > >>>>
> > >>>
> > >>>> Also, the only method in the WikiDescriptorManager that works
> > aliases
> > >>>> accepts a String instead of the WikiDescriptorAlias class, so
this
>
means
> >>>> that the class is useless:
> >>>>
> >>>> WikiDescriptor getByWikiAlias(String wikiAlias) throws
> >>>> WikiManagerException;
> >>>>
> >>>
> >>> I did not really think about it, I just take the work done by
Vincent
> > on
> > >>> wiki descriptors.
> > >>>
> > >>>
> > >>>> 2) WikiManager:
> > >>>>
> > >>>> The methods wikiIdExists and and isWikiIdAvailable do the
same
> thing,
> > they
> > >>>> just call it differently. Use only one, like wikiExists().
> > >>>>
> > >>>
> > >>> I should have added the javadoc about that. This is what I have
> > mind :
> > >>> - wikiExists(String wikiOd) as you said
> > >>> - wikiAvailable(String wikiId) that checks if the wiki id is
valid
> and
> > >>> free (that means that there is no existing database with that
name
--
> > not
> > >>> necessary related to XWiki).
> > >>>
> > >>> It is not implemented yet.
> > >>>
> > >>>
> > >>>>
> > >>>> Also, since it's a WikiManager, so the "wiki"
part is in the
name
of
Wiki?
> > >>>
> > >>>
> > >>>>
> > >>>> 3) WikiManager:
> > >>>>
> > >>>> What is the point of these 2 methods?
> > >>>>
> > >>>> void setDescriptor(WikiDescriptor descriptor);
> > >>>>
> > >>>> void removeDescriptor(WikiDescriptor descriptor);
> > >>>>
> > >>>> Looking at the implementation, I see that you`re handling
> descriptors
> > >>>> (setting/deleting) whithout corelating it to the wikis. I
mean,
if
the
>>>> class, we get it that it deals with wikis. You could remove the
"wiki"
> >>>> part
> >>>> from method names, like:
> >>>> - create instead of createWiki
> >>>> - delete instead of deleteWiki
> >>>> - exists instead of existsWiki
> >>>> - so on...
> >>>>
> >>>
> >>> I agree. I'll change it ;)
> >>>
> >>>
> >>>>
> >>>> Note on the naming of methods:
> >>>> I`ve noticed a rather annoying thing in the way the methods are
> named. So
> >>>> you have a class that is say... WikiDescriptor.
> >>>>
> >>>
> >>> Indeed, but a Wiki class would not contain something else than a
> >>> descriptor. I don't know what to do. Renaming WikiDescriptor to
you
> >>>> remove a descriptor, then you must remove the wiki too, and that
is
> the
> >>>> task of the WikiManager.delete() method.
> >>>>
> >>>
> >>> I have keeped them because it is used in the descriptors
> implementation of
> >>> Vincent. But I agree that it is weird to have it in the API.
> >>>
> >>>
> >>>>
> >>>> 4) Don`t use implementation details. Improve the interface (API)
if
there
>>>> is information you`re missing:
>>>>
>>>>
>
>>>>
> >>>
> >>> I disagree.
> >>> In this code, I need to have the document related to the
descriptor.
It
> >>> depends on the current implementation, because we can imagine an
> >>> implementation where the descriptors are not stored in the wiki.
So I
> > won't
> > >>> add a getDocument() in the API, but I need it in my > > >>>
> > >>>
> > >>>>
> > >>>> 5) DefaultWikiManager.createDescritptor
> > >>>> Since you have a WikiDescriptorBuilder class, maybe that is
where
> the
> > >>>> logic
> > >>>> of creating/building the descriptor's details (objects,
document)
and
>>>> where
>>>> the logic of extracting the document name from wiki name and
viceversa
>>>> should be located.
>>>>
>>>>
> > >>>>
> > >>>
> > >>> I agree, I will move that code into WikiDescriptorBuilder.
> > >>>
> > >>>
> > >>>>
> > >>>> 6) DefaultWikiManager.getByWikiId
> > >>>> Again seeing the logic of wikiID-to-document. It should be
located
in
> a
> >>>> single place and not spread in multiple places. Use a method of
the
> >>>> WikiManager class or of the
DescriptorBuilder class.
> >>>>
> >>>
> >>> OK.
> >>>
> >>>
> >>>>
> >>>> 7) WikiManagerScriptService:
> >>>> - deleteWiki: Why do you need Admin right to delete a wiki when
you
> did
> >>>> not
> >>>> need it in order to create it? That`s bad. We should probably
have a
> > >>>> deleteWiki right as well.
> > >>>
> > >>>
> > >>> It is a temporary solution in my implementation.
> > >>> The problem is: who has the right to remove a wiki ?
> > >>> - his owner? But we don't have the notion of owner in this
API. >
belongs
> >>> to the wiki-users module to handle this concept.
> >>> - someone who has the CREATE_WIKI right? That means every person
who
> has
> >>> the CREATE_WIKI right can also delete any existing wiki?
> >>> - someone who as the DELETE_WIKI right? Why not, but we need to
make
> a
> > >>> vote for adding this new right.
> > >>>
> > >>> So, in my first implementation, I have used the admin right.
> > >>>
> > >>>
> > >>>> Also, consider the workspaces use case when user
> > >>>> create and delete wikis/workspaces when they want to and when
are
> >>>> done
> >>>> with them.
> >>>>
> >>>
> >>> To me, it belongs to the future wiki-user module.
> >>>
> >>>
> >>>> - context key for exceptions "lastexception2" is not the
best of
> choices.
> >>>> Try something like "wikiException" instead, or even just
> "lastexception"
> >>>> like it was before (if we consider this as a best practice).
What's
> > the
> > >>>> reason for "lastexception2"?
> > >>>>
> > >>>>
> > >>> It's a bad commit. I have setted this name for debugging
reason.
> > >>>
> > >>>
> > >>>>
> > >>>> As a general note, I fail to see the added value of this
module > > this
> > >>>> point. I mean, the whole point was to have both the
functionality
of
> > >>>> WikiManager and Workspaces. I get it that it's a work in
progress
and
> that
> >>>> it's at the first stages, but you need to touch those points
before
> it
> > >>>> becomes relevant. Not that it's bad, just that it's
not much > to
> > see
> > >>>> at this point.
> > >>>>
> > >>>
> > >>> The idea is to split in different simple modules, that enable us
to
>
easily
> >>> add a new feature or to depends on a module without depending on
the
> > whole
> > >>> core. I try to reduce the dependencies while I design the >
>>>
> >>>
> >>>>
> >>>> Hope this helps,
> >>>> Eduard
> >>>>
> >>>>
> >>> Thanks Eduard!
> >>>
> >>> Louis-Marie
> >>>
> >>>
> >>>>
> >>>> On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie"
Delhumeau <
> >>>> gdelhumeau(a)xwiki.com>
wrote:
> >>>>
> >>>> > Hi.
> >>>> >
> >>>> > In this thread, I want to propose you the tiniest API that we
need
to
>>>> > handle multiwiki. All other features (users, templates,
workspaces...)
>>>> will
>>>> > be on other modules, because I think it is better for the
extensibility.
>>>> >
>>>> > The new module will be based on the
xwiki-platform-wiki-descriptor-api
>>>> > module, that I will rename to xwiki-platform-wiki-api. The
>>>> > WikiDescriptorManager becomes WikiManager and handle both
descriptors
>>>> and
>>>> > databases.
>>>> >
>>>> > This API will permit:
>>>> > * to create a wiki
>>>> > * to remove a wiki
>>>> > * to list all wikis (returning a list of descriptors)
>>>> > * ...
>>>> >
>>>> > You can see the code of that proposal there:
>>>> >
>>>> >
>>>>
> > >>>> >
> > >>>> > The most important is to decide what the API must look
like.
The
>>>> > implementation can still be
modified afterwards.
>>>> >
>>>> > I hope you like it,
>>>> >
>>>> > Louis-Marie
>>>> > _______________________________________________
>>>> > 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
>>>>
>>>
>>>
>> _______________________________________________
>> 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
--
Thomas Mortagne
_______________________________________________
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
16 Oct
16 Oct
11:18 a.m.
Hi Edy
2013/10/11 Eduard Moraru <enygma2002(a)gmail.com>
About the ability to create a template that is automatically "adapted"
to
be a workspace template, I have the feeling that there are more drawbacks
than benefits:
- it's too complex
- it is useless for the majority of users
- the wiki creation does not work out of the box
- we have to write documentation about this...
- If a user wants to create his own customized XAR, he can start from the
default we provide
Yes, I like this one.
Didn`t you mention something earlier about separation of concerns? :)
I see the template feature as an helper for the creation of a wiki. We
don't need template for anything else than the creation of a wiki. So it
does not disturb me to have createWikiFromTemplate() (which internally call
createWiki).
I propose, with Caty:
* 1 UI which is the "Wiki Directory" that display only wikis that users can
use
* 1 UI, in the administration, to manage templates only.
No, just rename the database and the descriptor. Is there any limitation to
that?
There is nothing in the XWikiStoreInterface to rename a database.
- DB2 does not support the database renaming:
http://bytes.com/topic/db2/answers/185194-i-want-rename-table-schema
- Derby neither:
http://apache-database.10148.n7.nabble.com/Rename-Schema-td95708.html
- Neither oracle:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3002019…
But it's OK for PostGreSQL, MySQL and HSQLDB.
So, if we want to rename the database from A to B, we can:
- create the database B
- import all the data from A into B
- delete the database A.
Then we need an option to not copy history and recycle bin, because when
you create a wiki from a template, you don't care about deleted documents
and the history. Only the template creator needs them.
in
might
of
I am going to look at it!
Thanks,
Louis-Marie
Hi,
On Thu, Oct 10, 2013 at 11:46 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Side note: I`ve noticed that you have 2 branches where you work, both
feature-wiki-properties-group that you`ve linked to now and new-wiki-api
that you`ve linked to in the initial post. Please use only one since it`s
already quite confusing and hard to follow.
> > > > > I think my
mistakes until now was the fact that I didn't want to
> deviate
> > > too much from the wiki-descriptor module of Vincent. But now, I
> > understand
> > > it is better to make something new.
> > > > > Now, the API has
a complete javadoc.
> > > > > = Modularity =
> > > == Reduce responsibility ==
> > > > > The first
advantage of creating several modules is to reduce the
> > > responsibility of each module. I want one API to handle the wiki
> creation
> > > and basic management, one API for the template feature (which could
be
> > > optional as soon as we have flavors),
> > > > This transition will most certainly require some
considerable
refactoring
> > and possibly some method deprecating, for which we already have a
> strategy,
> > at least for the workspaces UI.
> > Currently, the workspaces UI is a kind of a hack.
WorkspaceManager.Install
Yes, and it is bad, IMO. Today, we have the Distribution Wizard which is
launched the first time we go to the wiki. There is no reason to force
having a template anymore.
Hi Eduard,
2013/10/9 Eduard Moraru <enygma2002(a)gmail.com>
https://github.com/gdelhumeau/xwiki-platform/tree/feature-wiki-properties-g…
Hi,
On Tue, Oct 8, 2013 at 4:41 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> Thanks for all your answers.
> I continue to iterate until we reach
something nice. You can see the
work
there:
create a new template where we install a standard
XAR UI + Workspace
Template Feature (that overwrites some standard pages) + delete some
pages
that we don't need, etc... It forces us to
ask the user to create
workspacetemplate first, it does not work out of the box.
Neither does wiki manager work out of the box. The current technical
limitations require that the user first creates a template wiki that is
used in the creation of new wikis/workspaces.
And we need to
have 2 distinct XARs to handle the 2 use-cases: farm and workspaces. It
is
definitively not clean.
When talking with Vincent about this, we decided that it would be better
to
create a unique XAR that handle the 2 use-cases.
But again, this does not fix the "out-of-the-box" issue.
It will just look at the
wiki configuration to know if we have local users or not, what is the
membership type of the wiki, etc...
The idea was that an admin could come with his own customized XAR that
would then be "adapted" to be used as a workspace template, if the admin
did not already do that. It was not desired that the user be limited to the
standard XE xar, since that would have been rather easy to implement and
automatically "install".
So, I apologize to not having talk here about
that. I think that we
should,
indeed, refactor a lot of things to have a very
clean multiwiki feature
in
5.3.
from
Basically, you`d right now be using a
$services.wiki.createWiki('newWiki')
> to create the wiki followed by a
> $services.wikiTemplate.apply('someWikiTemplateName', 'newWiki') to
> initialize the wiki with content.
> When we`d have flavours, you`d probably follow the creation step with a
> $services.extension.install('someFlavourExtensionID', 'newWiki')
to
> initialize the wiki with the content of a flavour extension.
> We`d probably also want to keep the option of importing the content a
Maybe setTemplate(String wikiID) as in,
$services.wikiTemplate.setTemplate('someWiki')
...or even setTemplate(String wikiID, boolean isTemplate) to avoid having a
second removeTemplate(String wikiID) method.
XAR, so that might be a option too.
So this wikiTemplate service would probably contain some methods like:
- create/convert (since the argument would probably be a wikiID to mark
as
template. The content of that wiki would have
previously be initialized
from an extension of from a XAR)
I have proposed setTemplate(boolean template);
- list/getAll (wikis marked as templates)
- delete/revert (remove the template mark, resulting in a regular wiki
once
again)
- isTemplate (wikiID)
- apply (as seen above, copy the content to an empty wiki)
I was thinking about createWikiFromTemplate() instead, but maybe it does
not provide enough flexibility.
>
> Side Note1: It could get a bit ugly fast when having to list wikis.
What
do
> you do with templates? What do users see, what do admins see if you
plan
to
> have a single view(UI) for everything? Probably 2 UIs would fit best
> (similar to what we have not with WikiManagerUI and WorkspacesUI). The
> WikiManager part would probably go in the main wiki's administration
(for
admins)
and the WorkspacesUI part would be in the main wiki's WikiIndex
(for users).
That is an interesting question. I did not think that much about the UI
until now. I wanted to have a clean API first.
>
> Side Note2: While thinking about templates, I thought that we might
need
some
"copy" and "rename" methods for the WikiManager API, since they
might
operations that the user might want to perform
without having to use
templates or some other weird operations.
- Rename would be hard to implement (copy the wiki and delete it?)
- What
"copy a wiki" means? Should we copy the history of every pages
too?
Should we copy the recycle bin? I did not want to
provide a copy feature
because of these questions. The template feature actually does a copy
operation but with its own opinion concerning this aspects : no history
copied, no recycle bin.
1-to-1 copy of the source wiki. This means everything.
Sure, there might be some applications that use custom mapping and add some
tables to the source database that might not be copied in the process. But,
if we have no way of detecting and copying this data, I think it's not a
bit problem. History and recycle bin are core notions of which we have full
control so they should not be an issue.
Anyway, since we`re reviewing these processes and thinking about them now,
maybe we should do it right. Copy and Rename are basic operations that
should not miss from any data model.
I agree.
We should *at least* include them in
the API and implement them when time allows (and expose them in the UI when
implemented). It would be a shame to have yet another half baked API.
Can we create an implementation with missing features?
and one API for the ability to
the
manager users (both the farm and the workspaces
use-cases).
Do you mean operations like:
- join
- leave
- invite
- acceptInvitation
- cancelInvitation
- getMembers
- isMember
- etc, all the stuff that it's now written as velocity code in the
workspaces-ui pages?
If so, than this could be indeed a useful script service to lighten up velocity pages that are full of duplicate code.
I think it's the only way to have a clean code, and will probably make it
easier to have only 1 XAR for the 2 use-cases.
> However, for the farm use case I don`t see any applications of this
> service, since the farm use case would be using the same tools that are
> currently available to the main wiki.
>
> I think it's a
> > good thing to avoid creating a new oldcore. I know this module is too
> > simple yet to be comparable with oldcore, but I try to design things > > this way.
>
>
> > == Reduce dependencies ==
> >
> > The second advantage, is that I try to reduce the dependencies for
each
> > module. That means, if a module only
needs the list of wikis (and a
lot
of
the
modules needs it), they won't have plenty of
dependencies.
For example, the extension manager needs the list of all wikis, but
doesn't
> care about theirs users, the templates, etc... So it does not need to
> depend on the users module, etc...
>
> == About WikiPropertiesGroup ==
>
> The idea behind this new class is to easily add custom properties in > descriptor for new modules. Each module
provides its own
> WikiPropertiesGroupProvider that load and save custom properties for
the
> > wiki. Then, it would be easy to get a property:
> > wikiDescriptor.get("template").get("isTemplate") or (in
velocity)
> > $wikiDescriptor.template.isTemplate. But we can also create typed
> wrappers
> > that access to theses properties.
> >
>
> Care to provide other (practical) examples of where such properties be
useful?
Imagine a new Activity Stream that needs to store information about each
wiki, like "the main AS should index the events of this wiki" or "users
that wiki can send a message to main users",
etc... Where AS should store
this information? WikiPropertyGroup is good for that.
The membership type and the "enable local users" could be stored there
too.
Ludo told me that clients would like to disable extension manager in
(sub)wiki, or to restrict it to main admins only. If we decide to
implement
this, we could store the EM configuration in the
property groups...
I think it is easy to implement and could be very useful for a lot of
use-cases that we don't even imagine yet. In my opinion, having this
flexibility can not be bad.
Technical note: Looking at the code, I can`t see these WikiPropertyGroups
being handled anywhere. I imagine that you would have to delegate the task
of creating WikiDescriptor instances to the WikiManager which will, in
turn, be in charge of querying all the WikiPropertyGroupProviders and
populating the new WikiDescriptor with these properties before returning it
to the caller.
You speak of WikiPropertyGroup as a storage location. However, in the code,
I see that each provider is supposed to save the properties itself, so it
is in charge of picking a physical location for these properties to be
stored. The WikiDescriptor would only be a logical location where
applications might store and read information/properties **about** the
wiki. When an application would store a new property for a wiki in a
certain property group, that group's provider will be in charge of
physically storing the value in the location where that group's properties
are physically stored.
It would be an interesting idea, but I find that it would be much more
productive as a generic service of its own and not just limited to wikis.
It is easy to imagine the need for such a service in the case of users.
Applications might want to store/query properties for the current user,
maybe for the current space and so on. For users, right now we`re storing
stuff in the user profile. For wikis, we`d probably store it in
XWikiPreferences, SpacePreferences for spaces and so on.
Maybe something a bit like what we do with ConfiguratinSource, but targeted
on certain entities (wikis, users, etc)
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
...however, what I don`t like about ConfigurationSource is that it is
ReadOnly.
Would be a shame to spend the effort and not to make it a generic solution.
WDYT?
17 Oct
17 Oct
2:03 p.m.
Hi,
On Wed, Oct 16, 2013 at 12:18 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> > > Basically,
you`d right now be using a
> $services.wiki.createWiki('newWiki')
> > to create the wiki followed by a
> > $services.wikiTemplate.apply('someWikiTemplateName', 'newWiki')
to
> > initialize the wiki with content.
> > When we`d have flavours, you`d probably follow the creation step with a
> > So this wikiTemplate service would
probably contain some methods like:
Maybe setTemplate(String wikiID) as in,
$services.wikiTemplate.setTemplate('someWiki')
...or even setTemplate(String wikiID, boolean isTemplate) to avoid having a
> > - list/getAll (wikis marked as templates)
> > - delete/revert (remove the template mark, resulting in a regular wiki
I see the template feature as an helper for the creation of a wiki. We
don't need template for anything else than the creation of a wiki. So it
does not disturb me to have createWikiFromTemplate() (which internally call
createWiki).
> Side Note1: It could get a bit ugly fast
when having to list wikis. What
The
WikiIndex
I propose, with Caty:
* 1 UI which is the "Wiki Directory" that display only wikis that users can
use
* 1 UI, in the administration, to manage templates only.
> >
> > > > > > >
Side Note2: While thinking about templates, I thought that we might
> > need
> > > > some "copy" and "rename" methods for the
WikiManager API, since they
> > > might
> > > > operations that the user might want to perform without having to use
> > > > templates or some other weird operations.
> > > > > > > > - Rename would be hard to
implement (copy the wiki and delete it?)
> > > > > No, just rename the database and the
descriptor. Is there any limitation
> to
> > that?
> >
> There is nothing in the XWikiStoreInterface to rename a database.
> - DB2 does not support the database
renaming:
> http://bytes.com/topic/db2/answers/185194-i-want-rename-table-schema
> - Derby neither:
> http://apache-database.10148.n7.nabble.com/Rename-Schema-td95708.html
> - Neither oracle:
>
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3002019…
> But it's OK for PostGreSQL, MySQL and
HSQLDB.
> So, if we want to rename the database from
A to B, we can:
> - create the database B
> - import all the data from A into B
> - delete the database A.
We had the same problem with renaming documents. We did not take it into
account in the initial API/model and then we had to fake it with a
delete+remove. If we have to do the same for wikis, fine, but IMO we have
to include these common sense operations or we will hit them in the future
and we will be forced to do even dirtier things, or worse, leave the user
to have to do them.
Also, implementation would not be hard (we already do wiki copy and
delete). We`d just need to be careful :)
> > > - What "copy a wiki"
means? Should we copy the history of every pages
> > too?
> > > Should we copy the recycle bin? I did not want to provide a copy
> feature
> > > because of these questions. The template feature actually does a copy
> > > operation but with its own opinion concerning this aspects : no history
> > > copied, no recycle bin.
> > > > > 1-to-1 copy of the source wiki. This
means everything.
> > > Sure, there might be some applications
that use custom mapping and add
> some
> > tables to the source database that might not be copied in the process.
> But,
> > if we have no way of detecting and copying this data, I think it's not a
> > bit problem. History and recycle bin are core notions of which we have
> full
> > control so they should not be an issue.
>
> Then we need an option to not copy history and recycle bin, because when
> you create a wiki from a template, you don't care about deleted documents
> and the history. Only the template creator needs them.
> > > Anyway,
since we`re reviewing these processes and thinking about them
> now,
> > maybe we should do it right. Copy and Rename are basic operations that
> > should not miss from any data model.
> I agree.
> > We should *at least* include them in
> > the API and implement them when time allows (and expose them in the UI
> when
> > implemented). It would be a shame to have yet another half baked API.
>
> Can we create an implementation with missing features?
We do things iteratively. I don`t see why we can`t apply that to
implementations of an API, as long as we don`t have any UI using it, thus
risking to crash.
Thanks,
Eduard
> > > > >
> > > > > > >
and one API for the ability to
> > > > > manager users (both the farm and the workspaces use-cases).
> > > > > > > > > > Do you mean operations
like:
> > > > - join
> > > > - leave
> > > > - invite
> > > > - acceptInvitation
> > > > - cancelInvitation
> > > > - getMembers
> > > > - isMember
> > > > - etc, all the stuff that it's now written as velocity code in
the
> > > > workspaces-ui pages?
> > > > > > >
If so, than this could be indeed a useful script service to lighten
> up
> > > the
> > > > velocity pages that are full of duplicate code.
> > > > > > > > > I think it's the only way to
have a clean code, and will probably make
> it
> > > easier to have only 1 XAR for the 2 use-cases.
> > > > > > > > However, for the farm use
case I don`t see any applications of this
> > > > service, since the farm use case would be using the same tools that
> are
> > > > currently available to the main wiki.
> > > > > > > I
think it's a
> > > > > good thing to avoid creating a new oldcore. I know this module
is
> too
> > > > > simple yet to be comparable with oldcore, but I try to design
> things
> > in
> > > > > this way.
> > > > > > > > > > > == Reduce dependencies
==
> > > > > > > >
> The second advantage, is that I try to reduce the dependencies for
> > each
> > > > > module. That means, if a module only needs the list of wikis (and
a
> > lot
> > > > of
> > > > > modules needs it), they won't have plenty of dependencies.
> > > > > > > >
> For example, the extension manager needs the list of all wikis, but
> > > > doesn't
> > > > > care about theirs users, the templates, etc... So it does not
need
> to
> > > > > depend on the users module, etc...
> > > > > > > >
> == About WikiPropertiesGroup ==
> > > > > > > >
> The idea behind this new class is to easily add custom properties
> in
> > > the
> > > > > descriptor for new modules. Each module provides its own
> > > > > WikiPropertiesGroupProvider that load and save custom properties
> for
> > > the
> > > > > wiki. Then, it would be easy to get a property:
> > > > >
wikiDescriptor.get("template").get("isTemplate") or (in velocity)
> > > > > $wikiDescriptor.template.isTemplate. But we can also create
typed
> > > > wrappers
> > > > > that access to theses properties.
> > > > > > > > > > > Care to provide other
(practical) examples of where such properties
> > might
> > > > be useful?
> > > > > > > > > Imagine a new Activity Stream
that needs to store information about
> each
> > > wiki, like "the main AS should index the events of this wiki" or
"users
> > of
> > > that wiki can send a message to main users", etc... Where AS should
> store
> > > this information? WikiPropertyGroup is good for that.
> > > > > The
membership type and the "enable local users" could be stored there
> > too.
> > > > > Ludo
told me that clients would like to disable extension manager in
> > > (sub)wiki, or to restrict it to main admins only. If we decide to
> > implement
> > > this, we could store the EM configuration in the property groups...
> > > > > I
think it is easy to implement and could be very useful for a lot of
> > > use-cases that we don't even imagine yet. In my opinion, having this
> > > flexibility can not be bad.
> > > > > Technical note: Looking at the code, I
can`t see these WikiPropertyGroups
> > being handled anywhere. I imagine that you would have to delegate the
> task
> > of creating WikiDescriptor instances to the WikiManager which will, in
> > turn, be in charge of querying all the WikiPropertyGroupProviders and
> > populating the new WikiDescriptor with these properties before returning
> it
> > to the caller.
> > > You speak of WikiPropertyGroup as a
storage location. However, in the
> code,
> > I see that each provider is supposed to save the properties itself, so it
> > is in charge of picking a physical location for these properties to be
> > stored. The WikiDescriptor would only be a logical location where
> > applications might store and read information/properties **about** the
> > wiki. When an application would store a new property for a wiki in a
> > certain property group, that group's provider will be in charge of
> > physically storing the value in the location where that group's
> properties
> > are physically stored.
> > > It would be an interesting idea, but I
find that it would be much more
> > productive as a generic service of its own and not just limited to wikis.
> > It is easy to imagine the need for such a service in the case of users.
> > Applications might want to store/query properties for the current user,
> > maybe for the current space and so on. For users, right now we`re storing
> > stuff in the user profile. For wikis, we`d probably store it in
> > XWikiPreferences, SpacePreferences for spaces and so on.
> > > Maybe something a bit like what we do
with ConfiguratinSource, but
> targeted
> > on certain entities (wikis, users, etc)
> >
>
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
> > ...however, what I don`t like about ConfigurationSource is that it is
> > ReadOnly.
> > > Would be a shame to spend the effort
and not to make it a generic
> solution.
> > > WDYT?
>
> I am going to look at it!
> Thanks,
> Louis-Marie
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
Hi Edy
2013/10/11 Eduard Moraru <enygma2002(a)gmail.com
Side note: I`ve noticed that you have 2 branches where you work, both
feature-wiki-properties-group that you`ve linked to now and new-wiki-api
that you`ve linked to in the initial post. Please use only one since it`s
already quite confusing and hard to follow.
> > > > > I think my
mistakes until now was the fact that I didn't want to
> deviate
> > > too much from the wiki-descriptor module of Vincent. But now, I
> > understand
> > > it is better to make something new.
> > > > > Now, the API has
a complete javadoc.
> > > > > = Modularity =
> > > == Reduce responsibility ==
> > > > > The first
advantage of creating several modules is to reduce the
> > > responsibility of each module. I want one API to handle the wiki
> creation
> > > and basic management, one API for the template feature (which could
be
> > > optional as soon as we have flavors),
> > > > This transition will most certainly require some
considerable
refactoring
> > and possibly some method deprecating, for which we already have a
> strategy,
> > at least for the workspaces UI.
> > Currently, the workspaces UI is a kind of a hack.
WorkspaceManager.Install
Yes, and it is bad, IMO. Today, we have the Distribution Wizard which is
launched the first time we go to the wiki. There is no reason to force
having a template anymore.
> When talking with Vincent about this, we
decided that it would be better
You also need to be aware that when this application (workspaces) was
developed, it was to be developed as an addon. Even the minor and almost
necessary "hacks" (read "IFs") that were added into platform for the
top
menus were frowned upon even to this date. Stating that the current
implementation is not optimal when viewing this no longer as an added
feature, but a basic and integrated feature is, basically, comparing apples
to oranges.
My only concern is that, whatever approach we chose, we preserve the
ability of an admin to provide his own, customized, workspace template,
either through a xar, a flavour or whatever, just as long as he still has
the means to build it and deploy it (without having to publish it to a
public extension repository, since it can be private stuff).
Hi,
On Thu, Oct 10, 2013 at 11:46 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> Hi Eduard,
> 2013/10/9 Eduard Moraru <enygma2002(a)gmail.com
> > Hi,
> > > On Tue, Oct 8, 2013 at 4:41 PM,
Guillaume "Louis-Marie" Delhumeau <
> > gdelhumeau(a)xwiki.com> wrote:
> > > > Thanks for all your answers.
> > > > > I
continue to iterate until we reach something nice. You can see
the
https://github.com/gdelhumeau/xwiki-platform/tree/feature-wiki-properties-g…
create a new template where we install a standard
XAR UI + Workspace
Template Feature (that overwrites some standard pages) + delete some
pages
that we don't need, etc... It forces us to
ask the user to create
workspacetemplate first, it does not work out of the box.
Neither does wiki manager work out of the box. The current technical
limitations require that the user first creates a template wiki that is
used in the creation of new wikis/workspaces.
And we need to
have 2 distinct XARs to handle the 2 use-cases: farm and workspaces. It
is
> definitively not clean.
to
the
create a unique XAR that handle the 2 use-cases.
But again, this does not fix the "out-of-the-box" issue.
It will just look at the
wiki configuration to know if we have local users or not, what is the
membership type of the wiki, etc...
The idea was that an admin could come with his own customized XAR that
would then be "adapted" to be used as a workspace template, if the admin
did not already do that. It was not desired that the user be limited to standard XE xar, since that would have been
rather easy to implement and
automatically "install".
About the ability to create a template that is automatically "adapted"
to
be a workspace template, I have the feeling that there are more drawbacks
than benefits:
- it's too complex
- it is useless for the majority of users
- the wiki creation does not work out of the box
- we have to write documentation about this...
- If a user wants to create his own customized XAR, he can start from the
default we provide
So, I apologize to not having talk here about
that. I think that we
should,
indeed, refactor a lot of things to have a very
clean multiwiki feature
in
> 5.3.
>
$services.extension.install('someFlavourExtensionID', 'newWiki') to
> initialize the wiki with the content of a flavour extension.
> We`d probably also want to keep the option of importing the content
from
> a
> > XAR, so that might be a option too.
> > > - create/convert (since the argument
would probably be a wikiID to
mark
> as
> > template. The content of that wiki would have previously be
initialized
from an extension of from a XAR)
I have proposed setTemplate(boolean template);
second removeTemplate(String wikiID) method.
Yes, I like this one.
> once
> > again)
> > - isTemplate (wikiID)
> > - apply (as seen above, copy the content to an empty wiki)
>
> I was thinking about createWikiFromTemplate() instead, but maybe it
does
not
provide enough flexibility.
Didn`t you mention something earlier about separation of concerns? :)
do
> you do with templates? What do users see, what do admins see if you
plan
> to
> > have a single view(UI) for everything? Probably 2 UIs would fit best
> > (similar to what we have not with WikiManagerUI and WorkspacesUI). >
WikiManager part would probably go in the main wiki's administration
(for
> > admins) and the WorkspacesUI part would be in the main wiki's (for users).
That is an interesting question. I did not think that much about the UI
until now. I wanted to have a clean API first.
21 Oct
21 Oct
11:18 a.m.
2013/10/11 Eduard Moraru <enygma2002(a)gmail.com>
Technical note: Looking at the code, I can`t see these WikiPropertyGroups
being handled anywhere. I imagine that you would have to delegate the task
of creating WikiDescriptor instances to the WikiManager which will, in
turn, be in charge of querying all the WikiPropertyGroupProviders and
populating the new WikiDescriptor with these properties before returning it
to the caller.
You speak of WikiPropertyGroup as a storage location. However, in the code,
I see that each provider is supposed to save the properties itself, so it
is in charge of picking a physical location for these properties to be
stored. The WikiDescriptor would only be a logical location where
applications might store and read information/properties **about** the
wiki. When an application would store a new property for a wiki in a
certain property group, that group's provider will be in charge of
physically storing the value in the location where that group's properties
are physically stored.
It would be an interesting idea, but I find that it would be much more
productive as a generic service of its own and not just limited to wikis.
It is easy to imagine the need for such a service in the case of users.
Applications might want to store/query properties for the current user,
maybe for the current space and so on. For users, right now we`re storing
stuff in the user profile. For wikis, we`d probably store it in
XWikiPreferences, SpacePreferences for spaces and so on.
Maybe something a bit like what we do with ConfiguratinSource, but targeted
on certain entities (wikis, users, etc)
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
...however, what I don`t like about ConfigurationSource is that it is
ReadOnly.
Would be a shame to spend the effort and not to make it a generic solution.
WDYT?
I think it is a good idea. But I won't have the time to do it for 5.3.
I want to continue on what I have already proposed, and we could still make
a generic solution after.
Thanks,
Louis-Marie
3:41 p.m.
FYI, I now use the new-wiki-api branch.
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
I will delete all the others.
2013/10/21 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
2013/10/11 Eduard Moraru <enygma2002(a)gmail.com>
Technical note: Looking at the code, I can`t see these WikiPropertyGroups
being handled anywhere. I imagine that you would have to delegate the task
of creating WikiDescriptor instances to the WikiManager which will, in
turn, be in charge of querying all the WikiPropertyGroupProviders and
populating the new WikiDescriptor with these properties before returning
it
to the caller.
You speak of WikiPropertyGroup as a storage location. However, in the
code,
I see that each provider is supposed to save the properties itself, so it
is in charge of picking a physical location for these properties to be
stored. The WikiDescriptor would only be a logical location where
applications might store and read information/properties **about** the
wiki. When an application would store a new property for a wiki in a
certain property group, that group's provider will be in charge of
physically storing the value in the location where that group's properties
are physically stored.
It would be an interesting idea, but I find that it would be much more
productive as a generic service of its own and not just limited to wikis.
It is easy to imagine the need for such a service in the case of users.
Applications might want to store/query properties for the current user,
maybe for the current space and so on. For users, right now we`re storing
stuff in the user profile. For wikis, we`d probably store it in
XWikiPreferences, SpacePreferences for spaces and so on.
Maybe something a bit like what we do with ConfiguratinSource, but
targeted
on certain entities (wikis, users, etc)
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
...however, what I don`t like about ConfigurationSource is that it is
ReadOnly.
Would be a shame to spend the effort and not to make it a generic
solution.
WDYT?
I think it is a good idea. But I won't have the time to do it for 5.3.
I want to continue on what I have already proposed, and we could still
make a generic solution after.
Thanks,
Louis-Marie
23 Oct
23 Oct
3:39 p.m.
FYI,
I managed to make the new API work on my local build. Before fixing all
style violations and writing a lot of tests, I want to modify the
workspaces & wiki manager pages in order to have a clean UI.
You can already see how the API looks like there:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
BTW, It currently breaks the workspaces application, because the new API
remove the WorspaceManager.WorkspaceClass object from the server pages.
Thanks,
Louis-Marie
2013/10/21 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
FYI, I now use the new-wiki-api branch.
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
I will delete all the others.
2013/10/21 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
2013/10/11 Eduard Moraru
<enygma2002(a)gmail.com>
Technical note: Looking at the code, I can`t see these WikiPropertyGroups
being handled anywhere. I imagine that you would have to delegate the
task
of creating WikiDescriptor instances to the WikiManager which will, in
turn, be in charge of querying all the WikiPropertyGroupProviders and
populating the new WikiDescriptor with these properties before returning
it
to the caller.
You speak of WikiPropertyGroup as a storage location. However, in the
code,
I see that each provider is supposed to save the properties itself, so it
is in charge of picking a physical location for these properties to be
stored. The WikiDescriptor would only be a logical location where
applications might store and read information/properties **about** the
wiki. When an application would store a new property for a wiki in a
certain property group, that group's provider will be in charge of
physically storing the value in the location where that group's
properties
are physically stored.
It would be an interesting idea, but I find that it would be much more
productive as a generic service of its own and not just limited to wikis.
It is easy to imagine the need for such a service in the case of users.
Applications might want to store/query properties for the current user,
maybe for the current space and so on. For users, right now we`re storing
stuff in the user profile. For wikis, we`d probably store it in
XWikiPreferences, SpacePreferences for spaces and so on.
Maybe something a bit like what we do with ConfiguratinSource, but
targeted
on certain entities (wikis, users, etc)
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
...however, what I don`t like about ConfigurationSource is that it is
ReadOnly.
Would be a shame to spend the effort and not to make it a generic
solution.
WDYT?
I think it is a good idea. But I won't have the time to do it for 5.3.
I want to continue on what I have already proposed, and we could still
make a generic solution after.
Thanks,
Louis-Marie
24 Oct
24 Oct
5:27 p.m.
Hi.
In the past, the UI was stored in the "WikiManager" and in the
"WorkspaceManager" spaces.
Since, I am creating a new UI containing the 2 use-cases, and since it will
be integrated by default, I am creating the new UI in the "XWiki" space.
Any objection?
Thanks,
Louis-Marie
2013/10/23 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
FYI,
I managed to make the new API work on my local build. Before fixing all
style violations and writing a lot of tests, I want to modify the
workspaces & wiki manager pages in order to have a clean UI.
You can already see how the API looks like there:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
BTW, It currently breaks the workspaces application, because the new API
remove the WorspaceManager.WorkspaceClass object from the server pages.
Thanks,
Louis-Marie
2013/10/21 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
FYI, I now use the new-wiki-api branch.
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
I will delete all the others.
2013/10/21 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
2013/10/11 Eduard Moraru
<enygma2002(a)gmail.com>
Technical note: Looking at the code, I can`t see these
WikiPropertyGroups
being handled anywhere. I imagine that you would have to delegate the
task
of creating WikiDescriptor instances to the WikiManager which will, in
turn, be in charge of querying all the WikiPropertyGroupProviders and
populating the new WikiDescriptor with these properties before
returning it
to the caller.
You speak of WikiPropertyGroup as a storage location. However, in the
code,
I see that each provider is supposed to save the properties itself, so
it
is in charge of picking a physical location for these properties to be
stored. The WikiDescriptor would only be a logical location where
applications might store and read information/properties **about** the
wiki. When an application would store a new property for a wiki in a
certain property group, that group's provider will be in charge of
physically storing the value in the location where that group's
properties
are physically stored.
It would be an interesting idea, but I find that it would be much more
productive as a generic service of its own and not just limited to
wikis.
It is easy to imagine the need for such a service in the case of users.
Applications might want to store/query properties for the current user,
maybe for the current space and so on. For users, right now we`re
storing
stuff in the user profile. For wikis, we`d probably store it in
XWikiPreferences, SpacePreferences for spaces and so on.
Maybe something a bit like what we do with ConfiguratinSource, but
targeted
on certain entities (wikis, users, etc)
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
...however, what I don`t like about ConfigurationSource is that it is
ReadOnly.
Would be a shame to spend the effort and not to make it a generic
solution.
WDYT?
I think it is a good idea. But I won't have the time to do it for 5.3.
I want to continue on what I have already proposed, and we could still
make a generic solution after.
Thanks,
Louis-Marie
6:20 p.m.
On Oct 24, 2013, at 5:27 PM, Guillaume Louis-Marie Delhumeau <gdelhumeau(a)xwiki.com>
wrote:
Hi.
In the past, the UI was stored in the "WikiManager" and in the
"WorkspaceManager" spaces.
Since, I am creating a new UI containing the 2 use-cases, and since it will
be integrated by default, I am creating the new UI in the "XWiki" space.
Any objection?
yes, the XWiki space should be avoided. Extensions should have their own spaces in
general.
Thanks
-Vincent
Thanks,
Louis-Marie
2013/10/23 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
FYI,
I managed to make the new API work on my local build. Before fixing all
style violations and writing a lot of tests, I want to modify the
workspaces & wiki manager pages in order to have a clean UI.
You can already see how the API looks like there:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
BTW, It currently breaks the workspaces application, because the new API
remove the WorspaceManager.WorkspaceClass object from the server pages.
Thanks,
Louis-Marie
2013/10/21 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs FYI, I now use the new-wiki-api branch.
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
I will delete all the others.
2013/10/21 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
2013/10/11 Eduard Moraru
<enygma2002(a)gmail.com>
>
> Technical note: Looking at the code, I can`t see these
> WikiPropertyGroups
> being handled anywhere. I imagine that you would have to delegate the
> task
> of creating WikiDescriptor instances to the WikiManager which will, in
> turn, be in charge of querying all the WikiPropertyGroupProviders and
> populating the new WikiDescriptor with these properties before
> returning it
> to the caller.
>
> You speak of WikiPropertyGroup as a storage location. However, in the
> code,
> I see that each provider is supposed to save the properties itself, so
> it
> is in charge of picking a physical location for these properties to be
> stored. The WikiDescriptor would only be a logical location where
> applications might store and read information/properties **about** the
> wiki. When an application would store a new property for a wiki in a
> certain property group, that group's provider will be in charge of
> physically storing the value in the location where that group's
> properties
> are physically stored.
>
> It would be an interesting idea, but I find that it would be much more
> productive as a generic service of its own and not just limited to
> wikis.
> It is easy to imagine the need for such a service in the case of users.
> Applications might want to store/query properties for the current user,
> maybe for the current space and so on. For users, right now we`re
> storing
> stuff in the user profile. For wikis, we`d probably store it in
> XWikiPreferences, SpacePreferences for spaces and so on.
>
> Maybe something a bit like what we do with ConfiguratinSource, but
> targeted
> on certain entities (wikis, users, etc)
>
>
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
> ...however, what I don`t like about ConfigurationSource is that it is
> ReadOnly.
>
> Would be a shame to spend the effort and not to make it a generic
> solution.
>
> WDYT?
>
I think it is a good idea. But I won't have the time to do it for 5.3.
I want to continue on what I have already proposed, and we could still
make a generic solution after.
Thanks,
Louis-Marie
25 Oct
25 Oct
9:01 a.m.
I would prefer a different space too.
On Thu, Oct 24, 2013 at 6:20 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Oct 24, 2013, at 5:27 PM, Guillaume Louis-Marie Delhumeau <gdelhumeau(a)xwiki.com>
wrote:
--
Thomas Mortagne
Hi.
In the past, the UI was stored in the "WikiManager" and in the
"WorkspaceManager" spaces.
Since, I am creating a new UI containing the 2 use-cases, and since it will
be integrated by default, I am creating the new UI in the "XWiki" space.
Any objection?
yes, the XWiki space should be avoided. Extensions should have their own spaces in
general.
Thanks
-Vincent
Thanks,
Louis-Marie
2013/10/23 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs FYI,
I managed to make the new API work on my local build. Before fixing all
style violations and writing a lot of tests, I want to modify the
workspaces & wiki manager pages in order to have a clean UI.
You can already see how the API looks like there:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
BTW, It currently breaks the workspaces application, because the new API
remove the WorspaceManager.WorkspaceClass object from the server pages.
Thanks,
Louis-Marie
2013/10/21 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs FYI, I now use the new-wiki-api branch.
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
I will delete all the others.
2013/10/21 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
> 2013/10/11 Eduard Moraru <enygma2002(a)gmail.com>
>
>>
>> Technical note: Looking at the code, I can`t see these
>> WikiPropertyGroups
>> being handled anywhere. I imagine that you would have to delegate the
>> task
>> of creating WikiDescriptor instances to the WikiManager which will, in
>> turn, be in charge of querying all the WikiPropertyGroupProviders and
>> populating the new WikiDescriptor with these properties before
>> returning it
>> to the caller.
>>
>> You speak of WikiPropertyGroup as a storage location. However, in the
>> code,
>> I see that each provider is supposed to save the properties itself, so
>> it
>> is in charge of picking a physical location for these properties to be
>> stored. The WikiDescriptor would only be a logical location where
>> applications might store and read information/properties **about** the
>> wiki. When an application would store a new property for a wiki in a
>> certain property group, that group's provider will be in charge of
>> physically storing the value in the location where that group's
>> properties
>> are physically stored.
>>
>> It would be an interesting idea, but I find that it would be much more
>> productive as a generic service of its own and not just limited to
>> wikis.
>> It is easy to imagine the need for such a service in the case of users.
>> Applications might want to store/query properties for the current user,
>> maybe for the current space and so on. For users, right now we`re
>> storing
>> stuff in the user profile. For wikis, we`d probably store it in
>> XWikiPreferences, SpacePreferences for spaces and so on.
>>
>> Maybe something a bit like what we do with ConfiguratinSource, but
>> targeted
>> on certain entities (wikis, users, etc)
>>
>>
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
>> ...however, what I don`t like about ConfigurationSource is that it is
>> ReadOnly.
>>
>> Would be a shame to spend the effort and not to make it a generic
>> solution.
>>
>> WDYT?
>>
>
> I think it is a good idea. But I won't have the time to do it for 5.3.
> I want to continue on what I have already proposed, and we could still
> make a generic solution after.
>
> Thanks,
> Louis-Marie
>
30 Oct
30 Oct
9:35 a.m.
OK.
I have chosen WikiManager for the UI and WikiManagerCode for resources used
by this UI.
--
I want to share you some news.
I manage to transform the original Workspace UI to this new WikiManager UI.
I think I will have something nice during this day.
The only thing that I don't have now is the template feature. My plan is to
do it as soon as I finish the UI aspect.
My plan is to make a pull request with the whole work by the beginning of
the next week, to have all the new stuff included in 5.3M2.
Then, I will write a lot of unit and functional tests until the final
release.
I had to take some decisions. I hope you will like my work but since it
will be marked as @Unstable, we could still change things in 5.4!
The only problem is that this pull request will be huge. 127 files are
modified. How should I send it? Several pull requests that each contains a
small part?
WDYT?
Louis-Marie
2013/10/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
I would prefer a different space too.
On Thu, Oct 24, 2013 at 6:20 PM, Vincent Massol <vincent(a)massol.net>
wrote:
spaces in
general.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Oct 24, 2013, at 5:27 PM, Guillaume Louis-Marie Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> Hi.
>
> In the past, the UI was stored in the "WikiManager" and in the
> "WorkspaceManager" spaces.
>
> Since, I am creating a new UI containing the 2 use-cases, and since it
will
be
integrated by default, I am creating the new UI in the "XWiki" space.
Any objection?
yes, the XWiki space should be avoided. Extensions should have their own
Thanks
-Vincent
> Thanks,
> Louis-Marie
>
>
> 2013/10/23 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
>
>> FYI,
>>
>> I managed to make the new API work on my local build. Before fixing all
>> style violations and writing a lot of tests, I want to modify the
>> workspaces & wiki manager pages in order to have a clean UI.
>>
>> You can already see how the API looks like there:
>>
>>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
>>
>> BTW, It currently breaks the workspaces application, because the new
API
>> remove the WorspaceManager.WorkspaceClass
object from the server pages.
>>
>> Thanks,
>> Louis-Marie
>>
>>
>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
>>
>>> FYI, I now use the new-wiki-api branch.
>>> https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
>>>
>>> I will delete all the others.
>>>
>>>
>>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
>>>
>>>> 2013/10/11 Eduard Moraru <enygma2002(a)gmail.com>
>>>>
>>>>>
>>>>> Technical note: Looking at the code, I can`t see these
>>>>> WikiPropertyGroups
>>>>> being handled anywhere. I imagine that you would have to delegate
the
>>>>> task
>>>>> of creating WikiDescriptor instances to the WikiManager which will,
in
>>>>> turn, be in charge of
querying all the WikiPropertyGroupProviders
and
>>>>> populating the new
WikiDescriptor with these properties before
>>>>> returning it
>>>>> to the caller.
>>>>>
>>>>> You speak of WikiPropertyGroup as a storage location. However, in
the
>>>>> code,
>>>>> I see that each provider is supposed to save the properties itself,
so
>>>>> it
>>>>> is in charge of picking a physical location for these properties to
be
>>>>> stored. The WikiDescriptor
would only be a logical location where
>>>>> applications might store and read information/properties **about**
the
>>>>> wiki. When an application
would store a new property for a wiki in a
>>>>> certain property group, that group's provider will be in charge
of
>>>>> physically storing the value in the location where that group's
>>>>> properties
>>>>> are physically stored.
>>>>>
>>>>> It would be an interesting idea, but I find that it would be much
more
>>>>> productive as a generic
service of its own and not just limited to
>>>>> wikis.
>>>>> It is easy to imagine the need for such a service in the case of
users.
>>>>> Applications might want to
store/query properties for the current
user,
>>>>> maybe for the current space
and so on. For users, right now we`re
>>>>> storing
>>>>> stuff in the user profile. For wikis, we`d probably store it in
>>>>> XWikiPreferences, SpacePreferences for spaces and so on.
>>>>>
>>>>> Maybe something a bit like what we do with ConfiguratinSource, but
>>>>> targeted
>>>>> on certain entities (wikis, users, etc)
>>>>>
>>>>>
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
>>>>> ...however, what I don`t like
about ConfigurationSource is that it
is
>>>>> ReadOnly.
>>>>>
>>>>> Would be a shame to spend the effort and not to make it a generic
>>>>> solution.
>>>>>
>>>>> WDYT?
>>>>>
>>>>
>>>> I think it is a good idea. But I won't have the time to do it for
5.3.
>>>> I want to continue on what I have
already proposed, and we could
still
>> make a generic solution after.
>>
>> Thanks,
>> Louis-Marie
>>
>
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:23 p.m.
On 30 Oct 2013, at 09:35, Guillaume Louis-Marie Delhumeau <gdelhumeau(a)xwiki.com>
wrote:
OK.
I have chosen WikiManager for the UI and WikiManagerCode for resources used
by this UI.
I don’t understand why you’re using 2 spaces. Now that we have hidden docs we usually use
only one space.
--
I want to share you some news.
I manage to transform the original Workspace UI to this new WikiManager UI.
I think I will have something nice during this day.
cool :)
The only thing that I don't have now is the
template feature. My plan is to
do it as soon as I finish the UI aspect.
My plan is to make a pull request with the whole work by the beginning of
the next week, to have all the new stuff included in 5.3M2.
Then, I will write a lot of unit and functional tests until the final
release.
I had to take some decisions. I hope you will like my work but since it
will be marked as @Unstable, we could still change things in 5.4!
The only problem is that this pull request will be huge. 127 files are
modified. How should I send it? Several pull requests that each contains a
small part?
WDYT?
Let’s start by seeing your changes first. You have a URL for that?
Thanks
-Vincent
Louis-Marie
2013/10/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
> I would prefer a different space too.
>
> On Thu, Oct 24, 2013 at 6:20 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
>>
>> On Oct 24, 2013, at 5:27 PM, Guillaume Louis-Marie Delhumeau <
> gdelhumeau(a)xwiki.com> wrote:
>>
>>> Hi.
>>>
>>> In the past, the UI was stored in the "WikiManager" and in the
>>> "WorkspaceManager" spaces.
>>>
>>> Since, I am creating a new UI containing the 2 use-cases, and since it
> will
>>> be integrated by default, I am creating the new UI in the "XWiki"
space.
>>>
>>> Any objection?
>>
>> yes, the XWiki space should be avoided. Extensions should have their own
> spaces in general.
>>
>> Thanks
>> -Vincent
>>
>>> Thanks,
>>> Louis-Marie
>>>
>>>
>>> 2013/10/23 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
>>>
>>>> FYI,
>>>>
>>>> I managed to make the new API work on my local build. Before fixing all
>>>> style violations and writing a lot of tests, I want to modify the
>>>> workspaces & wiki manager pages in order to have a clean UI.
>>>>
>>>> You can already see how the API looks like there:
>>>>
>>>>
>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
>>>>
>>>> BTW, It currently breaks the workspaces application, because the new
> API
>>>> remove the WorspaceManager.WorkspaceClass object from the server pages.
>>>>
>>>> Thanks,
>>>> Louis-Marie
>>>>
>>>>
>>>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
>>>>
>>>>> FYI, I now use the new-wiki-api branch.
>>>>> https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
>>>>>
>>>>> I will delete all the others.
>>>>>
>>>>>
>>>>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
>>>>>
>>>>>> 2013/10/11 Eduard Moraru <enygma2002(a)gmail.com>
>>>>>>
>>>>>>>
>>>>>>> Technical note: Looking at the code, I can`t see these
>>>>>>> WikiPropertyGroups
>>>>>>> being handled anywhere. I imagine that you would have to
delegate
> the
>>>>>>> task
>>>>>>> of creating WikiDescriptor instances to the WikiManager which
will,
> in
>>>>>>> turn, be in charge of querying all the
WikiPropertyGroupProviders
> and
>>>>>>> populating the new WikiDescriptor with these properties
before
>>>>>>> returning it
>>>>>>> to the caller.
>>>>>>>
>>>>>>> You speak of WikiPropertyGroup as a storage location.
However, in
> the
>>>>>>> code,
>>>>>>> I see that each provider is supposed to save the properties
itself,
> so
>>>>>>> it
>>>>>>> is in charge of picking a physical location for these
properties to
> be
>>>>>>> stored. The WikiDescriptor would only be a logical location
where
>>>>>>> applications might store and read information/properties
**about**
> the
>>>>>>> wiki. When an application would store a new property for a
wiki in a
>>>>>>> certain property group, that group's provider will be in
charge of
>>>>>>> physically storing the value in the location where that
group's
>>>>>>> properties
>>>>>>> are physically stored.
>>>>>>>
>>>>>>> It would be an interesting idea, but I find that it would be
much
> more
>>>>>>> productive as a generic service of its own and not just
limited to
>>>>>>> wikis.
>>>>>>> It is easy to imagine the need for such a service in the case
of
> users.
>>>>>>> Applications might want to store/query properties for the
current
> user,
>>>>>>> maybe for the current space and so on. For users, right now
we`re
>>>>>>> storing
>>>>>>> stuff in the user profile. For wikis, we`d probably store it
in
>>>>>>> XWikiPreferences, SpacePreferences for spaces and so on.
>>>>>>>
>>>>>>> Maybe something a bit like what we do with
ConfiguratinSource, but
>>>>>>> targeted
>>>>>>> on certain entities (wikis, users, etc)
>>>>>>>
>>>>>>>
>
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
>>>>>>> ...however, what I don`t like about ConfigurationSource is
that it
> is
>>>>>>> ReadOnly.
>>>>>>>
>>>>>>> Would be a shame to spend the effort and not to make it a
generic
>>>>>>> solution.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>
>>>>>> I think it is a good idea. But I won't have the time to do it
for
> 5.3.
>>>>>> I want to continue on what I have already proposed, and we could
> still
>>>>>> make a generic solution after.
>>>>>>
>>>>>> Thanks,
>>>>>> Louis-Marie
31 Oct
31 Oct
12:24 p.m.
Hi!
2013/10/30 Vincent Massol <vincent(a)massol.net>
Sure.
To see the API:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
To see all the changes:
https://github.com/gdelhumeau/xwiki-platform/compare/new-wiki-api
Thanks,
Louis-Marie
On 30 Oct 2013, at 09:35, Guillaume Louis-Marie Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
It's an arbitrary try to filter pages depending of their type. Moreover,
all the pages are hidden!
OK.
I have chosen WikiManager for the UI and WikiManagerCode for resources
used
by this UI.
I don’t understand why you’re using 2 spaces. Now that we have hidden docs
we usually use only one space.
--
I want to share you some news.
I manage to transform the original Workspace UI to this new WikiManager
UI.
I think I will have something nice during this
day.
cool :)
The only thing that I don't have now is the
template feature. My plan is
to
do it as soon as I finish the UI aspect.
My plan is to make a pull request with the whole work by the beginning of
the next week, to have all the new stuff included in 5.3M2.
Then, I will write a lot of unit and functional tests until the final
release.
I had to take some decisions. I hope you will like my work but since it
will be marked as @Unstable, we could still change things in 5.4!
The only problem is that this pull request will be huge. 127 files are
modified. How should I send it? Several pull requests that each contains
a
small part?
WDYT?
Let’s start by seeing your changes first. You have a URL for that?
1 Nov
1 Nov
10:12 a.m.
Hi,
On Wed, Oct 30, 2013 at 10:35 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
OK.
I have chosen WikiManager for the UI and WikiManagerCode for resources used
by this UI.
This only makes sense for an application that creates entities, like the
Blog application does. It has the Blog space where it stores its entry page
and where it puts its newly created entities (blog posts) and <should> also
<have> a BlogCode space where it puts code related pages so that we don`t
mix code with content too much.
However, an application like WikiManager that does not create entities
(well it does, but it adds them to the XWiki space so you don`t have to
worry about that; Also, I`m not sure if we should change that right now) so
you are good with just one space where you will store the application's
code + entry page.
Vincent mentioned hidden pages, but I guess the topic was more about mixing
code with content in the same space. We should document these 2 scenarios
(regarding application entity creation) in the application best practices
page.
Thanks,
Eduard
--
I want to share you some news.
I manage to transform the original Workspace UI to this new WikiManager UI.
I think I will have something nice during this day.
The only thing that I don't have now is the template feature. My plan is to
do it as soon as I finish the UI aspect.
My plan is to make a pull request with the whole work by the beginning of
the next week, to have all the new stuff included in 5.3M2.
Then, I will write a lot of unit and functional tests until the final
release.
I had to take some decisions. I hope you will like my work but since it
will be marked as @Unstable, we could still change things in 5.4!
The only problem is that this pull request will be huge. 127 files are
modified. How should I send it? Several pull requests that each contains a
small part?
WDYT?
Louis-Marie
2013/10/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
pages.
will,
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
--
Thomas Mortagne
_______________________________________________
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
I would prefer a different space too.
On Thu, Oct 24, 2013 at 6:20 PM, Vincent Massol <vincent(a)massol.net>
wrote:
space.
On Oct 24, 2013, at 5:27 PM, Guillaume Louis-Marie Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> Hi.
>
> In the past, the UI was stored in the "WikiManager" and in the
> "WorkspaceManager" spaces.
>
> Since, I am creating a new UI containing the 2 use-cases, and since it
will
>> be integrated by default, I am creating the new UI in the "XWiki"
>>
>> Any objection?
>
> yes, the XWiki space should be avoided. Extensions should have their
own
spaces in general.
>
> Thanks
> -Vincent
>
>> Thanks,
>> Louis-Marie
>>
>>
>> 2013/10/23 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
>>
>>> FYI,
>>>
>>> I managed to make the new API work on my local build. Before fixing
all
>>
style violations and writing a lot of tests, I want to modify the
>> workspaces & wiki manager pages in order to have a clean UI.
>>
>> You can already see how the API looks like there:
>>
>>
>>
>> BTW, It currently breaks the workspaces application, because the new
API
>>> remove the WorspaceManager.WorkspaceClass object from the server >>
>> Thanks,
>> Louis-Marie
>>
>>
>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
>>
>>> FYI, I now use the new-wiki-api branch.
>>> https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
>>>
>>> I will delete all the others.
>>>
>>>
>>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
>>>
>>>> 2013/10/11 Eduard Moraru <enygma2002(a)gmail.com>
>>>>
>>>>>
>>>>> Technical note: Looking at the code, I can`t see these
>>>>> WikiPropertyGroups
>>>>> being handled anywhere. I imagine that you would have to delegate
the
>>>>>> task
>>>>>> of creating WikiDescriptor instances to the WikiManager which
in
itself,
>>>>> turn, be in charge of
querying all the WikiPropertyGroupProviders
and
>>>>> populating the new
WikiDescriptor with these properties before
>>>>> returning it
>>>>> to the caller.
>>>>>
>>>>> You speak of WikiPropertyGroup as a storage location. However, in
the
>>>>>> code,
>>>>>> I see that each provider is supposed to save the properties
so
>>>>>> it
>>>>>> is in charge of picking a physical location for these properties
to
be
in a
>>>>> stored. The WikiDescriptor
would only be a logical location where
>>>>> applications might store and read information/properties **about**
the
>>>>>> wiki. When an application would store a new property for a wiki
>>>>> certain property group, that group's provider will be in charge
of
>>>>> physically storing the value in the location where that group's
>>>>> properties
>>>>> are physically stored.
>>>>>
>>>>> It would be an interesting idea, but I find that it would be much
more
>>>>> productive as a generic
service of its own and not just limited to
>>>>> wikis.
>>>>> It is easy to imagine the need for such a service in the case of
users.
>>>>> Applications might want to
store/query properties for the current
user,
>>>>> maybe for the current space
and so on. For users, right now we`re
>>>>> storing
>>>>> stuff in the user profile. For wikis, we`d probably store it in
>>>>> XWikiPreferences, SpacePreferences for spaces and so on.
>>>>>
>>>>> Maybe something a bit like what we do with ConfiguratinSource, but
>>>>> targeted
>>>>> on certain entities (wikis, users, etc)
>>>>>
>>>>>
>>>>> ...however, what I don`t like about ConfigurationSource is that it
is
>>>>> ReadOnly.
>>>>>
>>>>> Would be a shame to spend the effort and not to make it a generic
>>>>> solution.
>>>>>
>>>>> WDYT?
>>>>>
>>>>
>>>> I think it is a good idea. But I won't have the time to do it for
5.3.
>>>> I want to continue on what I have
already proposed, and we could
still
>>> make a generic solution after.
>>>
>>> Thanks,
>>> Louis-Marie
>>>
>>
>>
>
_______________________________________________
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
4 Nov
4 Nov
11:48 a.m.
Hi.
All the UI is now located in the WikiManager space now.
The pull request is here:
https://github.com/xwiki/xwiki-platform/pull/191
Thanks,
Louis-Marie
2013/11/1 Eduard Moraru <enygma2002(a)gmail.com>
Hi,
On Wed, Oct 30, 2013 at 10:35 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
gdelhumeau(a)xwiki.com>
WikiPropertyGroupProviders
where
of
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
_______________________________________________
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
OK.
I have chosen WikiManager for the UI and WikiManagerCode for resources
used
by this UI.
This only makes sense for an application that creates entities, like the
Blog application does. It has the Blog space where it stores its entry page
and where it puts its newly created entities (blog posts) and <should> also
<have> a BlogCode space where it puts code related pages so that we don`t
mix code with content too much.
However, an application like WikiManager that does not create entities
(well it does, but it adds them to the XWiki space so you don`t have to
worry about that; Also, I`m not sure if we should change that right now) so
you are good with just one space where you will store the application's
code + entry page.
Vincent mentioned hidden pages, but I guess the topic was more about mixing
code with content in the same space. We should document these 2 scenarios
(regarding application entity creation) in the application best practices
page.
Thanks,
Eduard
--
I want to share you some news.
I manage to transform the original Workspace UI to this new WikiManager
UI.
I think I will have something nice during this
day.
The only thing that I don't have now is the template feature. My plan is
to
do it as soon as I finish the UI aspect.
My plan is to make a pull request with the whole work by the beginning of
the next week, to have all the new stuff included in 5.3M2.
Then, I will write a lot of unit and functional tests until the final
release.
I had to take some decisions. I hope you will like my work but since it
will be marked as @Unstable, we could still change things in 5.4!
The only problem is that this pull request will be huge. 127 files are
modified. How should I send it? Several pull requests that each contains
a
small part?
WDYT?
Louis-Marie
2013/10/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
> I would prefer a different space too.
>
> On Thu, Oct 24, 2013 at 6:20 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
> >
> > On Oct 24, 2013, at 5:27 PM, Guillaume Louis-Marie Delhumeau <
> gdelhumeau(a)xwiki.com> wrote:
> >
> >> Hi.
> >>
> >> In the past, the UI was stored in the "WikiManager" and in the
> >> "WorkspaceManager" spaces.
> >>
> >> Since, I am creating a new UI containing the 2 use-cases, and since
it
will
>> be integrated by default, I am creating the new UI in the "XWiki"
space.
>>
>> Any objection?
>
> yes, the XWiki space should be avoided. Extensions should have their
own
spaces in general.
>
> Thanks
> -Vincent
>
>> Thanks,
>> Louis-Marie
>>
>>
>> 2013/10/23 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com>
>>
>>> FYI,
>>>
>>> I managed to make the new API work on my local build. Before fixing
all
>>
style violations and writing a lot of tests, I want to modify the
>> workspaces & wiki manager pages in order to have a clean UI.
>>
>> You can already see how the API looks like there:
>>
>>
> >>>
> >>> BTW, It currently breaks the workspaces application, because the
new
API
>>> remove the WorspaceManager.WorkspaceClass object from the server
pages.
>>>
>>> Thanks,
>>> Louis-Marie
>>>
>>>
>>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com
> >>>
> >>>> FYI, I now use the new-wiki-api branch.
> >>>> https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
> >>>>
> >>>> I will delete all the others.
> >>>>
> >>>>
> >>>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau < > >>>>
> >>>>> 2013/10/11 Eduard Moraru <enygma2002(a)gmail.com>
> >>>>>
> >>>>>>
> >>>>>> Technical note: Looking at the code, I can`t see these
> >>>>>> WikiPropertyGroups
> >>>>>> being handled anywhere. I imagine that you would have to
delegate
the
>>>>>> task
>>>>>> of creating WikiDescriptor instances to the WikiManager which
will,
> in
> >>>>>> turn, be in charge of querying all the > and
> >>>>>> populating the new WikiDescriptor with these properties
before
> >>>>>> returning it
> >>>>>> to the caller.
> >>>>>>
> >>>>>> You speak of WikiPropertyGroup as a storage location.
However,
in
the
>>>>>> code,
>>>>>> I see that each provider is supposed to save the properties
itself,
so
>>>>>> it
>>>>>> is in charge of picking a physical location for these properties
to
> be
> >>>>>> stored. The WikiDescriptor would only be a logical location
> >>>>>> applications might
store and read information/properties
**about**
the
>>>>>> wiki. When an application would store a new property for a wiki
in a
> >>>>>> certain property group, that group's provider will be
in charge > >>>>>> physically storing
the value in the location where that group's
> >>>>>> properties
> >>>>>> are physically stored.
> >>>>>>
> >>>>>> It would be an interesting idea, but I find that it would
be
much
> more
> >>>>>> productive as a generic service of its own and not just
limited
to
> >>>>>> wikis.
> >>>>>> It is easy to imagine the need for such a service in the
case of
> users.
> >>>>>> Applications might want to store/query properties for the
current
> user,
> >>>>>> maybe for the current space and so on. For users, right now
we`re
> >>>>>> storing
> >>>>>> stuff in the user profile. For wikis, we`d probably store
it in
> >>>>>> XWikiPreferences, SpacePreferences for spaces and so on.
> >>>>>>
> >>>>>> Maybe something a bit like what we do with
ConfiguratinSource,
but
>>>>> targeted
>>>>> on certain entities (wikis, users, etc)
>>>>>
>>>>>
> >>>>>> ...however, what I
don`t like about ConfigurationSource is that
it
> is
> >>>>>> ReadOnly.
> >>>>>>
> >>>>>> Would be a shame to spend the effort and not to make it a
generic
>>>>> solution.
>>>>>
>>>>> WDYT?
>>>>>
>>>>
>>>> I think it is a good idea. But I won't have the time to do it for
5.3.
>>>> I want to continue on what I have
already proposed, and we could
still
>>>> make a generic solution after.
>>>>
>>>> Thanks,
>>>> Louis-Marie
>>>>
>>>
>>>
>>
> _______________________________________________
> 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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6 Nov
6 Nov
7:16 p.m.
Here a build if you want to test:
http://xwiki.kephpage.net/wiki-api/xwiki-enterprise-jetty-hsqldb-5.3-SNAPSH…
I didn't have the time to test it a lot. If you like it, you can apply my
pull request. If not, I hope the deadline will be postponed in order to do
the final corrections or 5.3M2.
Thanks,
Louis-Marie
2013/11/4 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
Hi.
All the UI is now located in the WikiManager space now.
The pull request is here:
https://github.com/xwiki/xwiki-platform/pull/191
Thanks,
Louis-Marie
2013/11/1 Eduard Moraru <enygma2002(a)gmail.com>
Hi,
On Wed, Oct 30, 2013 at 10:35 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
fixing
gdelhumeau(a)xwiki.com>
WikiPropertyGroupProviders
properties
charge of
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
OK.
I have chosen WikiManager for the UI and WikiManagerCode for resources
used
by this UI.
This only makes sense for an application that creates entities, like the
Blog application does. It has the Blog space where it stores its entry
page
and where it puts its newly created entities (blog posts) and <should>
also
<have> a BlogCode space where it puts code related pages so that we don`t
mix code with content too much.
However, an application like WikiManager that does not create entities
(well it does, but it adds them to the XWiki space so you don`t have to
worry about that; Also, I`m not sure if we should change that right now)
so
you are good with just one space where you will store the application's
code + entry page.
Vincent mentioned hidden pages, but I guess the topic was more about
mixing
code with content in the same space. We should document these 2 scenarios
(regarding application entity creation) in the application best practices
page.
Thanks,
Eduard
--
I want to share you some news.
I manage to transform the original Workspace UI to this new WikiManager
UI.
I think I will have something nice during this
day.
The only thing that I don't have now is the template feature. My plan
is to
do it as soon as I finish the UI aspect.
My plan is to make a pull request with the whole work by the beginning
of
the next week, to have all the new stuff included
in 5.3M2.
Then, I will write a lot of unit and functional tests until the final
release.
I had to take some decisions. I hope you will like my work but since it
will be marked as @Unstable, we could still change things in 5.4!
The only problem is that this pull request will be huge. 127 files are
modified. How should I send it? Several pull requests that each
contains a
small part?
WDYT?
Louis-Marie
2013/10/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
> I would prefer a different space too.
>
> On Thu, Oct 24, 2013 at 6:20 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
> >
> > On Oct 24, 2013, at 5:27 PM, Guillaume Louis-Marie Delhumeau <
> gdelhumeau(a)xwiki.com> wrote:
> >
> >> Hi.
> >>
> >> In the past, the UI was stored in the "WikiManager" and in the
> >> "WorkspaceManager" spaces.
> >>
> >> Since, I am creating a new UI containing the 2 use-cases, and
since
it
will
>> be integrated by default, I am creating the new UI in the "XWiki"
space.
>>
>> Any objection?
>
> yes, the XWiki space should be avoided. Extensions should have their
own
spaces in general.
>
> Thanks
> -Vincent
>
>> Thanks,
>> Louis-Marie
>>
>>
>> 2013/10/23 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com
> >>
> >>> FYI,
> >>>
> >>> I managed to make the new API work on my local build. Before all
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
>>> style violations and writing a lot
of tests, I want to modify the
>>> workspaces & wiki manager pages in order to have a clean UI.
>>>
>>> You can already see how the API looks like there:
>>>
>>>
> >>>
> >>> BTW, It currently breaks the workspaces application, because the
new
API
>>> remove the WorspaceManager.WorkspaceClass object from the server
pages.
> >>>
> >>> Thanks,
> >>> Louis-Marie
> >>>
> >>>
> >>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau < > >>>
> >>>> FYI, I now use the new-wiki-api branch.
> >>>> https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
> >>>>
> >>>> I will delete all the others.
> >>>>
> >>>>
> >>>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com>
> >>>>
> >>>>> 2013/10/11 Eduard Moraru <enygma2002(a)gmail.com>
> >>>>>
> >>>>>>
> >>>>>> Technical note: Looking at the code, I can`t see these
> >>>>>> WikiPropertyGroups
> >>>>>> being handled anywhere. I imagine that you would have to
delegate
the
>>>>>> task
>>>>>> of creating WikiDescriptor instances to the WikiManager which
will,
> in
> >>>>>> turn, be in charge of querying all the > and
> >>>>>> populating the new WikiDescriptor with these properties
before
> >>>>>> returning it
> >>>>>> to the caller.
> >>>>>>
> >>>>>> You speak of WikiPropertyGroup as a storage location.
However,
in
the
>>>>>> code,
>>>>>> I see that each provider is supposed to save the properties
itself,
> so
> >>>>>> it
> >>>>>> is in charge of picking a physical location for these
to
> be
> >>>>>> stored. The WikiDescriptor would only be a logical location
where
> >>>>>> applications might
store and read information/properties
**about**
the
>>>>>> wiki. When an application would store a new property for a wiki
in a
> >>>>>> certain property group, that group's provider will be
in > >>>>>> physically storing
the value in the location where that group's
> >>>>>> properties
> >>>>>> are physically stored.
> >>>>>>
> >>>>>> It would be an interesting idea, but I find that it would
be
much
> more
> >>>>>> productive as a generic service of its own and not just
limited to
> >>>>>> wikis.
> >>>>>> It is easy to imagine the need for such a service in the
case
of
> users.
> >>>>>> Applications might want to store/query properties for the
current
> user,
> >>>>>> maybe for the current space and so on. For users, right now
we`re
> >>>>>> storing
> >>>>>> stuff in the user profile. For wikis, we`d probably store
it in
> >>>>>> XWikiPreferences, SpacePreferences for spaces and so on.
> >>>>>>
> >>>>>> Maybe something a bit like what we do with
ConfiguratinSource,
but
>>>>>> targeted
>>>>>> on certain entities (wikis, users, etc)
>>>>>>
>>>>>>
> >>>>>> ...however, what I
don`t like about ConfigurationSource is
that it
> is
> >>>>>> ReadOnly.
> >>>>>>
> >>>>>> Would be a shame to spend the effort and not to make it a
generic
> >>>>>> solution.
> >>>>>>
> >>>>>> WDYT?
> >>>>>>
> >>>>>
> >>>>> I think it is a good idea. But I won't have the time to do
it
for
5.3.
>>>>> I want to continue on what I have already proposed, and we could
still
>>>>> make a generic solution after.
>>>>>
>>>>> Thanks,
>>>>> Louis-Marie
>>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> 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
--
Thomas Mortagne
_______________________________________________
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
7:20 p.m.
NB: The UI is not fully complete, but there is nothing critical. I will
finish it for RC1.
2013/11/6 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
Here a build if you want to test:
http://xwiki.kephpage.net/wiki-api/xwiki-enterprise-jetty-hsqldb-5.3-SNAPSH…
I didn't have the time to test it a lot. If you like it, you can apply my
pull request. If not, I hope the deadline will be postponed in order to do
the final corrections or 5.3M2.
Thanks,
Louis-Marie
2013/11/4 Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com>
Hi.
All the UI is now located in the WikiManager space now.
The pull request is here:
https://github.com/xwiki/xwiki-platform/pull/191
Thanks,
Louis-Marie
2013/11/1 Eduard Moraru <enygma2002(a)gmail.com>
Hi,
On Wed, Oct 30, 2013 at 10:35 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
OK.
I have chosen WikiManager for the UI and WikiManagerCode for resources
used
by this UI.
This only makes sense for an application that creates entities, like the
Blog application does. It has the Blog space where it stores its entry
page
and where it puts its newly created entities (blog posts) and <should>
also
<have> a BlogCode space where it puts code related pages so that we don`t
mix code with content too much.
However, an application like WikiManager that does not create entities
(well it does, but it adds them to the XWiki space so you don`t have to
worry about that; Also, I`m not sure if we should change that right now)
so
you are good with just one space where you will store the application's
code + entry page.
Vincent mentioned hidden pages, but I guess the topic was more about
mixing
code with content in the same space. We should document these 2 scenarios
(regarding application entity creation) in the application best practices
page.
Thanks,
Eduard
--
I want to share you some news.
I manage to transform the original Workspace UI to this new
WikiManager UI.
I think I will have something nice during this
day.
The only thing that I don't have now is the template feature. My plan
is to
do it as soon as I finish the UI aspect.
My plan is to make a pull request with the whole work by the beginning
of
the next week, to have all the new stuff included
in 5.3M2.
Then, I will write a lot of unit and functional tests until the final
release.
I had to take some decisions. I hope you will like my work but since it
will be marked as @Unstable, we could still change things in 5.4!
The only problem is that this pull request will be huge. 127 files are
modified. How should I send it? Several pull requests that each
contains a
small part?
WDYT?
Louis-Marie
2013/10/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>
> I would prefer a different space too.
>
> On Thu, Oct 24, 2013 at 6:20 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
> >
> > On Oct 24, 2013, at 5:27 PM, Guillaume Louis-Marie Delhumeau <
> gdelhumeau(a)xwiki.com> wrote:
> >
> >> Hi.
> >>
> >> In the past, the UI was stored in the "WikiManager" and in the
> >> "WorkspaceManager" spaces.
> >>
> >> Since, I am creating a new UI containing the 2 use-cases, and
since
it
> will
> >> be integrated by default, I am creating the new UI in the
"XWiki"
space.
> >>
> >> Any objection?
> >
> > yes, the XWiki space should be avoided. Extensions should have
their
own
> spaces in general.
> >
> > Thanks
> > -Vincent
> >
> >> Thanks,
> >> Louis-Marie
> >>
> >>
> >> 2013/10/23 Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com>
> >>
> >>> FYI,
> >>>
> >>> I managed to make the new API work on my local build. Before
fixing
all
> >>> style violations and writing a lot of tests, I want to modify the
> >>> workspaces & wiki manager pages in order to have a clean UI.
> >>>
> >>> You can already see how the API looks like there:
> >>>
> >>>
>
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
> >>>
> >>> BTW, It currently breaks the workspaces application, because the
new
> API
> >>> remove the WorspaceManager.WorkspaceClass object from the server
pages.
> >>>
> >>> Thanks,
> >>> Louis-Marie
> >>>
> >>>
> >>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com>
> >>>
> >>>> FYI, I now use the new-wiki-api branch.
> >>>> https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api
> >>>>
> >>>> I will delete all the others.
> >>>>
> >>>>
> >>>> 2013/10/21 Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com>
> >>>>
> >>>>> 2013/10/11 Eduard Moraru <enygma2002(a)gmail.com>
> >>>>>
> >>>>>>
> >>>>>> Technical note: Looking at the code, I can`t see these
> >>>>>> WikiPropertyGroups
> >>>>>> being handled anywhere. I imagine that you would have to
delegate
> the
> >>>>>> task
> >>>>>> of creating WikiDescriptor instances to the WikiManager
which
will,
> in
> >>>>>> turn, be in charge of querying all the
WikiPropertyGroupProviders
> and
> >>>>>> populating the new WikiDescriptor with these properties
before
> >>>>>> returning it
> >>>>>> to the caller.
> >>>>>>
> >>>>>> You speak of WikiPropertyGroup as a storage location.
However, in
> the
> >>>>>> code,
> >>>>>> I see that each provider is supposed to save the
properties
itself,
> so
> >>>>>> it
> >>>>>> is in charge of picking a physical location for these
properties
to
> be
> >>>>>> stored. The WikiDescriptor would only be a logical location
where
> >>>>>> applications might
store and read information/properties
**about**
> the
> >>>>>> wiki. When an application would store a new property for a
wiki
in a
> >>>>>> certain property group, that group's provider will be
in
charge of
> >>>>>> physically storing
the value in the location where that
group's
> >>>>>> properties
> >>>>>> are physically stored.
> >>>>>>
> >>>>>> It would be an interesting idea, but I find that it would
be
much
> more
> >>>>>> productive as a generic service of its own and not just
limited to
> >>>>>> wikis.
> >>>>>> It is easy to imagine the need for such a service in the
case
of
> users.
> >>>>>> Applications might want to store/query properties for the
current
> user,
> >>>>>> maybe for the current space and so on. For users, right now
we`re
> >>>>>> storing
> >>>>>> stuff in the user profile. For wikis, we`d probably store
it
in
> >>>>>> XWikiPreferences,
SpacePreferences for spaces and so on.
> >>>>>>
> >>>>>> Maybe something a bit like what we do with
ConfiguratinSource, but
> >>>>>> targeted
> >>>>>> on certain entities (wikis, users, etc)
> >>>>>>
> >>>>>>
>
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
> >>>>>> ...however, what I
don`t like about ConfigurationSource is
that it
> is
> >>>>>> ReadOnly.
> >>>>>>
> >>>>>> Would be a shame to spend the effort and not to make it a
generic
> >>>>>> solution.
> >>>>>>
> >>>>>> WDYT?
> >>>>>>
> >>>>>
> >>>>> I think it is a good idea. But I won't have the time to do
it
for
> 5.3.
> >>>>> I want to continue on what I have already proposed, and we
could
> still
> >>>>> make a generic solution after.
> >>>>>
> >>>>> Thanks,
> >>>>> Louis-Marie
> >>>>>
> >>>>
> >>>>
> >>>
> >> _______________________________________________
> >> 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
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7 Oct
7 Oct
9:09 p.m.
Hi,
On Mon, Oct 7, 2013 at 5:33 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
I disagree.
In this code, I need to have the document related to the descriptor. It
depends on the current implementation, because we can imagine an
implementation where the descriptors are not stored in the wiki. So I won't
add a getDocument() in the API, but I need it in my implementation.
> 5)
DefaultWikiManager.createDescritptor
> Since you have a WikiDescriptorBuilder class, maybe that is where the
logic
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
I agree, I will move that code into WikiDescriptorBuilder.
> 6) DefaultWikiManager.getByWikiId
> Again seeing the logic of wikiID-to-document. It should be located in a
> single place and not spread in multiple places. Use a method of the
> WikiManager class or of the DescriptorBuilder class.
OK.
> 7) WikiManagerScriptService:
> - deleteWiki: Why do you need Admin right to delete a wiki when you did
not
Try not to shoot yourself in the leg with this over-zelous separation of
concerns :). In our previous implementation, owners can delete their own
wikis or top level admins (admins on the main wiki). To this, we could add
the deleteWiki right that you`ve mentioned, but, at first, we should stick
to what we had (owners + top admins).
All this information (owner, homepage, etc) should be reflected by the
descriptor.
Why? What exactly do you plan to include in such a module?
As Vincent mentioned, in order for these modules to make sense, they would
have to be optional. However, the distribution will come with all of them
bundled and they will still be loaded and present.
As mentioned above, care to elaborate more on this plan that you have?
Thanks,
Eduard
https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi Eddy.
First, thanks for your answer.
2013/10/7 Eduard Moraru <enygma2002(a)gmail.com>
Scratch this note. I did some rephrasing and forgot to remove it. I noticed
you`ve already made the change (as you`ve understood it), but I`m not sure
it's the best thing to do.
Hi Guilllaume,
1) What is the point of the WikiDescriptorAlias class if it just holds
and
returns a string?
Also, the only method in the
WikiDescriptorManager that works with
aliases
accepts a String instead of the
WikiDescriptorAlias class, so this means
that the class is useless:
WikiDescriptor getByWikiAlias(String wikiAlias) throws
WikiManagerException;
I did not really think about it, I just take the work done by Vincent on
wiki descriptors.
2) WikiManager:
The methods wikiIdExists and and isWikiIdAvailable do the same thing,
they
just call it differently. Use only one, like
wikiExists().
I should have added the javadoc about that. This is what I have in mind :
- wikiExists(String wikiOd) as you said
- wikiAvailable(String wikiId) that checks if the wiki id is valid and free
(that means that there is no existing database with that name -- not
necessary related to XWiki).
It is not implemented yet.
Also, since it's a WikiManager, so the "wiki" part is in the name of the
class, we get it that it deals with wikis. You could remove the "wiki"
part
from method names, like:
- create instead of createWiki
- delete instead of deleteWiki
- exists instead of existsWiki
- so on...
I agree. I'll change it ;)
Note on the naming of methods:
I`ve noticed a rather annoying thing in the way the methods are named. So
you have a class that is say... WikiDescriptor.
Indeed, but a Wiki class would not contain something else than a
descriptor. I don't know what to do. Renaming WikiDescriptor to Wiki?
3) WikiManager:
What is the point of these 2 methods?
void setDescriptor(WikiDescriptor descriptor);
void removeDescriptor(WikiDescriptor descriptor);
Looking at the implementation, I see that you`re handling descriptors
(setting/deleting) whithout corelating it to the wikis. I mean, if you
remove a descriptor, then you must remove the wiki too, and that is the
task of the WikiManager.delete() method.
I have keeped them because it is used in the descriptors implementation of
Vincent. But I agree that it is weird to have it in the API.
4) Don`t use implementation details. Improve the interface (API) if there
is information you`re missing:
https://github.com/gdelhumeau/xwiki-platform/blob/new-wiki-api/xwiki-platfo…
of creating/building the descriptor's details
(objects, document) and
where
> the logic of extracting the document name from wiki name and viceversa
> should be located.
need it in order to create it? That`s bad. We
should probably have a
deleteWiki right as well.
It is a temporary solution in my implementation.
The problem is: who has the right to remove a wiki ?
- his owner? But we don't have the notion of owner in this API. It belongs
to the wiki-users module to handle this concept.
- someone who has the CREATE_WIKI right? That means every person who has
the CREATE_WIKI right can also delete any existing wiki?
- someone who as the DELETE_WIKI right? Why not, but we need to make a vote
for adding this new right.
So, in my first implementation, I have used the admin right.
Also, consider the workspaces use case when user
create and delete wikis/workspaces when they want to and when they are
done
with them.
To me, it belongs to the future wiki-user module.
- context key for exceptions
"lastexception2" is not the best of choices.
Try something like "wikiException" instead, or even just
"lastexception"
like it was before (if we consider this as a best practice). What's the
reason for "lastexception2"?
It's a bad commit. I have setted this name for debugging reason.
As a general note, I fail to see the added value of this module at this
point. I mean, the whole point was to have both the functionality of
WikiManager and Workspaces. I get it that it's a work in progress and
that
it's at the first stages, but you need to
touch those points before it
becomes relevant. Not that it's bad, just that it's not much there to see
at this point.
The idea is to split in different simple modules, that enable us to easily
add a new feature or to depends on a module without depending on the whole
core. I try to reduce the dependencies while I design the modules.
Hope this helps,
Eduard
Thanks Eduard!
Louis-Marie
On Mon, Oct 7, 2013 at 11:49 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
extensibility.
Hi.
In this thread, I want to propose you the tiniest API that we need to
handle multiwiki. All other features (users, templates, workspaces...)
will
> be on other modules, because I think it is better for the >
> The new module will be based on the xwiki-platform-wiki-descriptor-api
> module, that I will rename to xwiki-platform-wiki-api. The
> WikiDescriptorManager becomes WikiManager and handle both descriptors
and
databases.
This API will permit:
* to create a wiki
* to remove a wiki
* to list all wikis (returning a list of descriptors)
* ...
You can see the code of that proposal there:
The most important is to decide what the API must look like. The
implementation can still be modified afterwards.
I hope you like it,
Louis-Marie
_______________________________________________
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
4073
days inactive
4103
days old
30 comments
5 participants
participants (5)
-
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol