I've done this a try [1] and the changes needed to make lazr.restful do what we want are not too complicated. The only thing you won't have with these changes is the ability to extend a top level collection, but it should be possible to do something similar for them if we ever need -- we currently don't seem to need it, and that's why I haven't bothered.
[1] https://code.edge.launchpad.net/~salgado/lazr.restful/extension-interfaces/+merge/29388 On Tue, 2010-06-29 at 15:45 -0400, James Westby wrote: > On Mon, 29 Mar 2010 14:59:12 -0400, Leonard Richardson > <[email protected]> wrote: > > Assuming I understand what you're trying to do, the simplest way to > > represent this would be to define an annotation like > > @import_from_adapter() and put @import_from_adapter(IBranchTarget) in > > IProduct and ISourcePackage, while leaving it out of IPerson and > > IProductSeries. > > > > In IBranchTarget you would have an annotation like > > @only_used_in_adaptations that would stop it from being exported as a > > separate entry type. You would publish IBranchTarget.name as > > "branch_target_name" (or whatever you wanted) to avoid colliding with a > > 'name' declared in IProduct or ISourcePackage. The same would hold true > > for IBranchTargetName's named operations. You can choose whatever name > > you want, but if that name conflicts with a name found in the original > > interface, the original interface takes precedence. > > > > The end result would be 'product' and 'source_package' looking like they > > had everything that's @exported in IBranchTarget. Behind the scenes, a > > product or source package would be adapted to IBranchTarget to retrieve > > values like 'branch_target_name'. A PATCH that modified (eg.) both name > > and branch_target_name would make both object modifications within a > > single database transaction. > > This just came up again in a different situation, with a couple of > additional requirements. > > What we would like to do is avoid registry importing from so many of the > other apps, to avoid the circular dependencies. > > To do this we are currently looking at having ISomething interfaces in > the apps (bugs, code, soyuz etc.) that define an interface relevant to > them. This is standard practice for a lot of things, see IBugTarget, > IHasBranches etc. > > The implementations of these are then adapters, which isn't usually the > case. > > class ProductToBugTarget(): > adapts(IProduct) > implements(IBugTarget) > > This means that all the bugs-specific code can live in lp.bugs. > > This means that we want something similar to before, where some IProduct > methods should be made available over the webservice by adapting the > IProduct and calling the methods on the result. > > > In order to break the circular dependency we need to stop IProduct from > deriving from IBugTarget as well. In our experimental branch we define > a marker interface in lp.registry for things that can be adapted to bug > targets, which helps with registration etc. > > class IProduct(ICanBeBugTarget): > > The wrinkle that this has it that it doesn't accomodate the webservice. > > Currently in order for IBugTarget methods to be available on IProduct > they have to be available in the interface that IProduct derives from, > currently IBugTarget, which means that bugs code has to be imported in > to the registry. > > Using ICanBeBugTarget means that IBugTarget can't add methods to > IProduct right now. Therefore we want a way to annotate that extra > methods should be added from the webservice point of view, but > crucially, we don't want to import the bugs interface in order to do > that. > > class ICanBeBugTarget(Interface): > > @import_from_adapter(IBugTarget) > > requires importing lp.bugs.interfaces.bugtarget.IBugTarget, which gives > us the circular dependencies again. > > Would it be possible for us to instead have something like: > > class ProductToBugTarget(): > > @only_used_in_adaptations > @add_things_to(IProduct) > > such that the arrow is drawn the other way, and apps can add things to > registry objects without the registry having to import them? > > I don't see why this can't be done, except that it means that finding > out the methods on an object is now a global operation, requiring > importing everything and considering the result, rather than just > importing the interface and scanning it. > > Thanks, > > James -- Guilherme Salgado <https://launchpad.net/~salgado>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
