Hi Asiri, On Thu, Sep 17, 2009 at 1:09 PM, <[email protected]> wrote:

Hi Asiri,

Here is some feedback about the live table since I have been using it on client projects: + things work well with the standard version - I was a pain when I had to add a custom column with information from the documents in the live table - performance when filtering a lot of documents

...

Hi All,

I'm working on designing LiveTable 2.0 macro, an xwiki/2.0 macro that is supposed to work similar to current LiveTable (say 1.0) Macro. By looking at LiveTable 1.0 macro code I encountered few problems that confuses me a lot.

* First, LiveTable macro is different from other macros (those I have seen / written so far) in which the generated content is "live"... Normally macros replaces the macro block with some other generated content but here LiveTable macro makes use of AJAX to fetch content dynamically. So the question, is LiveTable a macro or is it something else? Stuffing JavaScript/AJAX code inside a rendering 2.0 feels unfamiliar to me.

* Second, existing LiveTable macro can be viewed in several ways:

1. Way of presenting a list of documents containing an object of a specific class.

2. Way of presenting a list of documents matching a criterion.

3. Generic way of presenting information mactching a criterion.

I would like the main purpose of the live table to be the display of a list of documents from the wiki. It should be up to the user what documents the live table displays (with objects - 1, a query result -2).

...

I'm having a hard time figuring out what should be the exact purpose of LiveTable 2.0 macro, should it be same as LiveTable 1.0 macro?

I agree with Oana on this one. The Livetable can be used to suit any of the purposes you stated. However if we want to keep the macro as simple as possible we could use it only for purposes 1 & 2 and tell developers to use the underlying code when trying to achieve 3 since it most cases that's what they"ll end up doing when they want to add custom rows, data sources etc... 1) is the most useful when it comes to writing basic applications -> it would allow an application writer to easily create a dynamic list of the items of any given class. I think it's the most important for "basic" users of this macro 2) is how the livetable is used on more ambitious applications, requiring a custom data source to be written -> it's used by "advanced" users of the livetable 3) is the same as 2 in the context of XWiki since everything is a document ;-) Thus you should make the macro aiming at 1) and 2) -> Either the user specifies an object name and the macro displays documents holding such an object -> Or the user specifies a data source document and the macro displays what the data source tells it to WDYT? Guillaume

...

* Third, LiveTable macro uses several resources.

1. XWiki.LiveTableResults

2. XWiki.LiveTableResultsMacros

3. LiveTable JavaScript widget & CSS

I would like to for the javascript API to be extended, being able to listen to more events(not just xwiki:livetable:newrow).

...

If we decide that LiveTable 2.0 macro should serve the same purpose as LiveTable 1.0 macro, should these resources be reused? (within the 2.0 rendering macro)

Please help me to clarify these issues, I'm a bit lost here.

Many thanks.

- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

Guillaume Lerouge wrote:

Hi Asiri,

On Thu, Sep 17, 2009 at 1:09 PM, <[email protected]> wrote:

...

Hi Asiri,

Here is some feedback about the live table since I have been using it on client projects: + things work well with the standard version - I was a pain when I had to add a custom column with information from the documents in the live table - performance when filtering a lot of documents

...

Hi All,

I'm working on designing LiveTable 2.0 macro, an xwiki/2.0 macro that is supposed to work similar to current LiveTable (say 1.0) Macro. By looking at LiveTable 1.0 macro code I encountered few problems that confuses me a lot.

* First, LiveTable macro is different from other macros (those I have seen / written so far) in which the generated content is "live"... Normally macros replaces the macro block with some other generated content but here LiveTable macro makes use of AJAX to fetch content dynamically. So the question, is LiveTable a macro or is it something else? Stuffing JavaScript/AJAX code inside a rendering 2.0 feels unfamiliar to me.

* Second, existing LiveTable macro can be viewed in several ways:

1. Way of presenting a list of documents containing an object of a specific class.

2. Way of presenting a list of documents matching a criterion.

3. Generic way of presenting information mactching a criterion. I would like the main purpose of the live table to be the display of a list of documents from the wiki. It should be up to the user what documents the live table displays (with objects - 1, a query result -2).

...

I'm having a hard time figuring out what should be the exact purpose of LiveTable 2.0 macro, should it be same as LiveTable 1.0 macro?

I agree with Oana on this one. The Livetable can be used to suit any of the purposes you stated. However if we want to keep the macro as simple as possible we could use it only for purposes 1 & 2 and tell developers to use the underlying code when trying to achieve 3 since it most cases that's what they"ll end up doing when they want to add custom rows, data sources etc...

1) is the most useful when it comes to writing basic applications -> it would allow an application writer to easily create a dynamic list of the items of any given class. I think it's the most important for "basic" users of this macro

2) is how the livetable is used on more ambitious applications, requiring a custom data source to be written -> it's used by "advanced" users of the livetable

That's not necessarily true. The default JSON source supports tables without objects, and right now supports certain filters (like document's space or the fact the document is orphaned or not). This is how are built the AllDocs, SpaceIndex and OrphanedPages UIs in XE. For me the 2.0 syntax livetable should be user-oriented, not developer-oriented as the velocity one is, and doesn't need to support custom JSON source (at least not in a first version). Here how I see it : {{doclist /}} // displays all documents on the wiki with no restriction {{doclist creator="XWiki.JohnDoe"/}} //displays all docs created by John Doe {{doclist class="Blog.BlogPostClass" /}} displays all docs containing a Blog Post {{doclist class="XWiki.SchedulerJobClass" space="Scheduler" /}} displays all docs containing a scheduler job in the Scheduler space I think most of the metadata carried by XWikiDocument should be supported by the table (dates, author/creator, tags, etc.) I will think a little about how columns parameters should be expressed, probably using the macro's content, with a default on standards columns. Jerome.

3) is the same as 2 in the context of XWiki since everything is a document ;-)

Thus you should make the macro aiming at 1) and 2)

-> Either the user specifies an object name and the macro displays documents holding such an object

-> Or the user specifies a data source document and the macro displays what the data source tells it to

WDYT?

Guillaume

...

...

* Third, LiveTable macro uses several resources.

1. XWiki.LiveTableResults

2. XWiki.LiveTableResultsMacros

3. LiveTable JavaScript widget & CSS

I would like to for the javascript API to be extended, being able to listen to more events(not just xwiki:livetable:newrow).

...

If we decide that LiveTable 2.0 macro should serve the same purpose as LiveTable 1.0 macro, should these resources be reused? (within the 2.0 rendering macro)

Please help me to clarify these issues, I'm a bit lost here.

Many thanks.

- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Sep 18, 2009, at 10:38 AM, Jerome Velociter wrote:

Guillaume Lerouge wrote:

...

Hi Asiri,

On Thu, Sep 17, 2009 at 1:09 PM, <[email protected]> wrote:

...

Hi Asiri,

Here is some feedback about the live table since I have been using it on client projects: + things work well with the standard version - I was a pain when I had to add a custom column with information from the documents in the live table - performance when filtering a lot of documents

...

Hi All,

I'm working on designing LiveTable 2.0 macro, an xwiki/2.0 macro that is supposed to work similar to current LiveTable (say 1.0) Macro. By looking at LiveTable 1.0 macro code I encountered few problems that confuses me a lot.

* First, LiveTable macro is different from other macros (those I have seen / written so far) in which the generated content is "live"... Normally macros replaces the macro block with some other generated content but here LiveTable macro makes use of AJAX to fetch content dynamically. So the question, is LiveTable a macro or is it something else? Stuffing JavaScript/AJAX code inside a rendering 2.0 feels unfamiliar to me.

* Second, existing LiveTable macro can be viewed in several ways:

1. Way of presenting a list of documents containing an object of a specific class.

2. Way of presenting a list of documents matching a criterion.

3. Generic way of presenting information mactching a criterion. I would like the main purpose of the live table to be the display of a list of documents from the wiki. It should be up to the user what documents the live table displays (with objects - 1, a query result -2).

...

I'm having a hard time figuring out what should be the exact purpose of LiveTable 2.0 macro, should it be same as LiveTable 1.0 macro?

I agree with Oana on this one. The Livetable can be used to suit any of the purposes you stated. However if we want to keep the macro as simple as possible we could use it only for purposes 1 & 2 and tell developers to use the underlying code when trying to achieve 3 since it most cases that's what they"ll end up doing when they want to add custom rows, data sources etc...

1) is the most useful when it comes to writing basic applications -

...

it would allow an application writer to easily create a dynamic list of the items of any given class. I think it's the most important for "basic" users of this macro

2) is how the livetable is used on more ambitious applications, requiring a custom data source to be written -> it's used by "advanced" users of the livetable

That's not necessarily true.

The default JSON source supports tables without objects, and right now supports certain filters (like document's space or the fact the document is orphaned or not). This is how are built the AllDocs, SpaceIndex and OrphanedPages UIs in XE.

For me the 2.0 syntax livetable should be user-oriented, not developer-oriented as the velocity one is, and doesn't need to support custom JSON source (at least not in a first version).

I don't agree with the "not in a first version". We need to be sure that we have something generic from the onset. It's just impossible to change it afterwards. So the doclist in your example (which I'd call {{documents}} instead but that's another discussion ;)) would for me use a more generic version so that we can write other specific macros extending that generic version instead of rewriting the new one and duplicating lots of code. I'd also like to see the ability to use the generic version from the onset even though it wouldn't be used normally by end users (they'd use the specialized version). Then we should have specialized macros for all the needs we already have in XE.

Here how I see it :

{{doclist /}} // displays all documents on the wiki with no restriction

{{doclist creator="XWiki.JohnDoe"/}} //displays all docs created by John Doe

{{doclist class="Blog.BlogPostClass" /}} displays all docs containing a Blog Post

{{doclist class="XWiki.SchedulerJobClass" space="Scheduler" /}} displays all docs containing a scheduler job in the Scheduler space

I think most of the metadata carried by XWikiDocument should be supported by the table (dates, author/creator, tags, etc.)

Sounds good. Need support for queries too (query="xwql:...", query="hql:...." or query="..." and queryType="hql | xwql" which I prefer) and the specific params would get transformed into that query.

I will think a little about how columns parameters should be expressed, probably using the macro's content, with a default on standards columns.

It could even be a nested macro so that you don't have parsing to do. Thanks -Vincent

Jerome.

...

3) is the same as 2 in the context of XWiki since everything is a document ;-)

Thus you should make the macro aiming at 1) and 2)

-> Either the user specifies an object name and the macro displays documents holding such an object

-> Or the user specifies a data source document and the macro displays what the data source tells it to

WDYT?

Guillaume

...

...

* Third, LiveTable macro uses several resources.

1. XWiki.LiveTableResults

2. XWiki.LiveTableResultsMacros

3. LiveTable JavaScript widget & CSS

I would like to for the javascript API to be extended, being able to listen to more events(not just xwiki:livetable:newrow).

...

If we decide that LiveTable 2.0 macro should serve the same purpose as LiveTable 1.0 macro, should these resources be reused? (within the 2.0 rendering macro)

Please help me to clarify these issues, I'm a bit lost here.

Many thanks.

- Asiri

Vincent Massol wrote:

On Sep 18, 2009, at 10:38 AM, Jerome Velociter wrote:

...

Guillaume Lerouge wrote:

...

Hi Asiri,

On Thu, Sep 17, 2009 at 1:09 PM, <[email protected]> wrote:

...

Hi Asiri,

Here is some feedback about the live table since I have been using it on client projects: + things work well with the standard version - I was a pain when I had to add a custom column with information from the documents in the live table - performance when filtering a lot of documents

...

Hi All,

I'm working on designing LiveTable 2.0 macro, an xwiki/2.0 macro that is supposed to work similar to current LiveTable (say 1.0) Macro. By looking at LiveTable 1.0 macro code I encountered few problems that confuses me a lot.

* First, LiveTable macro is different from other macros (those I have seen / written so far) in which the generated content is "live"... Normally macros replaces the macro block with some other generated content but here LiveTable macro makes use of AJAX to fetch content dynamically. So the question, is LiveTable a macro or is it something else? Stuffing JavaScript/AJAX code inside a rendering 2.0 feels unfamiliar to me.

* Second, existing LiveTable macro can be viewed in several ways:

1. Way of presenting a list of documents containing an object of a specific class.

2. Way of presenting a list of documents matching a criterion.

3. Generic way of presenting information mactching a criterion. I would like the main purpose of the live table to be the display of a list of documents from the wiki. It should be up to the user what documents the live table displays (with objects - 1, a query result -2).

...

I'm having a hard time figuring out what should be the exact purpose of LiveTable 2.0 macro, should it be same as LiveTable 1.0 macro? I agree with Oana on this one. The Livetable can be used to suit any of the purposes you stated. However if we want to keep the macro as simple as possible we could use it only for purposes 1 & 2 and tell developers to use the underlying code when trying to achieve 3 since it most cases that's what they"ll end up doing when they want to add custom rows, data sources etc...

1) is the most useful when it comes to writing basic applications -

...

it would allow an application writer to easily create a dynamic list of the items of any given class. I think it's the most important for "basic" users of this macro

2) is how the livetable is used on more ambitious applications, requiring a custom data source to be written -> it's used by "advanced" users of the livetable That's not necessarily true.

The default JSON source supports tables without objects, and right now supports certain filters (like document's space or the fact the document is orphaned or not). This is how are built the AllDocs, SpaceIndex and OrphanedPages UIs in XE.

For me the 2.0 syntax livetable should be user-oriented, not developer-oriented as the velocity one is, and doesn't need to support custom JSON source (at least not in a first version).

I don't agree with the "not in a first version". We need to be sure that we have something generic from the onset. It's just impossible to change it afterwards.

So the doclist in your example (which I'd call {{documents}} instead but that's another discussion ;)) would for me use a more generic version so that we can write other specific macros extending that generic version instead of rewriting the new one and duplicating lots of code.

I'd also like to see the ability to use the generic version from the onset even though it wouldn't be used normally by end users (they'd use the specialized version).

Then we should have specialized macros for all the needs we already have in XE.

...

Here how I see it :

{{doclist /}} // displays all documents on the wiki with no restriction

{{doclist creator="XWiki.JohnDoe"/}} //displays all docs created by John Doe

{{doclist class="Blog.BlogPostClass" /}} displays all docs containing a Blog Post

{{doclist class="XWiki.SchedulerJobClass" space="Scheduler" /}} displays all docs containing a scheduler job in the Scheduler space

I think most of the metadata carried by XWikiDocument should be supported by the table (dates, author/creator, tags, etc.)

Sounds good. Need support for queries too (query="xwql:...", query="hql:...." or query="..." and queryType="hql | xwql" which I prefer) and the specific params would get transformed into that query.

We have to decide if we want to support queries or not. We made the choice not to support queries sent over HTTP to the pseudo-REST service when writting the velocity livetable with Ludovic. For security reasons, but I must admit I don't recall exactly why. Maybe Ludovic remembers. Jerome.

...

I will think a little about how columns parameters should be expressed, probably using the macro's content, with a default on standards columns.

It could even be a nested macro so that you don't have parsing to do.

Thanks -Vincent

...

Jerome.

...

3) is the same as 2 in the context of XWiki since everything is a document ;-)

Thus you should make the macro aiming at 1) and 2)

-> Either the user specifies an object name and the macro displays documents holding such an object

-> Or the user specifies a data source document and the macro displays what the data source tells it to

WDYT?

Guillaume

...

...

* Third, LiveTable macro uses several resources.

1. XWiki.LiveTableResults

2. XWiki.LiveTableResultsMacros

3. LiveTable JavaScript widget & CSS

I would like to for the javascript API to be extended, being able to listen to more events(not just xwiki:livetable:newrow).

...

If we decide that LiveTable 2.0 macro should serve the same purpose as LiveTable 1.0 macro, should these resources be reused? (within the 2.0 rendering macro)

Please help me to clarify these issues, I'm a bit lost here.

Many thanks.

- Asiri

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, How about:

{{doclist ....}}

|(%field="doc.name" sort="true"%)Name |(%field="doc.creator"%)Creator |(%field="doc.tags"%)Tags

{{/doclist}}

Looks familiar :)

+ easily parsed. Although need to be careful with multiple syntaxes. Table specification should be in whatever the syntax the "doclist" macro is invoked from. Thanks. - Asiri

[email protected] wrote:

...

Hi Asiri,

Here is some feedback about the live table since I have been using it on client projects: + things work well with the standard version - I was a pain when I had to add a custom column with information from the documents in the live table - performance when filtering a lot of documents

...

Hi All,

I'm working on designing LiveTable 2.0 macro, an xwiki/2.0 macro that is supposed to work similar to current LiveTable (say 1.0) Macro. By looking at LiveTable 1.0 macro code I encountered few problems that confuses me a lot.

* First, LiveTable macro is different from other macros (those I have seen / written so far) in which the generated content is "live"... Normally macros replaces the macro block with some other generated content but here LiveTable macro makes use of AJAX to fetch content dynamically. So the question, is LiveTable a macro or is it something else? Stuffing JavaScript/AJAX code inside a rendering 2.0 feels unfamiliar to me.

* Second, existing LiveTable macro can be viewed in several ways:

1. Way of presenting a list of documents containing an object of a specific class.

2. Way of presenting a list of documents matching a criterion.

3. Generic way of presenting information mactching a criterion.

I would like the main purpose of the live table to be the display of a list of documents from the wiki. It should be up to the user what documents the live table displays (with objects - 1, a query result -2).

...

I'm having a hard time figuring out what should be the exact purpose of LiveTable 2.0 macro, should it be same as LiveTable 1.0 macro?

* Third, LiveTable macro uses several resources.

1. XWiki.LiveTableResults

2. XWiki.LiveTableResultsMacros

3. LiveTable JavaScript widget & CSS

I would like to for the javascript API to be extended, being able to listen to more events(not just xwiki:livetable:newrow).

Yes, that could be the occasion to extend the JS API.

What events do you have in mind ?

Jerome.

I would like to have: 1) xwiki:livetable:header Similar to newrow, but refers to the header table. Can help adding functionality when working with custom columns. This one would have helped a lot when working on the watch list for Water Wiki since I could not add a custom filter into the header. 2) refresh() method Redisplay the live table and the correct pagination when adding/deleting files. 3) display a nice info message when the live table is empty Something general like "No items in your live table" and hide the pagination. Oana

...

...

If we decide that LiveTable 2.0 macro should serve the same purpose as LiveTable 1.0 macro, should these resources be reused? (within the 2.0 rendering macro)

Please help me to clarify these issues, I'm a bit lost here.

Many thanks.

- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

[email protected] wrote:

...

...

[email protected] wrote:

...

Hi Asiri,

Here is some feedback about the live table since I have been using it on client projects: + things work well with the standard version - I was a pain when I had to add a custom column with information from the documents in the live table - performance when filtering a lot of documents

...

Hi All,

I'm working on designing LiveTable 2.0 macro, an xwiki/2.0 macro that is supposed to work similar to current LiveTable (say 1.0) Macro. By looking at LiveTable 1.0 macro code I encountered few problems that confuses me a lot.

* First, LiveTable macro is different from other macros (those I have seen / written so far) in which the generated content is "live"... Normally macros replaces the macro block with some other generated content but here LiveTable macro makes use of AJAX to fetch content dynamically. So the question, is LiveTable a macro or is it something else? Stuffing JavaScript/AJAX code inside a rendering 2.0 feels unfamiliar to me.

* Second, existing LiveTable macro can be viewed in several ways:

1. Way of presenting a list of documents containing an object of a specific class.

2. Way of presenting a list of documents matching a criterion.

3. Generic way of presenting information mactching a criterion. I would like the main purpose of the live table to be the display of a list of documents from the wiki. It should be up to the user what documents the live table displays (with objects - 1, a query result -2).

...

I'm having a hard time figuring out what should be the exact purpose of LiveTable 2.0 macro, should it be same as LiveTable 1.0 macro?

* Third, LiveTable macro uses several resources.

1. XWiki.LiveTableResults

2. XWiki.LiveTableResultsMacros

3. LiveTable JavaScript widget & CSS

I would like to for the javascript API to be extended, being able to listen to more events(not just xwiki:livetable:newrow).

Yes, that could be the occasion to extend the JS API.

What events do you have in mind ?

Jerome.

I would like to have: 1) xwiki:livetable:header Similar to newrow, but refers to the header table. Can help adding functionality when working with custom columns. This one would have helped a lot when working on the watch list for Water Wiki since I could not add a custom filter into the header.

Headers are not injected in JS, they are given as HTML by the server.

What we could do is fire an event upon table initialization.

...

2) refresh() method Redisplay the live table and the correct pagination when adding/deleting files.

By files you mean entries ?

Yes, I mean entries. (e.g I needed this when I used an AJAX request to remove a document from my watch list and I wanted to see the result in the watch list live table). Oana

refresh() is simple to add.

...

3) display a nice info message when the live table is empty Something general like "No items in your live table" and hide the pagination.

Yes that one would be nice. I'm also planning planning to inject server side errors in the table, so that one can know if the table is empty because there's no element or because the request failed.

Jerome.

...

Oana

...

...

...

If we decide that LiveTable 2.0 macro should serve the same purpose as LiveTable 1.0 macro, should these resources be reused? (within the 2.0 rendering macro)

Please help me to clarify these issues, I'm a bit lost here.

Many thanks.

- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs