23 Oct
2012
23 Oct
'12
8:29 a.m.
Hi Edy,
On Oct 23, 2012, at 12:46 AM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
Hi devs,
Since the current policy is to ask before adding a CLIRR exclude and since
I did not ask when I applied GuillaumeD's pull request [1], I hereby ask
for your vote whether it is ok to exclude the 2 new methods:
- that allows the creation of workspaces using a different template than
the default one
- that lists workspace templates
Since we are tight with time (Fabio needs to finish the 4.3M1 release),
this issue should be settled ASAP.
Also, please note that the Workspace API is still young (and pretty basic),
as far as I am concerned, and it is bound to get updated in the future.
Here's my +1
The workspace API was introduced in 3.2
(http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…) when it
was included in XEM (it was there even before in platform I think). 3.2 was released 11th
of October 2011. So that means the API has been there for more than 1 year. It's
starting to be long to consider it a "young api"… ;)
We really need to finish the discussion thread about "young apis" to clearly
define it as otherwise all devs are going to say that their code is young apis forever…
:)
Also note that your code is missing @since tags (for ex WorkspaceManager, Workspace, etc).
Could you please add them?
What are your alternatives here? I can think of at least 2 that wouldn't break
backward compat:
* Extend XWikiServer (for ex: WorkspaceXWikiServer) to add a new class field holding the
name of the template to use. It could be interesting information to keep the fact that a
given workspace was created with a given template so it could make sense to store it in
the XWikiServer class. Then of course you'll need to do an instanceof in your code to
see whether the passed XWikiServer instance is of type XWikiServer or
WorkspaceXWikiServer)
* Deprecate WorkspaceManager and introduce a new interface: WorkspaceManager2 (of course a
better name should be found, that's the hard part but it can be found, like
WorkspaceHandler, WorkspaceService, etc). Then move WorkspaceManager to legacy. Note that
WorkspaceManagerScriptService can be modified without breaking backward compat ;)
Before deciding on breaking backward compat, we should always discuss the alternatives IMO
and then, based on that, decide if we break it or not. From your email we can't really
see if you've thought about not breaking the compatibility ;)
I'm +1, not because it's a young api (1 year is pretty long for me) but because
it's not a major and widely implemented API IMO so we probably won't break a lot
developers and I can't recall any extension on extensions.xwiki.org that would be
broken.
Thanks
-Vincent
Thanks,
Eduard
--------
[1] https://github.com/xwiki/xwiki-platform/pull/70