Mailing-List: contact wookie-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: wookie-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 scott.bradley.wilson@gmail.com designates 74.125.82.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:mime-version:content-type:subject:date:in-reply-to:to
         :references:message-id:x-mailer;
        b=v/PyBU62lXP91hTGZNEYLY30yc5uYlta27n7r0Q1W4jQ7mGqTXBdyPV8DqWfRtnKtT
         JTpAN+StI8MxiYG1Y8eL+IkIsFSnXbADxJ6iaR/hiqL0tNjKEB+CZgyEuuJAAwk/IPRS
         BkXPtYE2NEwsxAcibgjcxuP9usZa0pl9CnhCc=
From: Scott Wilson <scott.bradley.wilson@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-19-382741768
Subject: Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Date: Wed, 11 May 2011 10:50:56 +0100
In-Reply-To: <4DCA5681.4010405@apache.org>
To: wookie-dev@incubator.apache.org
References: <4DC9571D.8080100@apache.org>
 <BANLkTik0TKBFnbVVdVpvvGuHewKFewpxYw@mail.gmail.com>
 <4DCA5681.4010405@apache.org>
Message-Id: <685EF94A-9CFF-4F00-AEE2-E0882689DED7@gmail.com>

--Apple-Mail-19-382741768
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


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

> On 11/05/2011 09:25, Steve Lee wrote:
>=20
>> 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.
>=20
> Naturally. I'm proposing that Rave become the official reference =
implementation of a UI for Wookie. Our site would reflect this =
accordingly.
>=20
>>> 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.
>>=20
>> 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....
>=20
> 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).
>=20
>>> Proposal
>>> =3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
> 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.
>=20
> e.g. wookie instantiate [WIDGET_ID] [PROPERTIES] --view

>=20
>>> 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.)
>>=20
>> 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
>=20
> Sure we can provide JSON too - we look forward to your patch or and =
XSLT to convert XML to JSON, e.g.
>=20
> wookie listWidgets [PROPERTIES] --transform=3DtoJSON.xslt
>=20
> or
>=20
> wookie listWidgets [PROPERTIES] --output=3DJSON


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=3Djson" or =
whatever.

e.g. in the WARP controller:

		switch (format(request)) {
			case XML: =
returnXml(AccessRequestHelper.createXMLAccessRequestDocument(accessRequest=
s),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)

>=20
>>> 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.
>>=20
>> +1
>=20
> Thanks for your comments.
>=20
> Ross
>=20
>>=20
>> 1: http://straight-street.com/api/
>=20


--Apple-Mail-19-382741768--