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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
