On Wed, Oct 15, 2014 at 6:08 PM, Eduard Moraru <[email protected]> wrote: > 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. Don't worry about that, it's coming ;) > > 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#HParameter24options >> >> 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/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/src/main/resources/flamingo/rightsUI.vm >> >> > _______________________________________________ >> >> > 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 >> > _______________________________________________ > 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
