16 Oct
2013
16 Oct
'13
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?