30 Apr
2009
30 Apr
'09
11:10 a.m.
On Apr 30, 2009, at 10:14 AM, Jerome Velociter wrote:
Hi Vincent,
Note the livetable is an empty table everywhere you don't have
JavaScript.
Inserting the select in JavaScript sounds a bad idea to me. It would
be
a hack to hide form controls (button, select, etc) to renderers for
which they do not have sense. But those form controls are meaningful
in
the macro, to me a form is something that by itself justify the use of
the HTML macro. (and actually I'm not sure you can do that trick that
easily, since the select values are generated server side from
velocity).
I'm completely convinced we have to use standard wiki syntax as much
as
possible, but we should also keep in mind that some macros will not
make
any kind of sense anywhere but in a browser. Can renderers that do not
support HTML fragments just drop them (eventually outputting a message
to say a part of the original document is missing) ?
Yes that's the problem: they'll be dropped. So instead of a table with
data it'll be an empty space.
That said we need to think how we'd want a livetable to be displayed
in other renderers.
As I said that's not a problem we have now but we need to be aware of
it since it'll crop up again one day.
-Vincent
Thanks,
Jerome.
Vincent Massol wrote:
> Note that since you've used the HTML macro using renderers may not
> output the live grid (only renderers that support HTML will be able
> to
> output some result).
>
> I've checked the html and all of it could be replaced by wiki syntax
> except for the select part. We could use wiki syntax everywhere and
> use some JS to inject the select in the HTML DOM afterwards. This
> would allow to output it easily.
>
> We currently have only 2 renderers that we use: xwiki syntax and
> xhtml
> and both support Raw events when the syntax is HTML. We can imagine
> that PDF, RTF renderers would also support it (it'll depend on how we
> implement it, if we use FOP it's fine but there's also a very simple
> way to implement a PDF renderer using itext but then I don't think if
> it can support HMTL fragments). We have a LaTex renderer that we
> currently don't use and this one won't work for example.
>
> This is just a thought for now. We just need to be aware of it for
> the
> future. We need to remember that using the HTML macro bypasses the
> rendering mechanism and thus generate non standard stuff.
>
> Thanks
> -Vincent
>
> On Apr 30, 2009, at 8:08 AM, jvelociter (SVN) wrote:
>
>> Author: jvelociter
>> Date: 2009-04-30 08:08:53 +0200 (Thu, 30 Apr 2009)
>> New Revision: 19209
>>
>> Modified:
>> platform/core/trunk/xwiki-core/src/main/resources/
>> ApplicationResources.properties
>> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/
>> table/livetable.css
>> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/
>> table/livetable.js
>> platform/web/trunk/standard/src/main/webapp/templates/macros.vm
>> Log:
>> XWIKI-3705 Clean and enhance the javascript Live Table component
>> XWIKI-3706 Provide a velocity macro to automate the creation of live
>> tables
>>
>> * Added support for multiple pagination nodes (for example one on
>> top, and one under the table). Formatting of livetable.js
>> * Added the #livetable macro in macros.vm, that supports syntax 1.0
>> and 2.0
>>