18 Sep
2009
18 Sep
'09
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