[xwiki-devs] [Brainstorming] Is the Refactoring module a core module?

List overview All Threads
Download

newer

older

[xwiki-devs] [Iteration][UX]...

[xwiki-devs] [ANN] XWiki 6.4.5...

vincent＠massol.net

31 Aug 2015 31 Aug '15

5:54 p.m.

Hi, Right now almost all func tests fail to delete pages when they do getUtil().deletePage(…). They fail with: Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component [role = [interface org.xwiki.job.Job] hint = [delete]] The reason is that since XWIKI-12268 the Delete action cannot work if the Refactoring module isn't bundled, which makes the Refactoring module a core module. And this module is not part of the core modules ATM. I’ve added it to the PackageMojo for now but we need to decide what to do. Personally I’ve always viewed Refactoring as optional and advanced features. I don’t consider basic delete, basic copy and basic rename/move as refactoring options. However there are some parts of them that are refactorings. For example when Renaming, also check for wiki pages having the renamed page as parent and updating them or updating wiki links in pages. So we need to decide if: * We consider the Refactoring module as core. * Introduce a new module and move some of the core actions such as delete, move, etc to it and keep the refactoring module for non-core refactoring * Split the refactoring into basic refactorings and advanced ones. Have basic delete, copy, rename + advanced options for them separately * Others? WDYT? Still hesitating on my side. Thanks -Vincent

Show replies by date

Eduard Moraru

31 Aug 31 Aug

6:26 p.m.

I`m not very familiar with the refactoring module and its contents, but it feels wrong to have extensions have to depend on it and use it in order to achieve basic model (CRUD) operations. Thanks, Eduard On Mon, Aug 31, 2015 at 6:54 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:

...

Guillaume "Louis-Marie" Delhumeau

7:40 p.m.

If it's part of the core modules, there would be no need to declare the dependency on the extension. I am hesitating between declaring it as a core extension and splitting it in 2 modules: one for basic CRUD operations, and one for the complex ones (rename backlinks, etc...). But this second solution would need more work and may not be pertinent. Thanks, Guillaume 2015-08-31 18:26 GMT+02:00 Eduard Moraru <enygma2002(a)gmail.com>om>:

...

core

module. And this module is not part of the core modules ATM. I’ve added

to the PackageMojo for now but we need to decide what to do. Personally I’ve always viewed Refactoring as optional and advanced features. I don’t consider basic delete, basic copy and basic rename/move as refactoring options. However there are some parts of them that are refactorings. For example when Renaming, also check for wiki pages having the renamed page as parent and updating them or updating wiki links in pages. So we need to decide if: * We consider the Refactoring module as core. * Introduce a new module and move some of the core actions such as

delete,

move, etc to it and keep the refactoring module for non-core refactoring * Split the refactoring into basic refactorings and advanced ones. Have basic delete, copy, rename + advanced options for them separately * Others? WDYT? Still hesitating on my side. Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

Marius Dumitru Florea

2 Sep 2 Sep

2:49 p.m.

On Mon, Aug 31, 2015 at 7:26 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:

...

I`m not very familiar with the refactoring module and its contents, but it feels wrong to have extensions have to depend on it and use it in order to achieve basic model (CRUD) operations.

The low level / basic CRUD operations are in oldcore. The refactoring module doesn't modify the database directly, it uses XWiki#deleteDocument and XWiki#copyDocument from oldcore to implement the refactorings. If you only need to delete a single document from the database without any side effects then you can use the oldcore API. If you want to delete an entire hierarchy or update the backlinks on rename then you should use the refactoring API. The "issue" here is that the DeleteAction (located currently in oldcore) uses the refactoring API in order to support deleting an entire hierarchy. If the DeleteAction were a component outside of oldcore then it could depend on the refactoring-default but currently it can only depend on refactoring-api (to avoid circular dependency on oldcore). The default refactoring implementation is brought in by XE, but functional tests in platform don't have it unless they add a dependency, or we add it to the packager plugin as Vincent did. Thanks, Marius

...

Thanks, Eduard On Mon, Aug 31, 2015 at 6:54 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

vincent＠massol.net

5:42 p.m.

New subject: [xwiki-devs] [Brainstorming] Is the Refactoring module a core module?

On 2 Sep 2015 at 14:49:26, Marius Dumitru Florea (mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

...

On Mon, Aug 31, 2015 at 7:26 PM, Eduard Moraru wrote:

I`m not very familiar with the refactoring module and its contents, but it feels wrong to have extensions have to depend on it and use it in order to achieve basic model (CRUD) operations.

Actually, even if the DeleteAction was located in a module/extension outside of oldcore, we would still need to decide if we want to bundle this action by default or not in a minimal wiki (i.e. is it a core extension). So far we’ve said that yes we need the Delete Action in an empty wiki. Instead, what we could do in the future is this: * Refactor the Page Menu to be made of Extension Points * Have a default Extension Point Provider for the Delete Action that simply implements Delete using XWiki#deleteDocument(). This would be part of core and be available in an empty wiki * Have a more elaborate Extension Provider for the Delete Action (that overrides the basic one) that uses the Refactoring module. This would be packaged in an optional extension (that we would bundle in our Flavors by default but that you wouldn’t get by default in a minimal empty wiki). <side note> I think that after we finish Nested Spaces coding, it would be nice that we start introducing and using more Extension Points (this is long overdue IMO). There are plenty of places where they would be useful. Yesterday for example I notice the hardcoding of the Wiki Index in core vm (drawer.vm) when an Extension Point in the Drawer would offer a better approach IMO. We should also discuss best practices for when using UIX vs XClass (see http://markmail.org/message/ojgmy7pljzwjq7vp). </side note> Thanks -Vincent

...

The default refactoring implementation is brought in by XE, but functional tests in platform don't have it unless they add a dependency, or we add it to the packager plugin as Vincent did. Thanks, Marius > > Thanks, > Eduard > > On Mon, Aug 31, 2015 at 6:54 PM, vincent(a)massol.net > wrote: > >> Hi, >> >> Right now almost all func tests fail to delete pages when they >> do getUtil().deletePage(…). They fail with: >> >> Caused by: org.xwiki.component.manager.ComponentLookupException: Can't >> find descriptor for the component [role = [interface org.xwiki.job.Job] >> hint = [delete]] >> >> The reason is that since XWIKI-12268 the Delete action cannot work if the >> Refactoring module isn't bundled, which makes the Refactoring module a core >> module. And this module is not part of the core modules ATM. I’ve added it >> to the PackageMojo for now but we need to decide what to do. >> >> Personally I’ve always viewed Refactoring as optional and advanced >> features. >> >> I don’t consider basic delete, basic copy and basic rename/move as >> refactoring options. However there are some parts of them that are >> refactorings. For example when Renaming, also check for wiki pages having >> the renamed page as parent and updating them or updating wiki links in >> pages. >> >> So we need to decide if: >> >> * We consider the Refactoring module as core. >> * Introduce a new module and move some of the core actions such as delete, >> move, etc to it and keep the refactoring module for non-core refactoring >> * Split the refactoring into basic refactorings and advanced ones. Have >> basic delete, copy, rename + advanced options for them separately >> * Others? >> >> WDYT? >> >> Still hesitating on my side. >> >> Thanks >> -Vincent >>

Eduard Moraru

8:08 p.m.

Hi, I get the feeling that we are overengineering it after a certain point. Yes, you could argue that the really, really, really basic operations should be in core and then the more elaborate operations can be included when needed, etc. but let's be real, nobody wants, for example, the XWiki version that only does create and view, but does not do copy + rename because in their specific code they don`t use that. Also, nobody wants the XWiki version that only works with a single document because they never create more than 1 document, etc. With nested spaces, the model has expanded and so did the operations on the model. They are part of the model, whether we like it or not, and should be bundled with the model itself. Like the wiki service, we have extended the model, but to use it in the new way, you need to depend on an "optional" module. There are very many places where XWiki is too monolithic and we need to break it apart and refactor, yes, I agree, but in these recent discussions on the topic, I personally feel we are drifting in the wrong direction. Just my personal feeling. Thanks, Eduard On Wed, Sep 2, 2015 at 6:42 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:

...

On 2 Sep 2015 at 14:49:26, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:

On Mon, Aug 31, 2015 at 7:26 PM, Eduard Moraru wrote: > I`m not very familiar with the refactoring module and its contents,

but it

> feels wrong to have extensions have to depend on it and use it in

order to

achieve basic model (CRUD) operations.

org.xwiki.job.Job]

>> hint = [delete]] >> >> The reason is that since XWIKI-12268 the Delete action cannot work if

the

>> Refactoring module isn't bundled, which makes the Refactoring module

a core

>> module. And this module is not part of the core modules ATM. I’ve

added it

>> to the PackageMojo for now but we need to decide what to do. >> >> Personally I’ve always viewed Refactoring as optional and advanced >> features. >> >> I don’t consider basic delete, basic copy and basic rename/move as >> refactoring options. However there are some parts of them that are >> refactorings. For example when Renaming, also check for wiki pages

having

>> the renamed page as parent and updating them or updating wiki links in >> pages. >> >> So we need to decide if: >> >> * We consider the Refactoring module as core. >> * Introduce a new module and move some of the core actions such as

delete,

>> move, etc to it and keep the refactoring module for non-core

refactoring

>> * Split the refactoring into basic refactorings and advanced ones.

Have

>> basic delete, copy, rename + advanced options for them separately >> * Others? >> >> WDYT? >> >> Still hesitating on my side. >> >> Thanks >> -Vincent >>

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Thomas Mortagne

1 Sep 1 Sep

2:10 p.m.

In its current state the refactoring module need to be put in the minimal package. Ideally there should be several differents packages, one with the minimum and some extension point and then various extensions providing hooks for renaming pages, etc. I would say lets put it in the minimal package and create an improvement issue for the separation, it's not a blocker. On Mon, Aug 31, 2015 at 5:54 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:

...

-- Thomas Mortagne

3302

days inactive

3304

days old

xwiki-devs@xwiki.org

Manage subscription

6 comments

5 participants

tags (0)

participants (5)

Eduard Moraru
Guillaume "Louis-Marie" Delhumeau
Marius Dumitru Florea
Thomas Mortagne
vincent＠massol.net