On 2 Sep 2011, at 09:50, Jasha Joachimsthal wrote: > 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
The watcher script unpacks the widget, parses the definition and adds the metadata to the database. > > Jasha
