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?

> * 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
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to