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-group/xwiki-platform-core/xwiki-platform-wiki/xwiki-platform-wiki-api/src/main/java/org/xwiki/wiki > > > > 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 > > > 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:30020192108317 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. > > - 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? > > > > > > > > > > > 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-commons-configuration/xwiki-commons-configuration-api/src/main/java/org/xwiki/configuration/ConfigurationSource.java > ...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
