You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Scott Wilson <sc...@gmail.com> on 2012/03/29 15:31:09 UTC
Wookie without a UI: are we there yet?
Hi everyone,
We've now removed the UI client from trunk, the only UI now is a HTML-only demo that lets you preview widgets (thanks Ross for the improvements to this - I like the filter especially!)
The UI functions are now represented in the REST API, and for the most part by other methods.
Kris has also been adding more functions to the Java connector framework to cover the admin APIs as well as handling instances, so this means the connector framework can eventually be used as the basis of an admin client. (See WOOKIE-326)
Here's the state of play:
Widgets
======
Drop into /deploy folder, or use REST API. The only function not supported outside of the REST API is deleting widgets.
Widget Instances, Properties and Participants
===================================
Use connector framework or REST API
API Keys
=======
Edit the /classes/policies file, or use REST API.
Policies
======
Edit the /classes/keys file, or use REST API.
The question I have is: is this sufficient to consider WOOKIE-262 completed?
If so, I'll get on with sorting out the remaining documentation so I can close WOOKIE-19 & WOOKIE-15.
S
Re: Wookie without a UI: are we there yet?
Posted by Ross Gardler <rg...@opendirective.com>.
On 29 March 2012 14:52, Paul Sharples <p....@bolton.ac.uk> wrote:
> On 29/03/2012 14:39, Ross Gardler wrote:
>>
>> On 29 March 2012 14:31, Scott Wilson<sc...@gmail.com>
>> wrote:
>>>
>>> Hi everyone,
>>>
>>> We've now removed the UI client from trunk, the only UI now is a
>>> HTML-only demo that lets you preview widgets (thanks Ross for the
>>> improvements to this - I like the filter especially!)
>>
>> I'd like to turn the navigation part into a widget, that shouldn't be
>> hard the way it is currently implemented. Just need to find a little
>> time to do it. This is *not* a blocker though. It is one more step
>> towards extracting all the UI functionality out of core.
>>
>>> Widgets
>>> ======
>>> Drop into /deploy folder, or use REST API. The only function not
>>> supported outside of the REST API is deleting widgets.
>>
>> So how do we delete a widget in a running instance of Wookie? Seems
>> like a necessary feature (but not a blocker).
>
>
> I presume you'd use the RESTAPI - see
> org.apache.wookie.tests.functional.WidgetControllerTest for an example.
Yes, sorry I misread Scotts original mail.
>>> The question I have is: is this sufficient to consider WOOKIE-262
>>> completed?
...
> I guess this probably covers it. If we find anything else we've missed then
> we can open a new issue for it (more specific)
> The only other thing is that WOOKIE-262 also mentions a command line
> management utility (is this a provided .bat and .sh script?)
+1
>
> Paul
>
>>
>>> If so, I'll get on with sorting out the remaining documentation so I can
>>> close WOOKIE-19& WOOKIE-15.
>>
>> This email is a good start for FAQ documentation.
>>
>> Ross
>>
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Wookie without a UI: are we there yet?
Posted by Scott Wilson <sc...@gmail.com>.
On 29 Mar 2012, at 15:31, Kris Popat wrote:
>
> On 29 Mar 2012, at 15:06, Paul Sharples wrote:
>
>> On 29/03/2012 15:03, Scott Wilson wrote:
>>> On 29 Mar 2012, at 14:52, Paul Sharples wrote:
>>>
>>>> On 29/03/2012 14:39, Ross Gardler wrote:
>>>>> On 29 March 2012 14:31, Scott Wilson<sc...@gmail.com> wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> We've now removed the UI client from trunk, the only UI now is a HTML-only demo that lets you preview widgets (thanks Ross for the improvements to this - I like the filter especially!)
>>>>> I'd like to turn the navigation part into a widget, that shouldn't be
>>>>> hard the way it is currently implemented. Just need to find a little
>>>>> time to do it. This is *not* a blocker though. It is one more step
>>>>> towards extracting all the UI functionality out of core.
>>>>>
>>>>>> Widgets
>>>>>> ======
>>>>>> Drop into /deploy folder, or use REST API. The only function not supported outside of the REST API is deleting widgets.
>>>>> So how do we delete a widget in a running instance of Wookie? Seems
>>>>> like a necessary feature (but not a blocker).
>>>> I presume you'd use the RESTAPI - see org.apache.wookie.tests.functional.WidgetControllerTest for an example.
>>> To be honest I can't think of another way to do it. You could watch the unpacked widget folder, and if it vanishes trigger a delete, but that bothers me a bit as it may not be the intention, and deleting widgets has lots of side-effects (deleting related instances, preferences).
>>
>> Agreed, I don't think thats a good way to go.
>
> Should I add it to the connector?
Yep, that would be useful.
> Or perhaps we could enable/disable widgets or make them invisible or similar?
Could be a good idea - so not deleting anything, just not returning anything. That might work. Then again I can see something like that also implemented a layer up in things like Rave?
>
>>
>>>
>>>>>> The question I have is: is this sufficient to consider WOOKIE-262 completed?
>>>>> I'm happy to close it and add a new lower priority issue on the delete
>>>>> widget requirement above. Also happy to lower the priority with the
>>>>> delete widget requirement remaining in the original issue.
>>>> I guess this probably covers it. If we find anything else we've missed then we can open a new issue for it (more specific)
>>>> The only other thing is that WOOKIE-262 also mentions a command line management utility (is this a provided .bat and .sh script?)
>>> That was the original intention - but maybe thats not needed now?
>>
>> We could just open a new issue for it and give it a lower priority.
>>
>>>> Paul
>>>>
>>>>>> If so, I'll get on with sorting out the remaining documentation so I can close WOOKIE-19& WOOKIE-15.
>>>>> This email is a good start for FAQ documentation.
>>>>>
>>>>> Ross
>>>>>
>>>
>>
>
Re: Wookie without a UI: are we there yet?
Posted by Kris Popat <kj...@gmail.com>.
On 29 Mar 2012, at 15:06, Paul Sharples wrote:
> On 29/03/2012 15:03, Scott Wilson wrote:
>> On 29 Mar 2012, at 14:52, Paul Sharples wrote:
>>
>>> On 29/03/2012 14:39, Ross Gardler wrote:
>>>> On 29 March 2012 14:31, Scott Wilson<sc...@gmail.com> wrote:
>>>>> Hi everyone,
>>>>>
>>>>> We've now removed the UI client from trunk, the only UI now is a HTML-only demo that lets you preview widgets (thanks Ross for the improvements to this - I like the filter especially!)
>>>> I'd like to turn the navigation part into a widget, that shouldn't be
>>>> hard the way it is currently implemented. Just need to find a little
>>>> time to do it. This is *not* a blocker though. It is one more step
>>>> towards extracting all the UI functionality out of core.
>>>>
>>>>> Widgets
>>>>> ======
>>>>> Drop into /deploy folder, or use REST API. The only function not supported outside of the REST API is deleting widgets.
>>>> So how do we delete a widget in a running instance of Wookie? Seems
>>>> like a necessary feature (but not a blocker).
>>> I presume you'd use the RESTAPI - see org.apache.wookie.tests.functional.WidgetControllerTest for an example.
>> To be honest I can't think of another way to do it. You could watch the unpacked widget folder, and if it vanishes trigger a delete, but that bothers me a bit as it may not be the intention, and deleting widgets has lots of side-effects (deleting related instances, preferences).
>
> Agreed, I don't think thats a good way to go.
Should I add it to the connector?
Or perhaps we could enable/disable widgets or make them invisible or similar?
>
>>
>>>>> The question I have is: is this sufficient to consider WOOKIE-262 completed?
>>>> I'm happy to close it and add a new lower priority issue on the delete
>>>> widget requirement above. Also happy to lower the priority with the
>>>> delete widget requirement remaining in the original issue.
>>> I guess this probably covers it. If we find anything else we've missed then we can open a new issue for it (more specific)
>>> The only other thing is that WOOKIE-262 also mentions a command line management utility (is this a provided .bat and .sh script?)
>> That was the original intention - but maybe thats not needed now?
>
> We could just open a new issue for it and give it a lower priority.
>
>>> Paul
>>>
>>>>> If so, I'll get on with sorting out the remaining documentation so I can close WOOKIE-19& WOOKIE-15.
>>>> This email is a good start for FAQ documentation.
>>>>
>>>> Ross
>>>>
>>
>
Re: Wookie without a UI: are we there yet?
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 29/03/2012 15:03, Scott Wilson wrote:
> On 29 Mar 2012, at 14:52, Paul Sharples wrote:
>
>> On 29/03/2012 14:39, Ross Gardler wrote:
>>> On 29 March 2012 14:31, Scott Wilson<sc...@gmail.com> wrote:
>>>> Hi everyone,
>>>>
>>>> We've now removed the UI client from trunk, the only UI now is a HTML-only demo that lets you preview widgets (thanks Ross for the improvements to this - I like the filter especially!)
>>> I'd like to turn the navigation part into a widget, that shouldn't be
>>> hard the way it is currently implemented. Just need to find a little
>>> time to do it. This is *not* a blocker though. It is one more step
>>> towards extracting all the UI functionality out of core.
>>>
>>>> Widgets
>>>> ======
>>>> Drop into /deploy folder, or use REST API. The only function not supported outside of the REST API is deleting widgets.
>>> So how do we delete a widget in a running instance of Wookie? Seems
>>> like a necessary feature (but not a blocker).
>> I presume you'd use the RESTAPI - see org.apache.wookie.tests.functional.WidgetControllerTest for an example.
> To be honest I can't think of another way to do it. You could watch the unpacked widget folder, and if it vanishes trigger a delete, but that bothers me a bit as it may not be the intention, and deleting widgets has lots of side-effects (deleting related instances, preferences).
Agreed, I don't think thats a good way to go.
>
>>>> The question I have is: is this sufficient to consider WOOKIE-262 completed?
>>> I'm happy to close it and add a new lower priority issue on the delete
>>> widget requirement above. Also happy to lower the priority with the
>>> delete widget requirement remaining in the original issue.
>> I guess this probably covers it. If we find anything else we've missed then we can open a new issue for it (more specific)
>> The only other thing is that WOOKIE-262 also mentions a command line management utility (is this a provided .bat and .sh script?)
> That was the original intention - but maybe thats not needed now?
We could just open a new issue for it and give it a lower priority.
>> Paul
>>
>>>> If so, I'll get on with sorting out the remaining documentation so I can close WOOKIE-19& WOOKIE-15.
>>> This email is a good start for FAQ documentation.
>>>
>>> Ross
>>>
>
Re: Wookie without a UI: are we there yet?
Posted by Scott Wilson <sc...@gmail.com>.
On 29 Mar 2012, at 14:52, Paul Sharples wrote:
> On 29/03/2012 14:39, Ross Gardler wrote:
>> On 29 March 2012 14:31, Scott Wilson<sc...@gmail.com> wrote:
>>> Hi everyone,
>>>
>>> We've now removed the UI client from trunk, the only UI now is a HTML-only demo that lets you preview widgets (thanks Ross for the improvements to this - I like the filter especially!)
>> I'd like to turn the navigation part into a widget, that shouldn't be
>> hard the way it is currently implemented. Just need to find a little
>> time to do it. This is *not* a blocker though. It is one more step
>> towards extracting all the UI functionality out of core.
>>
>>> Widgets
>>> ======
>>> Drop into /deploy folder, or use REST API. The only function not supported outside of the REST API is deleting widgets.
>> So how do we delete a widget in a running instance of Wookie? Seems
>> like a necessary feature (but not a blocker).
>
> I presume you'd use the RESTAPI - see org.apache.wookie.tests.functional.WidgetControllerTest for an example.
To be honest I can't think of another way to do it. You could watch the unpacked widget folder, and if it vanishes trigger a delete, but that bothers me a bit as it may not be the intention, and deleting widgets has lots of side-effects (deleting related instances, preferences).
>>
>>> The question I have is: is this sufficient to consider WOOKIE-262 completed?
>> I'm happy to close it and add a new lower priority issue on the delete
>> widget requirement above. Also happy to lower the priority with the
>> delete widget requirement remaining in the original issue.
>
> I guess this probably covers it. If we find anything else we've missed then we can open a new issue for it (more specific)
> The only other thing is that WOOKIE-262 also mentions a command line management utility (is this a provided .bat and .sh script?)
That was the original intention - but maybe thats not needed now?
>
> Paul
>
>>
>>> If so, I'll get on with sorting out the remaining documentation so I can close WOOKIE-19& WOOKIE-15.
>> This email is a good start for FAQ documentation.
>>
>> Ross
>>
>
Re: Wookie without a UI: are we there yet?
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 29/03/2012 14:39, Ross Gardler wrote:
> On 29 March 2012 14:31, Scott Wilson<sc...@gmail.com> wrote:
>> Hi everyone,
>>
>> We've now removed the UI client from trunk, the only UI now is a HTML-only demo that lets you preview widgets (thanks Ross for the improvements to this - I like the filter especially!)
> I'd like to turn the navigation part into a widget, that shouldn't be
> hard the way it is currently implemented. Just need to find a little
> time to do it. This is *not* a blocker though. It is one more step
> towards extracting all the UI functionality out of core.
>
>> Widgets
>> ======
>> Drop into /deploy folder, or use REST API. The only function not supported outside of the REST API is deleting widgets.
> So how do we delete a widget in a running instance of Wookie? Seems
> like a necessary feature (but not a blocker).
I presume you'd use the RESTAPI - see
org.apache.wookie.tests.functional.WidgetControllerTest for an example.
>
>> The question I have is: is this sufficient to consider WOOKIE-262 completed?
> I'm happy to close it and add a new lower priority issue on the delete
> widget requirement above. Also happy to lower the priority with the
> delete widget requirement remaining in the original issue.
I guess this probably covers it. If we find anything else we've missed
then we can open a new issue for it (more specific)
The only other thing is that WOOKIE-262 also mentions a command line
management utility (is this a provided .bat and .sh script?)
Paul
>
>> If so, I'll get on with sorting out the remaining documentation so I can close WOOKIE-19& WOOKIE-15.
> This email is a good start for FAQ documentation.
>
> Ross
>
Re: Wookie without a UI: are we there yet?
Posted by Ross Gardler <rg...@opendirective.com>.
On 29 March 2012 14:31, Scott Wilson <sc...@gmail.com> wrote:
> Hi everyone,
>
> We've now removed the UI client from trunk, the only UI now is a HTML-only demo that lets you preview widgets (thanks Ross for the improvements to this - I like the filter especially!)
I'd like to turn the navigation part into a widget, that shouldn't be
hard the way it is currently implemented. Just need to find a little
time to do it. This is *not* a blocker though. It is one more step
towards extracting all the UI functionality out of core.
> Widgets
> ======
> Drop into /deploy folder, or use REST API. The only function not supported outside of the REST API is deleting widgets.
So how do we delete a widget in a running instance of Wookie? Seems
like a necessary feature (but not a blocker).
> The question I have is: is this sufficient to consider WOOKIE-262 completed?
I'm happy to close it and add a new lower priority issue on the delete
widget requirement above. Also happy to lower the priority with the
delete widget requirement remaining in the original issue.
> If so, I'll get on with sorting out the remaining documentation so I can close WOOKIE-19 & WOOKIE-15.
This email is a good start for FAQ documentation.
Ross
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com