figleaf-developer

Re: [Figleaf-developer] Need for a ViewRegistry

[<sam...@ma...>]

Quoting sam...@ma...:

> Playing around with your SwingViewer last night, I had some problems getting
> my
> registered views to be picked up. I think this is down to the fact that I
> didn't
> register specific classes with views - that is I registered Informative not
> my
> applications ImageAlbum class. I think we could do with defining a
> ViewRegistry
> class which could be used with any viewing mechanism. It would define the
> following methods:
> 
> void addViewMapping(Class clazz, View view);
> 
> View getView(Class clazz);
> 
> And would define the following behaviour:
> 
> 1. If a direct mapping exists, it returns that view
> 2. If no direct mapping exists, it looks for mappings for its immediate
> superclass, then interfaces
> 3. If no mapping exists for its immediate superclass or interfaces, it
> recursively traverses the superclass structure looking for a match
> 4. Finally if no match can be found null is returned.
> 
> This allows us to assume a mapping for Informative but let the user override
> this. It also lets us map to classes or interfaces - your code seems to only
> support mapping to interfaces. This should be a very simple thing to write
> and
> can drop right into your code (it should even make your code a little
> simpler) -
> I'm happy to work on this while you concentrate on the UI if you want.

Talking to a colleague he had an idea about multiple views matching for a single
class (e.g. its super class and its interfaces have view mappings) that we could
decide to display both - each view represents some facet of the underlying
object (there is no overlap in behaviour). Not sure how feasible that is though
- I think we should keep things simple for this version!


sam
http://www.magpiebrain.com/

Re: [Figleaf-developer] Need for a ViewRegistry

[<sam...@ma...>]

Quoting Greg Steckman <ste...@on...>:

> sam...@ma... wrote:
> 
> >Playing around with your SwingViewer last night, I had some problems getting
> my
> >registered views to be picked up. I think this is down to the fact that I
> didn't
> >register specific classes with views - that is I registered Informative not
> my
> >applications ImageAlbum class. I think we could do with defining a
> ViewRegistry
> >class which could be used with any viewing mechanism. It would define the
> >following methods:
> >

<snip>

> The implementation is already written to do precisely this. It first 
> traverses the complete class hierarchy, if none found it then traverses 
> the interface hierarchy in a way to try and find the closest 
> superinterface (in terms of inheritence distance) for which there is a 
> view registered. I was going to write some test cases for it next 
> though...because it hasn't been tested on anything but the 
> InformativeDescriptorImpl class. That said, I registered a view for 
> Informative, and it found it for my InformativeDesctiprorImpl which 
> implements Informative directly, so I'm not sure why it didn't work on 
> your ImageAlbum class. Perhaps once I write a test I will see...

Well I don't think it can hurt to have this as a seperate class which different
UI mechanisms can reuse - I'll take your code as a base and write one with full
test coverage so we can work out any little kinks that might exist.


sam
http://www.magpiebrain.com/

Re: [Figleaf-developer] Need for a ViewRegistry

[Greg S. <ste...@on...>]

sam...@ma... wrote:

>Quoting Greg Steckman <ste...@on...>:
>
>  
>
>>sam...@ma... wrote:
>>
>>    
>>
>>>Playing around with your SwingViewer last night, I had some problems getting
>>>      
>>>
>>my
>>    
>>
>>>registered views to be picked up. I think this is down to the fact that I
>>>      
>>>
>>didn't
>>    
>>
>>>register specific classes with views - that is I registered Informative not
>>>      
>>>
>>my
>>    
>>
>>>applications ImageAlbum class. I think we could do with defining a
>>>      
>>>
>>ViewRegistry
>>    
>>
>>>class which could be used with any viewing mechanism. It would define the
>>>following methods:
>>>
>>>      
>>>
>
><snip>
>
>  
>
>>The implementation is already written to do precisely this. It first 
>>traverses the complete class hierarchy, if none found it then traverses 
>>the interface hierarchy in a way to try and find the closest 
>>superinterface (in terms of inheritence distance) for which there is a 
>>view registered. I was going to write some test cases for it next 
>>though...because it hasn't been tested on anything but the 
>>InformativeDescriptorImpl class. That said, I registered a view for 
>>Informative, and it found it for my InformativeDesctiprorImpl which 
>>implements Informative directly, so I'm not sure why it didn't work on 
>>your ImageAlbum class. Perhaps once I write a test I will see...
>>    
>>
>
>Well I don't think it can hurt to have this as a seperate class which different
>UI mechanisms can reuse - I'll take your code as a base and write one with full
>test coverage so we can work out any little kinks that might exist.
>
>
>sam
>http://www.magpiebrain.com/
>
>
>  
>

I'll break it out. I was just getting started on the tests.

Greg

Re: [Figleaf-developer] Need for a ViewRegistry

[<sam...@ma...>]

Quoting Greg Steckman <ste...@on...>:


> >Well I don't think it can hurt to have this as a seperate class which
> different
> >UI mechanisms can reuse - I'll take your code as a base and write one with
> full
> >test coverage so we can work out any little kinks that might exist.
> >
> >
> >sam
> >http://www.magpiebrain.com/

> I'll break it out. I was just getting started on the tests.
> 
> Greg

OK, cool - I'd started a little bit of work on this but it sounds like you've
got it all in hand. What do we need next?

sam
http://www.magpiebrain.com/

Re: [Figleaf-developer] Need for a ViewRegistry

[Greg S. <ste...@on...>]

sam...@ma... wrote:

>Quoting Greg Steckman <ste...@on...>:
>
>
>  
>
>>>Well I don't think it can hurt to have this as a seperate class which
>>>      
>>>
>>different
>>    
>>
>>>UI mechanisms can reuse - I'll take your code as a base and write one with
>>>      
>>>
>>full
>>    
>>
>>>test coverage so we can work out any little kinks that might exist.
>>>
>>>
>>>sam
>>>http://www.magpiebrain.com/
>>>      
>>>
>
>  
>
>>I'll break it out. I was just getting started on the tests.
>>
>>Greg
>>    
>>
>
>OK, cool - I'd started a little bit of work on this but it sounds like you've
>got it all in hand. What do we need next?
>
>sam
>http://www.magpiebrain.com/
>
>
>  
>
I haven't had a chance to look at your introspection stuff yet, but now 
it will proxy both superinterfaces of Informative? The next thing might 
be to put the validatable interface back in as a super of Informative. 
The other thing would be to cover the case where a class implements some 
but not all of the superinterfaces of Informaive. For example, I 
implement ClassDescriptor but not Observable. Then have the proxy just 
do its magic for Observable and defer ClassDescriptor calls to the real 
object.

Greg

Re: [Figleaf-developer] Need for a ViewRegistry

[<sam...@ma...>]

Quoting Greg Steckman <ste...@on...>:


> I haven't had a chance to look at your introspection stuff yet, but now 
> it will proxy both superinterfaces of Informative? 

Erm, give it an object, and it returns an object which subclasses the original,
and implements Informative.

> The next thing might 
> be to put the validatable interface back in as a super of Informative. 

I'm guessing Validatable at an Object/class level needs to be backed up with
validation information on a property by property basis - a library of default
validation types would be good (e.g. String at least this long).

> The other thing would be to cover the case where a class implements some 
> but not all of the superinterfaces of Informaive. For example, I 
> implement ClassDescriptor but not Observable. Then have the proxy just 
> do its magic for Observable and defer ClassDescriptor calls to the real 
> object.

Currently I use Informative if I can find it, or else I create a default
implementation (this is working - also if you have DomainObject and I can find
DomainObjectInformative in the same package I use that too). Next step would be
to add the same support for Observable, that is provide the default
implementation if the given domain object doesn't implement Observable -
currently I always implement Observable for the user.

Once I get that working I'll start looking at validation - I guess I can quickly
create a library of useful validation types. I won't handle validation of the
String->Integer nature (that is typing text into a UI that maps to an Integer
property) as that is something the UI should do itself. We also need to consider
how the validation information impacts on the UI - for example a simple "String
should be X characters long" could be implemented in the UI using a fixed input
text field, but "If this other object is X, this value has to be greater than Y"
cannot easily be constrained - in such a case it will simply have to call
"property.valaidate()" or whatever and return the error message. 

I think the simple approach will be to have individual properties validatable,
and have an isValid:String method which returns an error message if invalid. We
could then throw a runtime ValidationException when invoking the write method if
its not valid.


sam
http://www.magpiebrain.com/

Re: [Figleaf-developer] Need for a ViewRegistry

[Greg S. <ste...@on...>]

sam...@ma... wrote:

>
>Talking to a colleague he had an idea about multiple views matching for a single
>class (e.g. its super class and its interfaces have view mappings) that we could
>decide to display both - each view represents some facet of the underlying
>object (there is no overlap in behaviour). Not sure how feasible that is though
>- I think we should keep things simple for this version!
>
>
>  
>
Yes, let's keep it simple for now!

Greg