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/