Hi Edy, On Oct 23, 2012, at 12:46 AM, Eduard Moraru <[email protected]> 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/ReleaseNotesXWikiEnterprise32) 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
