17 Sep
2009
17 Sep
'09
11:54 a.m.
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'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
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
17 Sep
17 Sep
1:09 p.m.
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).
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:17 p.m.
Hi Asiri,
On Thu, Sep 17, 2009 at 1:09 PM, <oana.tabaranu(a)xwiki.com> wrote:
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
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
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
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).
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
18 Sep
18 Sep
10:21 a.m.
Hi,
-> 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
Sounds perfect. I like the fact that this way we can define the purpose of
the livetable macro precisely, I mean "a generic way of presenting
information" is not a good specification for a macro and the implementation
too would be rather complex.
Also, when I discussed about LiveTable macro 2.0 with jerome we both agreed
that it is best written as a wiki macro rather than a java macro. Being a
wiki macro it has the potential of utilizing JSX & SSX to host all the
JavaScript & CSS required by the macro.
WDYT?
Anyway, I'm waiting for jerome to put his opinions into this thread :) (the
conversation we had was brief)
Thanks.
- Asiri
10:38 a.m.
Guillaume Lerouge wrote:
Hi Asiri,
On Thu, Sep 17, 2009 at 1:09 PM, <oana.tabaranu(a)xwiki.com> wrote:
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.
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
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 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?
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:54 a.m.
Hi,
On Fri, Sep 18, 2009 at 10:38 AM, Jerome Velociter <jerome(a)xwiki.com> wrote:
Guillaume Lerouge wrote:
I agree with Oana on this one. The Livetable can be used to suit any of the
Yep, that sounds great.
Hi Asiri,
On Thu, Sep 17, 2009 at 1:09 PM, <oana.tabaranu(a)xwiki.com> 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? 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.)
+1.
I will think a little about how columns parameters
should be expressed,
probably using the macro's content, with a default on standards columns.
Maybe have a macro that has 2 steps:
- Pass parameters (which user, which object, which space)
- Once the parameters have been selected, run a query and see which
properties come up
- Display each property with a checkbox next to it
- The user checks the properties he wants to see displayed in the
livetable (date, author, document name)
- The livetable displays those properties
- We add a default displayer that uses name - author - date
I'm not sure what's feasible though...
WDYT?
Guillaume
Jerome.
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
* 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:11 a.m.
On Sep 18, 2009, at 10:38 AM, Jerome Velociter wrote:
Guillaume Lerouge wrote:
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.
Hi Asiri,
On Thu, Sep 17, 2009 at 1:09 PM, <oana.tabaranu(a)xwiki.com> wrote:
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). 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
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 -
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? 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 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
11:19 a.m.
Vincent Massol wrote:
On Sep 18, 2009, at 10:38 AM, Jerome Velociter wrote:
Well, custom JSON source is for tables that cannot fit in the generic case.
So I should have say instead : it's just not supported by the macro. If
that's what you meant, agreed we don't really need it even in future
versions.
Jerome.
Guillaume Lerouge wrote:
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. Hi Asiri,
On Thu, Sep 17, 2009 at 1:09 PM, <oana.tabaranu(a)xwiki.com> wrote:
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). 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
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:21 a.m.
Vincent Massol wrote:
On Sep 18, 2009, at 10:38 AM, Jerome Velociter wrote:
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.
Guillaume Lerouge wrote:
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.
Hi Asiri,
On Thu, Sep 17, 2009 at 1:09 PM, <oana.tabaranu(a)xwiki.com> wrote:
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). 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 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:47 p.m.
Hi,
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.
How about:
{{doclist ....}}
|(%field="doc.name" sort="true"%)Name
|(%field="doc.creator"%)Creator
|(%field="doc.tags"%)Tags
{{/doclist}}
Looks familiar :)
- Asiri
12:53 p.m.
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
10:41 a.m.
oana.tabaranu(a)xwiki.com 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
Yes, that could be the occasion to extend the JS API.
What events do you have in mind ?
Jerome.
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).
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:42 p.m.
oana.tabaranu(a)xwiki.com wrote:
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
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
Yes, that could be the occasion to extend the JS API.
What events do you have in mind ?
Jerome.
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).
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:31 p.m.
oana.tabaranu(a)xwiki.com wrote:
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.
oana.tabaranu(a)xwiki.com wrote:
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. 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
Yes, that could be the occasion to extend the JS API.
What events do you have in mind ?
Jerome.
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).
2) refresh() method
Redisplay the live table and the correct pagination when adding/deleting
files.
By files you mean entries ?
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:54 p.m.
oana.tabaranu(a)xwiki.com wrote:
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.
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
oana.tabaranu(a)xwiki.com wrote:
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. 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.
2) refresh() method
Redisplay the live table and the correct pagination when adding/deleting
files.
By files you mean entries ?
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> 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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5480
days inactive
5481
days old
14 comments
5 participants
participants (5)
-
Asiri Rathnayake -
Guillaume Lerouge -
Jerome Velociter -
oana.tabaranu＠xwiki.com -
Vincent Massol