> >> > IBranchTarget has several implementations, one for each of product, > >> > sourcepackage, person, and productseries. I want the method to be only > >> > available on the first two if possible, but it's fine if it has to be > >> > all four, as it is part of the interface after all.
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. Would this work? (This is not something I can get to anytime soon, BTW.) Leonard > >> > > >> > I can add newCodeImport methods to IProduct and ISourcePackage that just > >> > do > >> > > >> > def newCodeImport(...): > >> > return IBranchTarget(self).newCodeImport(...) > >> > > >> > but that seems like unnecessary duplication. > >> > > >> > Is there some way that I can tell lazr.restful to consider IBranchTarget > >> > when looking at what to export on IProduct etc? > >> > >> I *think* but without checking the code or really knowing for sure that > >> you have to make IProduct inherit from IBranchTarget to do this. But > >> IIRC products are not IBranchTargets, they are adaptable to > >> IBranchTargets, and I don't think adaptation is (or really could be) a > >> concept that translates into the API. > > > > Right, so it sounds like I still need a small interface and mixin to do > > the adaptation and call newCodeImport on the result? > > > > This is the right solution given our current constraints, but it's kind of > ugly. > > I know there's a bunch of stuff to do with the webservice API first, > but do we have any idea how we can have methods on interfaces where > they make sense and still expose them over the webservice API? > > jml > > _______________________________________________ > Mailing list: https://launchpad.net/~launchpad-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~launchpad-dev > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
