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/
>
