Re: Schema provider/CA lookup status

whit wrote:

> not sure I follow you here.  ISchema(instance) only returns the schema 
> in-toto

What does this mean? Language parsing error ;-)

> for that instance.  It would encapsulate anything else(just like 
> Schema()). 

Yes, but the idea is that I can provide another adapter to ISchema if I 
wish to override, yes?

In that case, I *must* also remember to run the ClassGen magic after 
I've found out which schema I'm using (or rather, each time the schema 
I'm using changes), or base_edit and probably other things will break.

> There is no requirement for ClassGen to exist inside or 
> outside of an adapter in your example...putting it inside make it 
> possible for someone to change the implementation to fit their needs 
> without using inheritance(thus avoiding migrations and other headaches).

What I mean is - the call to ClassGen is a necessary evil. If you want 
schemas that change, you have to do it. AT depends on it (and I guess 
it's not easy to make it independent of it). Thus, I think we should 
make sure it happens, not rely on the adapter writer to remember to call 
it. Also, to be efficient, it needs to be cached (as per my mixin), 
which again is tricky and should be done in a uniform way.

And if/when we fix AT to not need it anymore, I'd like to be able to 
remove it one place, not tell every adapter writer to get rid if again.

> which I think is fine...I just think that ISchema is the encapsulating 
> entity here.  I want elaborate extension via ISchemaExtender, then I 
> register an adapter to handle that, if I want the default, then I leave 
> the registrations as is.  the really cool about what you've done is that 
> if you encapsulate it as an adapter, you can easily switch in your 
> behavior for the default or vice versa.

Yeah, I agree - the extender mechanism doesn't need to be the default. 
But I think the low-level implementation necessity of having to generate 
methods for schema accessors and mutators is not something we should 
depend on schema authors to remember - it's framework code.

> I'd say we would be exactly on the same page and we'd be able to give 
> people an option for dealing with their schema. 
> 
> Your extension adapter could be a nice way to solve alot of those "I 
> need one extra field" problems without subclassing and proliferation of 
> unnecessary type info.

That is precisely the pattern 'company' is trying to demonstrate, and 
precisely (or rather, partly) what I want to talk about at the 
Conference ;-)

Martin


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV