I'd also like to know if we can support the use case of having a normal table for which we'd like to do filtering/sorting. Could that be a special {{table}} macro that would use the {{livetable}} macro with a special source that takes the content of the {{table}} macro as the content to be displayed and extract from it both the content and the table definition? Thanks -Vincent On Sep 21, 2009, at 2:22 PM, Vincent Massol wrote:
On Sep 21, 2009, at 1:58 PM, Asiri Rathnayake wrote:
Hi Devs,
I've been thinking about the new {{doclist}} macro syntax which is going to be the successor of old livetable macro.
Then there's a pb of name since doclist is about listing document but livetable is about creating a table from a JSON source.
Why not name it {{livetable}}?
Following is the syntax I have in mind:
{{doclist <macro_parameters>}} |=(% <column_spec> %) column_name |=(% <column_spec> %) column_name |=(% <column_spec> %) column_name ... {{/doclist}}
[macro_parameters]
class="" ## bounds the table to a class.
I don't think this class parameter should be here. IMO it's a special source( json source) that will do that.
source="" ## can be a document name or a url. (will be ignored if class parameter is set)
document name = document that produces json content right?
rowCount="" ## number of rows per page.
tagCloud="" ## whether to display the tag cloud or not. (On/Off)
callback="" ## name of a js function to be used for handling server (JSON) response manually.
[column_spec]
mapping="" ## name of the json attribute to which this column should be bound to. [1] (see below)
selected="" ## if this column should be selected by default.
order="" ## Default sort order for this column (applies only if this is the default selected column).
isHtml="" ## if the result JSON string should be treated as html and directly injected into cell content.
filterable="" ## whether this column should present a filter or not.
sortable="" ## whether this columnd should be sortable or not.
filterType="" ## what type of a filter to be used (only for filterable columns).
linkType="" ## type of link to be used if a cell value should link to the original document. [2] (see below)
[1] - mapping:
This is a mandatory parameter. I'm not sure if this is the correct name for the parameter. For the default implementation (XWiki.DocListMacroResults) we have to decide the names of the JSON properties that will be returned, we could use:
"doc.<fieldName>" ## for document metadata.
"obj.<propertyName>" ## for object properties when the table is bound to a class.
"actions" ## special column for listing all the actions available for the current user.
* We could have an special "function_name(field1, field2, ....)" mapping parameter which will deligate the mapping function to a local js function. This can be useful if someone wants to calculate a column value based on the returned results.
* Question: Do we need to have attachment / image columns?
[2] - linkType:
We can have "none", "view", "edit" & "inline" type of links. Any other type of link?
You can compare this doclist macro specification with the old livetable macro spec here: http://code.xwiki.org/xwiki/bin/view/Macros/LiveTableMacro .
WDYT?
sounds good
I'd like to see also some predefined macros that would use the livetable macro. I can think of:
- a {{objects}} macro that would display a livetable of objects matching a given xclass - a {{documents}} macro that would display a livetable of documents matching a query
Thanks -Vincent
Thanks.
- Asiri