On 2 September 2011 10:17, Scott Wilson <[email protected]>wrote:

>
> On 2 Sep 2011, at 07:17, Jasha Joachimsthal wrote:
>
> > On 1 September 2011 20:04, Marlon Pierce <[email protected]> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hi all--
> >>
> >> Ankur Goyal has compiled a list of gadgets (mostly simple) from the OGCE
> >> Gadget Container that can be ported straightforwardly into Rave.  These
> >> include some useful ones (facebook, gmail clients, google talk) and some
> >> that at least have instructive potential.  Do we want to include these
> in
> >> Rave trunk?  If so, where? For simplicity and reliability, I suggest
> these
> >> be deployed into the Rave tomcat server under new webapp
> ("demo-gadgets").
> >>
> >
> > Hosting our own widgets is a very useful addition to the portal. You can
> add
> > them as static resources, but why don't we add them to the existing
> database
> > of the portal? We can either extend the existing Widget bean with fields
> to
> > contain the actual definition, thumbnail and screenshot. Or we split up
> the
> > current Widget bean: a widget that is hosted by a 3rd party and a widget
> we
> > host ourselves. Just like we have a form to add a new externally hosted
> > widget, we can have a form to add a new widget we want to host from the
> > portal with different fields because administrators should be able to
> > upload/paste the images and widget definition.
> > Then you don't need a new webapp for only hosting our own widgets.
>
> In Wookie we have a "deploy" folder where we drop packaged W3C Widgets
> (.wgt) files to deploy them - this means we can have collections of widgets
> in the project that we can deploy during the build process by copying the
> files with an Ant task. (No forms required)
>
> For OpenSocial gadgets, can you use a similar process? So package up the
> gadget's resources and XML descriptor in a zip and drop it into a watched
> location for Rave to unpack and host locally?
>
>
You could build that but why wouldn't you store this information in the
database? Then you can do runtime CRUD operations on the widget through a
management interface. We can create urls that follow a pattern to return the
widget definition, image etc.
Just my €0.02

Jasha

Reply via email to