Hi, On Wed, Oct 16, 2013 at 12:18 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Hi Edy
2013/10/11 Eduard Moraru <[email protected]>
Hi,
On Thu, Oct 10, 2013 at 11:46 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Hi Eduard,
2013/10/9 Eduard Moraru <[email protected]>
Hi,
On Tue, Oct 8, 2013 at 4:41 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> 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-gr...
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 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.
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.
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".
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
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).
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.
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);
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.
Yes, I like this one.
- 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.
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).
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.
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:30020192...
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs