3 Oct
2014
3 Oct
'14
10:43 a.m.
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.
(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.
(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.
WDYT?
Thanks,
Marius
3 Oct
3 Oct
10:58 a.m.
On Fri, Oct 3, 2014 at 10:43 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> 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) ?
(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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
11:11 a.m.
On Fri, Oct 3, 2014 at 11:58 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Fri, Oct 3, 2014 at 10:43 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
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
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) ?
(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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:23 a.m.
On Fri, Oct 3, 2014 at 11:11 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On Fri, Oct 3, 2014 at 11:58 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Same comment for whatever the distribution wizard is going to reuse (I
guess it means most very standard trees should be in templates).
On Fri, Oct 3, 2014 at 10:43 AM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Indeed, the XAR import tree must be defined in a Velocity template. I
shouldn't have put it in the list above. 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) ?
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
(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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
11:59 a.m.
On 3 Oct 2014 at 11:11:27, Marius Dumitru Florea
(mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:
On Fri, Oct 3, 2014 at 11:58 AM, Thomas Mortagne
wrote:
Yep that’s a good location.
Thanks
-Vincent
On Fri, Oct 3, 2014 at 10:43 AM, Marius Dumitru
Florea
wrote:
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. 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) ? 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
11:58 a.m.
Hi Marius,
On 3 Oct 2014 at 10:43:59, Marius Dumitru Florea
(mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) 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.
I also prefer the webjar option.
(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 prefer a lot to have them in the existing modules where they are used. We’ve been trying
to organize our modules by functional domains instead of technical domains.
(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.
Indeed that could be a good idea (for now).
Thanks
-Vincent
WDYT?
Thanks,
Marius
4046
days inactive
4046
days old
5 comments
3 participants
participants (3)
-
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net