28 Sep
2009
28 Sep
'09
10:28 a.m.
BTW, it would be good that the callback supports the JSON given by our
REST API natively.
I think the base versions (like {{documents}}, {{objects}}) should
consume REST resources.
We could decide that the livetable only consumes REST, but that would be
a strong limitation compared to what the velocity livetable can do
today. In my opinion, the challenge is to support both REST and non-REST
JSON sources.
Jerome.
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.
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.
source="" ## can be a document name or a url. (will be ignored if class
parameter is set)
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?
Thanks.
- Asiri
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs