On Wed, Oct 15, 2014 at 3:45 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Oct 15, 2014 at 1:45 PM, Eduard Moraru <[email protected]> wrote:
Marius, thanks for the explanation, but I had no confusion there. Maybe I did not explain myself clear enough.
The question (originally asked by Vincent) from the OP is
"Can/should we use the livetable inside templates?
The live table widget can be used anywhere. I don't see why you wouldn't use it in Velocity templates. Any widget from xwiki-platform-web can and should be used in Velocity templates if needed.
Fine by me. Do others have a different opinion on this? Then a first thing we would need to do for the #livetable macro is to add a parameter that makes it stop adding the {{html}} and {{/html}} macro calls since in templates we don`t have XWiki syntax. It seems that the current assumption was that the #livetable macro would always be called from wiki syntax, and that is not true for templates. Side note: Now that I`ve mentioned, I also wonder what is stopping us from actually applying rendering for the templates as well so we can have access to wiki syntax, but that's another discussion. Thanks, Eduard
Is the livetable part of xwiki-platform-web or is a removable extension (xwiki-platform-livetable)?"
The live table widget is part of xwiki-platoform-web. What we have in xwiki-platform-livetable-ui is just a helper to ease the creation of a live table data source but it not required to use the live table. Moreover, the main use case that xwiki-platform-livetable-ui tries to cover is when you have an XClass. Most of the code from XWiki.LiveTableResultsMacros handles the querying, sorting and filtering on XObject properties. If your live table displays only document fields (title, author, date) and no XObject properties then most of that code is unused.
Do we want to have that as a common practice inside templates when
listing
documents or not?
If we do want it to be used inside templates, does it make sense to ask each template to implement its own data source (like you are proposing now for the delete space UI example) or should we allow the templates to use the default data source (by making it a template as well)?
It's a bad practice to have a Velocity template that depends on an XClass. Thus we shouldn't have the need to list documents of a certain type (XClass) in a Velocity template. Thus most of the code from xwiki-platform-livetable-ui wouldn't be needed when the live table is used in a Velocity template. That's why I'm not so sure we need to move the code from xwiki-platform-livetable-ui to Velocity templates.
We shouldn't write a new data source for each live table that lists (plain) documents in a Velocity template of course. I would probably start by writing the source for the list of document to delete from the space and then when a new use case appears I would see how that source can be reused.
Thanks, Eduard
On Wed, Oct 15, 2014 at 11:42 AM, Marius Dumitru Florea < [email protected]> wrote:
Edy, you're mixing two things:
(1) The live table widget. This is currently provided by xwiki-platform-web. The widget has some HTML template (currently in macros.vm), some JavaScript code (livetable.js) and some CSS (livetable.css). The widget is configurable. The main configuration option is the data source. As written on
http://extensions.xwiki.org/xwiki/bin/view/Extension/Livetable+Macro#HParame...
you can specify the data source either using the 'resultPage' or the 'url' parameter. What's important is that it can use **any** data source.
(2) The default data source. This is currently provided by xwiki-platform-livetable. Many applications have their own data sources though. You don't need this to use the live table widget.
For the delete space UI issue you can use the "url" parameter server the live table JSON from a template, so you don't need xwiki-platform-livetable.
The only question for me is whether the default data source should be moved to a template or not. I don't think we need to move it.
Thanks, Marius
On Tue, Oct 14, 2014 at 10:52 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
While looking into the delete space UI issue [1], we first thought about directly using the livetable macro to list the documents to be deleted from the space.
Now the problem, as state by Vincent: Can/should we use the livetable inside templates? Is the livetable part of xwiki-platform-web or is a removable extension (xwiki-platform-livetable)?
Currently, xwiki-platform-livetable only contains the 2 pages that generate the JSON for the livetable, but the html markup is generated by the #livetable macro (macros.vm) and the livetable.css and livetable.js files are all in xwiki-platform-web.
The only case of it being used in templates right now is in rightsUI.vm [2] where the macro is not directly called, but the html markup is created by hand and the javascript and css is included.
IMO, we should decide on a single approach for the livetable and use it all the way. What we do currently can be confusing even for us.
I currently see two directions:
1) Move the content of xwiki-platform-livetable in a xwiki-platform-web as templates so that the livetable is a core feature and that it also works in the UI when the database is empty.
2) Move the livetable macro (as wiki macro?), js (as JSX) and css (as SSX) from xwiki-platform-web to xwiki-platform-livetable and see the livetable as just another extension/feature that is only present when installed. The rightsUI would need a change as well, since it can no longer rely on the livetable and probbaly we would also need to find a way to allow extenions to contribute filesystem resources.
I thought it would be a good idea to open a discussion on this topic since it's currently, AFAIK, a grey area.
WDYT?
Thanks, Eduard
---------- [1] http://jira.xwiki.org/browse/XWIKI-8320 [2]
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik...
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs