You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by "Copeland, Bryan" <Br...@nrc-cnrc.gc.ca> on 2009/12/07 17:41:46 UTC
Wookie as a Widget plugin
Hi all,
I believe the image on the incubator landing page provides an excellent
overview of how Wookie would ideally fit into existing projects as a
W3C-compatible widget plugin:
http://incubator.apache.org/wookie/
Do any instructions exist on how to configure Wookie specifically
following this paradigm? If not I would be willing to contribute in this
area, with a little guidance.
So far I don't really know where to start except for browsing the SVN in
a new project, and compiling Wookie as a standalone Widget container
unto itself. In this method though, Wookie and "your application" are
one and the same. I suppose the next step would be to build the JAR
outputs and include that in my own web application, but it's not exactly
clear how to bring it in to a project which already has its own
definitions (DB, schema, handlers, etc) for a more basic type of widget.
Should I:
- scrap my application's concept of a widget and add Wookie to
the Build Path as a .jar, pointing to the new Widget objects instead
- bridge Wookie's widget system via the REST API and each
project running separately in the same Tomcat container
- or, simply use specific components of Wookie such as the W3C
Widget processing logic?
I guess in the end the answer is whatever works... but if there's any
documentation which provides more details or starting points please let
me know, and I can enhance those or just separately document my attempts
to use Wookie as a true Widget management plugin...
Thanks,
Bryan Copeland
(The best I can find
http://incubator.apache.org/wookie/wookie-plugin-developers-guide.html
seems to be incomplete with some headers not yet filled in, this is
precisely a place where I think I can help as I'd like to test a full
Wookie integration)
Re: Wookie as a Widget plugin
Posted by Scott Wilson <sc...@gmail.com>.
On 7 Dec 2009, at 17:05, Hugh Barnard wrote:
> Hi Bryan
>
> A lot of these are my current concerns, so I'll just add a little
> commentary on what I'm after (I could call it a use case, but that's a
> little precise for something that's a rather vague) into this...
>>
>> Do any instructions exist on how to configure Wookie specifically
>> following this paradigm? If not I would be willing to contribute in
>> this
>> area, with a little guidance.
>
> That would help me, I want to use the wookie server to provide widgets
> into an instance of Elgg via the plugin (which probably needs
> reviewing, I may do some of that). My 'goal' is ubi-widgets, ones that
> will work for my application on phones and via wookie connectors,
> looking the same. That may be unrealistic and over ambitious.
I think within a certain scope (i.e. feature set) its actually looking
doable. The convergence of W3C Widgets, W3C DAP and BONDI is helpful
here
> So far I don't really know where to start except for browsing the
> SVN in
>> a new project, and compiling Wookie as a standalone Widget container
>> unto itself.
>
> Yes, currently I'm there, wrestling a little with the connection
> between the wookie server, widget development and making the server
> 'serve'. I'm a beginner for widgets, so I don't expect instant
> enlightement...
>
> In this method though, Wookie and "your application" are
>> one and the same. I suppose the next step would be to build the JAR
>> outputs and include that in my own web application, but it's not
>> exactly
>> clear how to bring it in to a project which already has its own
>> definitions (DB, schema, handlers, etc) for a more basic type of
>> widget.
>> Should I:
>>
>> - scrap my application's concept of a widget and add
>> Wookie to
>> the Build Path as a .jar, pointing to the new Widget objects instead
>
> Yes, see above, Elgg already has its own style of widgets, these are
> basically php constructed mini-views and they won't 'go' anywhere else
> (phones, browsers etc.) hence a large part of my interest.
Yes, all the plugins we've made so far build on these existing
mechanisms, as a lot of the local plumbing is already in place. E.g.
for Elgg the plugin that Bernhard has been working on at Elgg extends
the built-in "widget" mechanism by calling the Wookie REST API.
((I had an email exchange with Dave Tosh a few weeks ago and he was
interested in how they could work with Wookie - perhaps you and
Bernhard would like to follow that up?))
>> - bridge Wookie's widget system via the REST API and each
>> project running separately in the same Tomcat container
>
> That'll probably be easier than what I have in mind! I'm interested in
> extending the reach of current stuff by presenting bits of it as a
> widget(s)
>
> Incidentally, Scott, now I've revealed what I'm up to, please tell me
> whether it's sensible or fairly silly. I can take it!
Building simultaneously for web, mobile (and desktop) using W3C
Widgets looks like a sensible development path for apps, with
eventually more reach than the current iPhone and Android app stores.
> Best regards Hugh
>
> --
> http://www.hughbarnard.org
> http://www.big-wave-heuristics.com/
>
> http://www.hackney-environment-network.org.uk/
Re: Wookie as a Widget plugin
Posted by Hugh Barnard <hu...@googlemail.com>.
Hi Bryan
A lot of these are my current concerns, so I'll just add a little
commentary on what I'm after (I could call it a use case, but that's a
little precise for something that's a rather vague) into this...
>
> Do any instructions exist on how to configure Wookie specifically
> following this paradigm? If not I would be willing to contribute in this
> area, with a little guidance.
That would help me, I want to use the wookie server to provide widgets
into an instance of Elgg via the plugin (which probably needs
reviewing, I may do some of that). My 'goal' is ubi-widgets, ones that
will work for my application on phones and via wookie connectors,
looking the same. That may be unrealistic and over ambitious.
>
> So far I don't really know where to start except for browsing the SVN in
> a new project, and compiling Wookie as a standalone Widget container
> unto itself.
Yes, currently I'm there, wrestling a little with the connection
between the wookie server, widget development and making the server
'serve'. I'm a beginner for widgets, so I don't expect instant
enlightement...
In this method though, Wookie and "your application" are
> one and the same. I suppose the next step would be to build the JAR
> outputs and include that in my own web application, but it's not exactly
> clear how to bring it in to a project which already has its own
> definitions (DB, schema, handlers, etc) for a more basic type of widget.
> Should I:
>
> - scrap my application's concept of a widget and add Wookie to
> the Build Path as a .jar, pointing to the new Widget objects instead
Yes, see above, Elgg already has its own style of widgets, these are
basically php constructed mini-views and they won't 'go' anywhere else
(phones, browsers etc.) hence a large part of my interest.
> - bridge Wookie's widget system via the REST API and each
> project running separately in the same Tomcat container
That'll probably be easier than what I have in mind! I'm interested in
extending the reach of current stuff by presenting bits of it as a
widget(s)
Incidentally, Scott, now I've revealed what I'm up to, please tell me
whether it's sensible or fairly silly. I can take it!
Best regards Hugh
--
http://www.hughbarnard.org
http://www.big-wave-heuristics.com/
http://www.hackney-environment-network.org.uk/
Re: Wookie as a Widget plugin
Posted by Scott Wilson <sc...@gmail.com>.
On 8 Dec 2009, at 10:53, Ate Douma wrote:
> Hi all,
>
> I just want to provide my 2c on Wookie Widget integration.
>
> As you might know, I'm (foremost) working on portal solutions,
> Apache Jetspeed-2 particular.
> Our interest in Wookie is eventually come to a full (100%)
> integration *within* the portal server itself, serving both
> "standard" portlets and Widgets (Wookie, Open Social, Google Wave,
> etc.) transparently side-by-side, including the capability to
> "coordinate" and communicate with each other (any ideas anyone about
> for instance AjaxHub or some other client-side level integration and
> coordination ...?).
Loads of ideas over at: http://groups.google.com/group/talk-about-widgets
e.g. http://groups.google.com/group/talk-about-widgets/web/use-cases-for-iwc
So far possibilities are:
Ajax Hub
PUSHH
Server-side events/listeners
HTML 5 Messaging
HTML 5 Drag n Drop (see e.g. http://zope.cetis.ac.uk/members/scott/blogview?entry=20090623135357)
Ivan Zuzak was compiling a big list/comparison of all these...
Also if you look back in the list archive Allar Tammik asked about
this too on 28th November.
> To make this happen, we'll try to "wrap" Wookie Widgets as portlets,
> while hooking them onto our portal server back-end (users,
> preferences, any kind of coordination data, etc.).
>
> I'm still not familiar enough with the code base, but overtime I
> suppose I will :)
> What I'd like to see though is being able to use Wookie Server as
> modular engine with enough abstractions in place to be able to
> delegate infrastructural features, such like our portal, without
> needing to touch the engine logic itself.
Right, so we need to get the core logic buildable as a jar. I guess
the question then is what is left in and what is taken out..?
> For now, the REST API is already working nicely to allow "bridging"
> our portal users with Wookie, but this still uses Wookie Server
> (including back-end storage) separated. NB: that is a use-case we
> always also will need, to allow integration of remote (Wookie)
> Widgets as well.
Indeed; multiple Wookie servers/app stores (e.g. within an enterprise
and public external) would seem to be a reasonable case to cover.
> Yesterday evening I gave a demonstration at Cap Gemini (Javanight)
> in the Netherlands for my company in which I showed a few Wookie
> Widgets nicely "integrated" in a Portal, like the Google Wave
> Sudoku, Chat and Natter Widget all using the current Portal user and
> its preferences (like Participant thumbnail etc.)
Cool! What did they think to it?
> For who's interested, the still overly simplistic and quick-and-
> dirty coded example WookieWidgetPortlet "plugin" I used for this is
> accessible online here:
>
> http://svn.hippocms.org/viewvc/hippo-collab/trunk/wiki/src/main/java/org/onehippo/portal/collab/wookie/WookieWidgetPortlet.java/?revision=21027&view=markup
Nice - I see you've followed pretty much the same pattern as in all
the other plugins, have to make sure this is documented in http://cwiki.apache.org/WOOKIE/wookie-plugin-developers-guide.html
>
> This is currently stored in my company svn repo, but with the
> intention to contribute back to Apache.
> I might bring this in under Apache Portals, once its more complete,
> less dependent on hard-coded path mappings and has some more
> features, like maybe a Gallery picker to "switch" selected Widget.
> Alternatively, and if there is interest for this, it might also be
> useful to bring this to Wookie svn itself too as a example Portlet
> plugin usage (its already ASL 2.0 licensed and 100% portlet spec
> only, not dependent on any specific portal like for instance
> Jetspeed-2 itself).
I think either option works - some plugins are hosted by the container
app project, but we can also host within Wookie. The main thing is we
provide links so that the users can find them (I've added links to the
existing plugins on the main page now)
>
> Regards,
>
> Ate
>
> Scott Wilson wrote:
>> Hi Bryan!
>> On 7 Dec 2009, at 16:41, Copeland, Bryan wrote:
>>> Hi all,
>>>
>>> I believe the image on the incubator landing page provides an
>>> excellent
>>> overview of how Wookie would ideally fit into existing projects as a
>>> W3C-compatible widget plugin:
>>>
>>> http://incubator.apache.org/wookie/
>>>
>>> Do any instructions exist on how to configure Wookie specifically
>>> following this paradigm? If not I would be willing to contribute
>>> in this
>>> area, with a little guidance.
>> There is a starting point for this here, which I see you'd already
>> spotted:
>> http://incubator.apache.org/wookie/wookie-plugin-developers-
>> guide.html
>> ... but it could certainly do with some improvement!
>>> So far I don't really know where to start except for browsing the
>>> SVN in
>>> a new project, and compiling Wookie as a standalone Widget container
>>> unto itself. In this method though, Wookie and "your application"
>>> are
>>> one and the same. I suppose the next step would be to build the JAR
>>> outputs and include that in my own web application, but it's not
>>> exactly
>>> clear how to bring it in to a project which already has its own
>>> definitions (DB, schema, handlers, etc) for a more basic type of
>>> widget.
>>> Should I:
>>>
>>> - scrap my application's concept of a widget and add
>>> Wookie to
>>> the Build Path as a .jar, pointing to the new Widget objects instead
>>>
>>> - bridge Wookie's widget system via the REST API and each
>>> project running separately in the same Tomcat container
>>>
>>> - or, simply use specific components of Wookie such as
>>> the W3C
>>> Widget processing logic?
>> I'd got for the second option myself; that's certainly how we've
>> tended to envisage it. Note however that you don't need to run your
>> app in the same servlet container (or indeed be using Java). There
>> are some plugins for other applications here:
>> http://getwookie.org/Plugins.html
>> Some of the implementation patterns could be gleaned from these
>> existing plugins.
>> (we could probably do with putting these links in the project wiki,
>> too)
>>> I guess in the end the answer is whatever works...
>> Indeed :-)
>>> but if there's any
>>> documentation which provides more details or starting points
>>> please let
>>> me know, and I can enhance those or just separately document my
>>> attempts
>>> to use Wookie as a true Widget management plugin...
>> If you can enhance the plugin guide then that would be fantastic.
>> If you need help with anything, just ask.
>>> Thanks,
>>>
>>> Bryan Copeland
>>>
>>> (The best I can find
>>> http://incubator.apache.org/wookie/wookie-plugin-developers-guide.html
>>> seems to be incomplete with some headers not yet filled in, this is
>>> precisely a place where I think I can help as I'd like to test a
>>> full
>>> Wookie integration)
>
Re: Wookie as a Widget plugin
Posted by Ate Douma <at...@douma.nu>.
Hi all,
I just want to provide my 2c on Wookie Widget integration.
As you might know, I'm (foremost) working on portal solutions, Apache Jetspeed-2 particular.
Our interest in Wookie is eventually come to a full (100%) integration *within* the portal server itself, serving both "standard" portlets
and Widgets (Wookie, Open Social, Google Wave, etc.) transparently side-by-side, including the capability to "coordinate" and communicate
with each other (any ideas anyone about for instance AjaxHub or some other client-side level integration and coordination ...?).
To make this happen, we'll try to "wrap" Wookie Widgets as portlets, while hooking them onto our portal server back-end (users, preferences,
any kind of coordination data, etc.).
I'm still not familiar enough with the code base, but overtime I suppose I will :)
What I'd like to see though is being able to use Wookie Server as modular engine with enough abstractions in place to be able to delegate
infrastructural features, such like our portal, without needing to touch the engine logic itself.
For now, the REST API is already working nicely to allow "bridging" our portal users with Wookie, but this still uses Wookie Server
(including back-end storage) separated. NB: that is a use-case we always also will need, to allow integration of remote (Wookie) Widgets as
well.
Yesterday evening I gave a demonstration at Cap Gemini (Javanight) in the Netherlands for my company in which I showed a few Wookie Widgets
nicely "integrated" in a Portal, like the Google Wave Sudoku, Chat and Natter Widget all using the current Portal user and its preferences
(like Participant thumbnail etc.)
For who's interested, the still overly simplistic and quick-and-dirty coded example WookieWidgetPortlet "plugin" I used for this is
accessible online here:
http://svn.hippocms.org/viewvc/hippo-collab/trunk/wiki/src/main/java/org/onehippo/portal/collab/wookie/WookieWidgetPortlet.java/?revision=21027&view=markup
This is currently stored in my company svn repo, but with the intention to contribute back to Apache.
I might bring this in under Apache Portals, once its more complete, less dependent on hard-coded path mappings and has some more features,
like maybe a Gallery picker to "switch" selected Widget.
Alternatively, and if there is interest for this, it might also be useful to bring this to Wookie svn itself too as a example Portlet plugin
usage (its already ASL 2.0 licensed and 100% portlet spec only, not dependent on any specific portal like for instance Jetspeed-2 itself).
Regards,
Ate
Scott Wilson wrote:
> Hi Bryan!
>
> On 7 Dec 2009, at 16:41, Copeland, Bryan wrote:
>
>> Hi all,
>>
>> I believe the image on the incubator landing page provides an excellent
>> overview of how Wookie would ideally fit into existing projects as a
>> W3C-compatible widget plugin:
>>
>> http://incubator.apache.org/wookie/
>>
>> Do any instructions exist on how to configure Wookie specifically
>> following this paradigm? If not I would be willing to contribute in this
>> area, with a little guidance.
>
> There is a starting point for this here, which I see you'd already spotted:
>
> http://incubator.apache.org/wookie/wookie-plugin-developers-guide.html
>
> ... but it could certainly do with some improvement!
>
>
>> So far I don't really know where to start except for browsing the SVN in
>> a new project, and compiling Wookie as a standalone Widget container
>> unto itself. In this method though, Wookie and "your application" are
>> one and the same. I suppose the next step would be to build the JAR
>> outputs and include that in my own web application, but it's not exactly
>> clear how to bring it in to a project which already has its own
>> definitions (DB, schema, handlers, etc) for a more basic type of widget.
>> Should I:
>>
>> - scrap my application's concept of a widget and add Wookie to
>> the Build Path as a .jar, pointing to the new Widget objects instead
>>
>> - bridge Wookie's widget system via the REST API and each
>> project running separately in the same Tomcat container
>>
>> - or, simply use specific components of Wookie such as the W3C
>> Widget processing logic?
>
> I'd got for the second option myself; that's certainly how we've tended
> to envisage it. Note however that you don't need to run your app in the
> same servlet container (or indeed be using Java). There are some plugins
> for other applications here:
>
> http://getwookie.org/Plugins.html
>
> Some of the implementation patterns could be gleaned from these existing
> plugins.
>
> (we could probably do with putting these links in the project wiki, too)
>
>> I guess in the end the answer is whatever works...
>
> Indeed :-)
>
>> but if there's any
>> documentation which provides more details or starting points please let
>> me know, and I can enhance those or just separately document my attempts
>> to use Wookie as a true Widget management plugin...
>
> If you can enhance the plugin guide then that would be fantastic. If you
> need help with anything, just ask.
>
>> Thanks,
>>
>> Bryan Copeland
>>
>> (The best I can find
>> http://incubator.apache.org/wookie/wookie-plugin-developers-guide.html
>> seems to be incomplete with some headers not yet filled in, this is
>> precisely a place where I think I can help as I'd like to test a full
>> Wookie integration)
>
Re: Wookie as a Widget plugin
Posted by Scott Wilson <sc...@gmail.com>.
Hi Bryan!
On 7 Dec 2009, at 16:41, Copeland, Bryan wrote:
> Hi all,
>
> I believe the image on the incubator landing page provides an
> excellent
> overview of how Wookie would ideally fit into existing projects as a
> W3C-compatible widget plugin:
>
> http://incubator.apache.org/wookie/
>
> Do any instructions exist on how to configure Wookie specifically
> following this paradigm? If not I would be willing to contribute in
> this
> area, with a little guidance.
There is a starting point for this here, which I see you'd already
spotted:
http://incubator.apache.org/wookie/wookie-plugin-developers-guide.html
... but it could certainly do with some improvement!
> So far I don't really know where to start except for browsing the
> SVN in
> a new project, and compiling Wookie as a standalone Widget container
> unto itself. In this method though, Wookie and "your application" are
> one and the same. I suppose the next step would be to build the JAR
> outputs and include that in my own web application, but it's not
> exactly
> clear how to bring it in to a project which already has its own
> definitions (DB, schema, handlers, etc) for a more basic type of
> widget.
> Should I:
>
> - scrap my application's concept of a widget and add Wookie
> to
> the Build Path as a .jar, pointing to the new Widget objects instead
>
> - bridge Wookie's widget system via the REST API and each
> project running separately in the same Tomcat container
>
> - or, simply use specific components of Wookie such as the
> W3C
> Widget processing logic?
I'd got for the second option myself; that's certainly how we've
tended to envisage it. Note however that you don't need to run your
app in the same servlet container (or indeed be using Java). There are
some plugins for other applications here:
http://getwookie.org/Plugins.html
Some of the implementation patterns could be gleaned from these
existing plugins.
(we could probably do with putting these links in the project wiki, too)
> I guess in the end the answer is whatever works...
Indeed :-)
> but if there's any
> documentation which provides more details or starting points please
> let
> me know, and I can enhance those or just separately document my
> attempts
> to use Wookie as a true Widget management plugin...
If you can enhance the plugin guide then that would be fantastic. If
you need help with anything, just ask.
> Thanks,
>
> Bryan Copeland
>
> (The best I can find
> http://incubator.apache.org/wookie/wookie-plugin-developers-guide.html
> seems to be incomplete with some headers not yet filled in, this is
> precisely a place where I think I can help as I'd like to test a full
> Wookie integration)