I agree with you that setTarget is a mutator and should be exposed as such.
But I'd argue, it should be the mutator of a field named target. Fields such a sourcepackage, distribution, product don't need to be exposed. It's really an implementation details that leaks the Object-RDBMS mismatch. Polymorphism FTW -- Francis J. Lacoste [email protected] On May 7, 2010, Leonard Richardson wrote: > > Not surprising, but how can we tell the restfulclient that the url for > > the entry has changed? > > Named operations don't really have hooks for this kind of thing. OTOH if > you set a regular field (possibly through a mutator) and that happens to > change the object's URL, lazr.restful knows to send a redirect to the > new URL. > > I would like to get rid of that named operation altogether if possible. > setTarget() is a method that sets _either_ project _or_ source_package. > Both of these are normal fields of the branch, and if you made them > directly settable the API would be simpler. The only part of > setTarget()'s logic the end-user needs to know is "if the branch is ever > missing both project and source_package, it gets automatically moved > into the junk namespace of the branch owner". That information can go > into the descriptions of project and source_package. > > But setTarget sets _either_ project or source_package. lazr.restful > prohibits one field from having two mutators, but you might be able to > declare a single method with different fixed arguments as the mutator > for two different fields. Realistically, though, this has never been > tried before and strains the capabilities of the system. > > A more realistic solution might be to implement setattr for 'project' > and 'source_package' in Branch. This would let us treat them like normal > fields without having to do any lazr.restful hacks. > > On top of this, I can implement something in lazr.restful that checks > the URL of an object before and after invoking a POST named operation. > But "this named operation needs special treatment" is a code smell. It > indicates that the system is more complex than it needs to be. > > In this case, if the user thinks "I want to move this branch to project > foo", they have to look at the apidoc, discover that setting the project > is a special case of setting the "target", and invoke a named operation > called setTarget. Ideally they would be able to set .project=foo and > save. > > Summary: I should extend the 'check if the URL has changed' code to run > after a POST named operation, but I don't think we need to publish this > particular named operation, and turning project_link and > sourcepackage_link into read-write fields will also solve your problem. > > Leonard > > > _______________________________________________ > Mailing list: https://launchpad.net/~launchpad-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~launchpad-dev > More help : https://help.launchpad.net/ListHelp
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
