incubator-wookie-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Wilson <scott.bradley.wil...@gmail.com>
Subject Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Date Wed, 11 May 2011 09:50:56 GMT

On 11 May 2011, at 10:27, Ross Gardler wrote:

> On 11/05/2011 09:25, Steve Lee wrote:
> 
>> One thought is that in order to ease evaluation by new users/devs a
>> global installer would be be useful, or at least clear signposting
>> between the projects.
> 
> Naturally. I'm proposing that Rave become the official reference implementation of a
UI for Wookie. Our site would reflect this accordingly.
> 
>>> Wookie is focussed on providing a server based environment for the hosting
>>> of Widgets and Gadgets. It provides the necessary infrastructure for clients
>>> to request a widget/gadget instance (or a wgt package if appropriate). It
>>> also provides a persistence layer so that widgets/gadgets can store
>>> preference values. Wookie does not concern itself with the rendering of
>>> those widgets/gadgets.
>> 
>> I may be getting confused but doesn't Wookie also implement Wave APIs
>> - do these really belong there as well? But that's another
>> discussion....
> 
> I'm not sure where "there" is. I don't think it is important for this proposal which
is only concerned with UI. However, for completeness, I believe the Wave integration we currently
have belongs here. In the long term we should consider adopting Apache Wave for this rather
than the partial local implementation we currently have. However, there is currently no use
case so lets stay focussed (for reference Rave has Wave features on its long term objectives
list so a relationship with the Rave community now would be a good thing in the future too).
> 
>>> Proposal
>>> ========
>>> 
>>> Wookie should deprecate all UI code and provide integration with Rave,
>>> thereby allowing Rave to host W3C Widgets as well as OpenSocial gadgets. Our
>>> UI will no longer be interactive. All administration activities will be
>>> carried out via a command line application, interfacing with Wookie via the
>>> REST API.
>> 
>> Util now Wookie has required simple UI to allow basic evaluation
>> testing and developing. If these functions move to another project, I
>> would suggest that stand-alone unit tests would still be required at a
>> minimum, and perhaps a simple demo. It seems much of this could be
>> done with some mock widgets and the command line / REST access.
> 
> I'm saying *no* UI code. Wookie becomes a library. The moment we start bringing UI code
back in for any reason we start to blur the lines.
> 
> Testing is not a problem (in fact it is simplified) and instructions for instantiating
a widget  and viewing it in  browser would be just a few lines long. In fact there is no reason
why the CLI couldn't optionally fire up a browser when a widget is instantiated.
> 
> e.g. wookie instantiate [WIDGET_ID] [PROPERTIES] --view

> 
>>> We may choose to provide text based output from this API, although
>>> I would suggest an XSL transformation of the XML responses from the API
>>> would be most appropriate as this will allow data to be retrieved in
>>> multiple formats (CSV, text, HTML etc.)
>> 
>> That sounds good. However without getting too sidetracked JSON does
>> provide easy consumption in many cases (but might not be appropriate
>> here). For the straight-street.com API [1] I ended up serving JSON
>> mime type with minimal formating to ease reading. using the Firefox
>> JSONView plug makes it pretty and then interacting and exploring is
>> really easy through the hyperlinks
> 
> Sure we can provide JSON too - we look forward to your patch or and XSLT to convert XML
to JSON, e.g.
> 
> wookie listWidgets [PROPERTIES] --transform=toJSON.xslt
> 
> or
> 
> wookie listWidgets [PROPERTIES] --output=JSON


Currently In the Controller class there is content-type support, it just requires for each
Controller method that returns a representation that you implement a serializer in its respective
Helper class. To get the different views you either send a content-type header in the request,
or if you can't for some reason you can also add "?format=json" or whatever.

e.g. in the WARP controller:

		switch (format(request)) {
			case XML: returnXml(AccessRequestHelper.createXMLAccessRequestDocument(accessRequests),response);break;
			case HTML: returnHtml(AccessRequestHelper.createAccessRequestHTMLTable(accessRequests),response);break;
			case JSON: returnJson(AccessRequestHelper.createJSON(accessRequests),response);break;
		}


And in the whitelist controller:

		switch (format(request)) {
			case XML: returnXml(WhitelistHelper.createXMLDocument(entries),response);break;
			case JSON: returnHtml(WhitelistHelper.createJSON(entries),response);break;
			case HTML: returnHtml(WhitelistHelper.createHTML(entries),response);break;
		}

(Going with Ross's proposal we'd remove the HTML option, or wire it to return XML with an
XSLT)

> 
>>> We should offer all UI code in Wookie to Rave as a starting point for their
>>> "Gadget Store". I imagine that the majority of this code will be re-written
>>> by the Rave team to suit their local needs. However, I also imagine that the
>>> work they do will greatly enhance the work we have done here and, for those
>>> people who need a stand alone administration UI for Wookie we can point them
>>> towards Rave.
>> 
>> +1
> 
> Thanks for your comments.
> 
> Ross
> 
>> 
>> 1: http://straight-street.com/api/
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message