On Fri, Oct 3, 2014 at 11:58 AM, Thomas Mortagne <[email protected]> wrote:

On Fri, Oct 3, 2014 at 10:43 AM, Marius Dumitru Florea <[email protected]> wrote:

...

Hi devs,

Following the vote on http://lists.xwiki.org/pipermail/devs/2014-September/057560.html I started working on a generic tree widget based on jsTree. I'm almost done now and I'm wondering where's the best place to commit my work. There are 3 parts:

(1) A generic JavaScript tree widget (used by all trees)

The common practice so far was to put the new JavaScript code in xwiki-platform-web (resources/uicomponents). But since we started using webjars I'm wondering if it's not better to create a webjar. The advantage is that the applications will be able to explicitly declare a dependency on the tree widget. The downside is that the JavaScript code is a bit harder to modify. Another option is to put the tree widget in a JSX object but we may need to use it in Velocity templates also (e.g. the report step of the DW).

I prefer the webjar.

+1 for webjar

...

(2) A couple of wiki pages that define specific trees:

* One page for the All Docs Tree (space-page-child) * One page for the XWiki Entity Tree (wiki-space-page-[translations|attachments|objects|properties|sections]) * One page for the Hierarchy Tree (page-child) * One page for the XAR import tree (space-page) * others later maybe

I'm hesitating between creating a dedicated module (xwiki-platform-tree-ui) and putting them in existing modules like the xwiki-platform-index.

I really don't like too much grouping pages based on a technical criteria (xwiki-platform-panels-ui is very bad) so my vote goes to putting those pages where their content make sense. So that's probably xwiki-platform-index for most of them. However there is something I don't understand here, how is the import UI which is a template is supposed to work without the XAR import tree (which will happen in an empty wiki) ?

Indeed, the XAR import tree must be defined in a Velocity template. I shouldn't have put it in the list above. I also prefer putting the pages that define specific trees in the module that match their domain. Now, I will also create a wiki macro {{tree source="doc:Space.MyTree" /}} but I guess I will put this macro in xwiki-platform-rendering-macro-tree. Thanks, Marius

...

(3) A couple of jobs (Java code) to perform tree operations that can take time, like deleting or renaming a space.

For these I could use the xwiki-platform-refactoring module since they are generic operations, not limited to trees. We have a Delete space entry in the top menu and we probably want a Rename space one.

xwiki-platform-refactoring sounds good

...

WDYT?

Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

  On 3 Oct 2014 at 11:11:27, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:

On Fri, Oct 3, 2014 at 11:58 AM, Thomas Mortagne wrote:

...

On Fri, Oct 3, 2014 at 10:43 AM, Marius Dumitru Florea wrote:

...

Hi devs,

Following the vote on http://lists.xwiki.org/pipermail/devs/2014-September/057560.html I started working on a generic tree widget based on jsTree. I'm almost done now and I'm wondering where's the best place to commit my work. There are 3 parts:

(1) A generic JavaScript tree widget (used by all trees)

The common practice so far was to put the new JavaScript code in xwiki-platform-web (resources/uicomponents). But since we started using webjars I'm wondering if it's not better to create a webjar. The advantage is that the applications will be able to explicitly declare a dependency on the tree widget. The downside is that the JavaScript code is a bit harder to modify. Another option is to put the tree widget in a JSX object but we may need to use it in Velocity templates also (e.g. the report step of the DW).

I prefer the webjar.

+1 for webjar

...

(2) A couple of wiki pages that define specific trees:

* One page for the All Docs Tree (space-page-child) * One page for the XWiki Entity Tree (wiki-space-page-[translations|attachments|objects|properties|sections]) * One page for the Hierarchy Tree (page-child) * One page for the XAR import tree (space-page) * others later maybe

I'm hesitating between creating a dedicated module (xwiki-platform-tree-ui) and putting them in existing modules like the xwiki-platform-index.

I really don't like too much grouping pages based on a technical criteria (xwiki-platform-panels-ui is very bad) so my vote goes to putting those pages where their content make sense. So that's probably xwiki-platform-index for most of them. However there is something I don't understand here, how is the import UI which is a template is supposed to work without the XAR import tree (which will happen in an empty wiki) ?

Indeed, the XAR import tree must be defined in a Velocity template. I shouldn't have put it in the list above.

I also prefer putting the pages that define specific trees in the module that match their domain. Now, I will also create a wiki macro

{{tree source="doc:Space.MyTree" /}}

but I guess I will put this macro in xwiki-platform-rendering-macro-tree.

Yep that’s a good location. Thanks -Vincent

Thanks, Marius

...

...

(3) A couple of jobs (Java code) to perform tree operations that can take time, like deleting or renaming a space.

For these I could use the xwiki-platform-refactoring module since they are generic operations, not limited to trees. We have a Delete space entry in the top menu and we probably want a Rename space one.

xwiki-platform-refactoring sounds good

...

WDYT?

Thanks, Marius