23 Oct
2012
23 Oct
'12
12:06 p.m.
Hi,
On Tue, Oct 23, 2012 at 9:29 AM, Vincent Massol <vincent(a)massol.net> wrote:
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… :)
It`s not so much a matter of time, as it is a matter of features. Since a
big segment of our users wait for stable versions, it has not yet benefited
from user attention and testing, but lately it is getting some more
attention and more and more features are being asked. I know we have the
other thread for "young api", but this is what I mean in my previous mail.
It was developed one year ago but it is far from being complete and, since
it did not make it into the Roadmap, it did not get the chance to mature,
so again, I see it as being young and subject to change.
Also note that your code is missing @since tags (for ex WorkspaceManager,
Workspace, etc). Could you please add them?
Sure.
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)
Not really an alternative here. We already have a Workspace interface and,
most important, even if we do something like what you suggest, we will
still need a method to create these instances, method which will be exposed
in the API, thus breaking CLIRR.
* 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 ;)
Something like this could be done at some point, but, as I`ve already
mentioned, this API is bound to get more changes. Most likely it should get
a bigger refactoring the first time it makes it into the Roadmap. However,
for the moment, for the additional 2 methods, I consider this overkill.
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 ;)
From the feature's point of view, I have considered
and tried to handle
backwards compatibility, at least regarding upgrades [1]. The
API change
part of the backwards compatibility issue is only addressed with a CLIRR
exclude.
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,
Eduard
----------
[1]
https://github.com/xwiki/xwiki-platform/commit/b8c00d91928718fd7e54ebb6bed4…
Thanks
-Vincent
Thanks,
Eduard
--------
[1] https://github.com/xwiki/xwiki-platform/pull/70
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs