Ah, ok, now I understand (I hope) :)

Indeed the livetable macro is in that place, but this is because the flamingo 
skin overrides some of the macros;
the "original" is actually here: 

I guess both macros should be updated, as other skins will use the version in 
xwiki-platform-web by default.

(Btw, as the variant in the flamingo skin seems to be there to stay, I wonder 
if one wants to split that file
into two parts, one containing the macros overwritten in the flamingo-skin, and 
the other one containing the common ones.
Or is this considered an "API breakage" ?)

Anyway, when adding a "dateformat" to one of the $columnsProperties it might be 
still some way to go to get this working ...
I just tried to track this down, and ended up with the following (any better 
idea how to do it?)

 - the livetable macro does not really render much stuff by itself, but 
delegates most to the AJAX call
   You can see that in the <script> part, where a JavaScript at the end of the 
macro, where
   the  function startup()  creates a JavaScript object : 
XWiki.widgets.LiveTable  that does the actual loading

 - just in case you wonder how this triggers the Ajax call, this JavaScript 
class in turn is in the file
   but I guess that does not need to be touched. (at least)

 - instead you can see how the AJAX-request parameters are put together in the 
#livetable macro in

    #set ($parameters = {
      'outputSyntax': 'plain',
      'transprefix': $transprefix,
      'classname': $classname,
      'collist': $stringtool.join($dataColumns, ','),
      'queryFilters': $queryFilters

  You can see these parameters are send via Ajax if you check your browsers 
network tab.

  So this would be the place to add more parameters.
  However as you might see there are no column-specific parameters, only 
"global" ones. So you need to invent a schema to pass these "parameters for 
columns" in, too.
  Maybe it might be easier to try to send a "global" dateformat, at least for a 
first try? (I.e. "globally" used for all entries in the current livetable)

  Anyway, these parameters are then send to the XWiki.LiveTableResults : 
which in turn delegate most of the work into the  XWiki.LiveTableResultsMarco   
there the call chain in the velocity macros is:

  gridresultwithfilter -> calls gridresultwithfilter_buildJSON  -> 
gridresult_buildRowsJSON -> gridresult_buildRowJSON

In the latter one you find the code which creates the (already formatted) 
doc.creationDate (already formatted, because "Date" is no JSON data type that 
can be passed around, and also formatting Dates in JavaScript + Timezone issues 
= Desperation IMO)
It is somewhere:
  #set($discard = $row.put('doc_date', $xwiki.formatDate($translatedDoc.date)))
   #set($discard = $row.put('doc_creationDate', 

Then this macro, for custom class property date columns, delegates to 
gridresult_buildColumnJSON, which just called the "display" for that class 
property and I guess that will ignore any attempts to change date formatting.

It looks like after putting the date format into the request you would have to 
read the format from the request in XWiki.LiveTableResults and pass it around 
through all the macros ...

> Yes I know that format_date parameter doesn't exist for the moment :-), I 
> wanted to improve livetable macro (with pull request at the end I hope). I 
> think I find where this macro 
> is:https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/src/main/resources/flamingo/macros.vmLine
>  1261
> #macro(livetable $divid $collist $colprops $options)
> I saw the "Modify the JSON data ..." solution but afraid about "...since it 
> would slow down your wiki a lot as it loads Doc"Thxs

That "slow down your wiki" comment is only about the action happening in that 
specific example, because it loads a document for every element in the result 
set into memory.
If you do something with the data already loaded I think it should not be too 
Personally I still think this is the way to go ...

>       De : Clemens Klein-Robbenhaar <c.robbenh...@espresto.com>
>  À : users@xwiki.org 
>  Envoyé le : Mardi 13 janvier 2015 16h10
>  Objet : Re: [xwiki-users] Add date of account creation (without time) in 
> User Index problem
> On 01/13/2015 03:05 PM, Pascal BASTIEN wrote:
>> Thxs a lot to explained me with clarity all of that and help me to 
>> understand better XWiki.
>> Then with what you give me, I tried to add a  format_date parameter () (or 
>> regexp) in columns properties to improve livetable.
>> I failed because I didn't manage to find where is store livetable macro :-))
>> Something like this and next add a format date parameter in user index 
>> customizer.
>> #set($columns = ["_avatar", "first_name", "last_name", "email", 
>> "doc.creationDate", "_actions"])
>> #set($columnsProperties = {
>>     "_avatar" : { "type" : "none", "link" : "none", "html" : "true", 
>> "sortable":false },
>>     "first_name" : { "type" : "text" , "size" : 20, "link" : "view"},
>>     "last_name" : { "type" : "text", "link" : "view"},
>>     "email" : { "type" : "text" },
>>     "doc.creationDate" : { "type" : "date", "dateformat":"YYYY-mm" }
>> })
> I am afraid that this does not work.
> The supported options are documented here:
>   http://extensions.xwiki.org/xwiki/bin/view/Extension/Livetable+Macro
> and a 'dateformat' option is unfortunately not part of it.
> The problem is that in the end the #livetable macro turns out to make an AJAX 
> call
> to the code at the page XWiki.LiveTableResults ,  which in turn uses the 
> XWiki.LiveTableResultsMacros
> and the latter just calls  $xwiki.formatDate($itemDoc.creationDate)) without 
> any custom format.
> What you can to is:
>  - either again patch that line of code in the XWiki.LiveTableResultsMacros 
> with a date format of your choice
>  - or modify the results afterwards, as explained  
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Livetable+Macro#HCustomJSON
>   (scroll down to the "Starting with XWiki Enterprise 4.0 you can modify the 
> default JSON ...")
> the later would involve creating your own livetable result page, i.e. 
> XWiki.LiveTableResultsNoTime
> with e.g. the contents:
> {{include reference="XWiki.LiveTableResultsMacros" /}}
> {{velocity wiki="false"}}
> #if("$!{request.xpage}" == 'plain')
>  $response.setContentType('application/json')
> #end
> ##==================
> ## Initialize the map that will store the JSON data.
> ##==================
> #set($map = {})
> ##==================
> ## Build the JSON in memory using the previous map
> ##==================
> #gridresult_buildJSON("$!request.classname" $request.collist.split(',') $map)
> ##==================
> ## Modify the JSON data from the map or add new data.
> ##==================
> #foreach($row in $map.get('rows'))
>  #if($row.get('doc_creationDate'))
>     #set($creation_date = $row.get('doc_creationDate'))
>     #set($time_sep_index = $creation_date.indexOf(' '))
>     #if($time_sep_index >=0)
>       #set($creation_date_without_time = $creation_date.substring(0, 
> $time_sep_index))
>       #set($discard = $row.put('doc_creationDate', 
> $creation_date_without_time ))
>     #end
>  #end
> #end
> ##==================
> ## Serialize the map in the JSON format.
> ##==================
> $jsontool.serialize($map)
> {{/velocity}}
> this mostly copy & paste from the LiveTable docs, expect for the "Modify the 
> JSON data ..." part,
> where the creation date field is simply cut off after the first space - quite 
> hackish, but should work
> for most date formats.
> Now when calling that page to get the results, everything must be put inside 
> the 'url' option
> so the $options change to:
> #set($options = {
>   "url" : "$xwiki.getURL('XWiki.LiveTableResultsNoTime', 'get', 
> 'outputSyntax=plain&classname=XWiki.XWikiUsers&transprefix=xe.userdirectory.&collist=_avatar,first_name,last_name,email,doc.creationDate')",
>   "rowCount": 10
> })
> Afterwards it is just a matter of a few hours debugging with firebug etc 
> until one finds the missing ')' or '"' that keeps things from working ;)
> Oh, and come to think of it, the simplest solution would be to change
> the XWiki date format the XWiki Admin to exclude the time - that would remove
> the time everywhere, but I know people who actually like it. ;)
>> #set($options = {
>>   "className":"XWiki.XWikiUsers",
>>   "translationPrefix" : "xe.index.users.",
>>   "tagCloud" : true,
>>   "rowCount": 10
>> })
>> #livetable("userdirectory" $columns $columnsProperties $options)
> [...]
> _______________________________________________
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users

mit freundlichen Grüßen
Clemens Klein-Robbenhaar

Clemens Klein-Robbenhaar
Software Development
EsPresto AG
Breite Str. 30-31
10178 Berlin/Germany
Tel: +49.(0)30.90 226.763
Fax: +49.(0)30.90 226.760

HRB 77554 B - Berlin-Charlottenburg
Vorstand: Maya Biersack, Peter Biersack
Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber
Zertifiziert nach ISO 9001:2008
users mailing list

Reply via email to