Vincent Massol wrote:
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.
For me, we should display a message that explain "this part of the document cannot be represented in this format". Could this be a parameter of the HTML macro, the "I'm sorry I can not be rendered with this renderer, etc." message ? Again, even if we make the macro use only wiki syntax, it will be an empty table, which is IMHO worse than an empty space (users will be wondering that is supposed to be). Of course we can think of an alternative to be displayed (which I believe is not an easy task for a live table, since you'll never want to display a table with 30.000 entries, so displaying the whole table is... out of the table), but we'll have the case anyway with potentially lot of other things. (How do you render a canvas element ? a flash object ? an applet ? etc.) I really think we'll need a way to display an "excuse message". Jerome.
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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs