22 Jun
2010
22 Jun
'10
9:40 a.m.
On 06/22/2010 10:04 AM, Vincent Massol wrote:
Hi Anca,
On Jun 21, 2010, at 4:10 PM, Anca Luca wrote:
Hi all,
I am now restarting the work on the gadgets& dashboard project,
documented here
http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration (however
documentation needs to be slightly revised).
What is done already can be summarized as:
* gadgets are implemented as macros and there is a script to import
google gadgets as xwiki macros,
WDYM by script? Isn't there's simple a
{{gadget url="..."}} macro with a URL pointing to the gadget xml URL?
The initial approach was to _import_ gadgets as wiki macros. This has
the advantage that we can reuse tools from wiki macros and that gadgets
become more wiki syntax friendly:
{{clock width="50px"/}}
vs.
{{gadget url="http://gadgets.repository.com/misc/clock?width=50px"/}}
Marius
* also, right now, gadgets are implemented as
xwiki macros and can be
used anywhere just like a regular wiki macro, and any wiki macro can be
seen/used as a gadget so **there is no difference between macros and
gadgets** . WDYT about this? should we keep it like that? (A)
I think there are differences. One of them is the preferred size (width, height). IMO the
{{dashboard}} macro should only accept {{gadget}} macros (real open social gadgets) and
{{gadgetwrapper}} macros (wrapper around any wiki syntax), and for {{gadgetwrapper}} you
could specify additional metadata such as preferred width, height and whatever the
opensocial spec offers for gadgets.
Something like:
{{dashboard layout="..." ....}}
{{gadget.../}}
{{gadgetwrapper.../}}
...
{{/dashboard}}
As for transforming a given wiki page into an open social gadget we could have a Gadget
object you would add to a page and have a sheet that will generate the XML based on the
content + the metadata from that object. Then you could use it directly inside the
{{dashboard}} macro using a {{gadget url="url to the xwiki page which generates the
xml"}}.
If we think it's too much work to have both, then I would be for dropping the
{{gadgetwrapper}} macro and have only one {{gadget}} macro and force code to be put in
separate pages with a Gadget object attached. We would need to migrate Panels to gadgets
for this to work though, so introducing a {{gadgetwrapper}} is a nicer transition path
IMO.
* there is a dashboard macro responsible with
layouting a gadgets
dashboard, which also provides specific editing features in inline mode
(gadgets can be dragged around, toolboxes for gadgets in the top right)
* there is a minimal macros directory, where one can see all the
existing macros, descriptions, details about the parameters.
* there is an PanelMacro macro, that displays an xwiki panel inside a
document, which can be used to display xwiki panels as gadgets in a
dashboard.
The big picture of the roadmap is that we should:
1/ have a fully working dashboard, that is implement add gadget and edit
gadget settings
+1
2/ implement the main dashboard (Main.Dashboard)
as a dashboard and fill
it with the appropriate gadgets by default, and also to add a user
specific dashboard ("My dashboard") where each user can configure
his/her dashboard, and is available to a user from his / her profile or
the user menu
+1 with the ability for a user to decide if the home page displays the default dashboard
or his personal dashboard.
3/ have a nice macros directory where a user can
navigate through
existing gadgets and add one to a dashboard
+1
4/ have a "dashboard template",
integrated with the document templates
system to easily allow a user to create a dashboard
+1, and also add a Add Gadget template provider.
5/ also, since the xwiki panels can be seen as
gadgets / macros, and can
be implemented as such, somewhere in the future a refactoring should be
made to integrate the 2 notions
+1
6/ be able to publish the gadgets in the wiki
such that other apps can
integrate this in their content
That's the solution I've proposed above.
WDYT about the order above? (B) with the mention
that points 5 and 6
could eventually be infinitely postponed.
Whatever solution we choose we have to take 5 and 6 into account right now.
Also, after points 1 and 2 are implemented, the
feature could be
available with xwiki platform and integrated in XE by default. WDYT? (C)
+1 but provided we have a sound architecture that allows for 5 and 6.
Thanks
-Vincent
my +1 for (A), (B) and (C).
Happy hacking,
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs