[kforge-dev] domainmodel API design suggestions

Fri Nov 17 17:39:10 UTC 2006

Jo Walsh wrote:
> dear Rufus, John, thankyou both for indulging me in pair- and triad-
> programming sessions last week and enduring my barrage of stupid
> questions and answering many of them.
> 
> I was just looking over my notes on the domainmodel interface and
> wondering about possible API reworking. I find the current API more
> *seems* overcomplex because it talks the language of the pattern
> process so literally. Well illustration is always best; the following
> is what my notes say now about how to query for instances of an object
> in the domain model:
> 
>     from ckan.soleInstance import application
>     register = application.registry.getDomainClassRegister()
>     domainClasses = register.keys() 
>     domainClass = domainClasses['PackageName']
>     objectRegister = domainClass.createRegister()
>     objectRegister.findDomainObjects(filter)

I normally do:

import ckan

app = ckan.getA()
tags = app.registry.tags  # or app.registry.projects or ...
tags_i_want = tags.filter(...)

you can try this from an interactive shell

bin/ckan-admin shell

(better than straight $ python to get a shell as it sets any necessary 
environment variables for you)

> ^^^^- note my four-space tabs, Rufus :P 

appreciated ;0

> I would like to be able to address domainmodel more idiomatically thus:
> 
>     ...
>     classes = application.classes()
>     package = classes['Package']
>     package.list(filter) or package.search(filter)

ok so this just a mapping of

application.registry -> application.classes

and for the registry to key by the class name rather than having 
attributes such as .tags or .packages

> And have the stuff below abstracted away a bit more. It is a beautiful
> if baroque design underneath, that works really well, but as an
> application developer i don't think i need to be so exposed to the
> inner workings and to the raw pattern language as the current interface
> necessitates.

Absolutely the user of the domain model doesn't really need to know how 
it is working. They should just be able to utilize those classes to 
write a plugin or a view or ...

> I wish i had the focus to accompany this with more constructive
> illustrations but it probably wants to be talked over a bit more
> before code written anyway, the latter is relatively unimportant?  
> 
> I am probably working fulltime for the next couple of weeks (!) but
> would love to come back to Cambridge in 3 or 4 weeks time and have a
> more proper sprinting session then, and patch the docs up.

That would be great and it would be wonderful to some more pair programming.

Regards,

Rufus