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