22 Jun
2010
22 Jun
'10
7:22 p.m.
On 06/22/2010 08:03 PM, Vincent Massol wrote:
width & height == dashboard css
title = could not exist, it's the macros responsibility what it displays
in its box (as it's implemented right now on the incubator). Why would
it have to be controlled at dashboard level?
Thanks,
Anca
On Jun 22, 2010, at 6:59 PM, Anca Luca wrote:
Why? why not any macro?
Why just macros? Why not any wiki syntax? I don't understand why you'd restrict
it to macros?
The question here is if we want to have generic stuff with generic
parameters, such as:
{{gadgetwrapper width="" height="" title=""}}
dishwashing wiki code here
{{/gadgetwrapper}}
in which case when editing the settings you'd make the users edit the
generic params and when you want to customize the dishwashing gadget
you'd have to edit content,
or provide (actually make developers provide):
{{dishwashing numberofdishes="" detergentbrand="" ... }}
maybe some code here
{{/dishwashing}}
in which case editing this gadget's settings would be about customizing
the gadget itself, not about generic customizing.
I'd go for second option, since it also allows first option, whereas the
reverse does not hold.
This is also in the spirit of importing google gadgets as macros instead
of using just one macro with xml as param.
Hi Vincent,
On 06/22/2010 10:04 AM, Vincent Massol wrote:
Ok I'll need some time to read this.
Hi Anca,
On Jun 21, 2010, at 4:10 PM, Anca Luca wrote:
See this thread http://markmail.org/message/f4gclxpff74vzu6t from around
the place where I linked. That is a discussion around this design page
http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HProposal2-Mul…
from which the option which I anchored to was used. 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. such that the dashboard is only about layouting,
and attaching the appropriate js to do drag& drop, edits in place, etc.
How do you specify the width and height + other gadget metadata (title, etc)?
Thanks
-Vincent
I think in this way we would be able to have
easier integration of the
xwiki content in the xwiki dashboard.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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"}}.
yes, the idea is to use xwiki structured data to specify such a gadget,
and then automatically generate the open soc gadget XML from that.
Jerome, what do you think of this approach?
So as I see it there are 2 approaches to this:
1/ make xwiki an open social container working only with open social
gadgets only and providing a mean to use xwiki content/macros in such a
gadget
2/ have xwiki gadgets& dashboard work with macros and provide ways to
import an OS gadget in an xwiki macro and export an xwiki macro as an
open social gadget.
We could discuss here pros and cons.
WDYT?
Thanks,
Anca
>
> 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