launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

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
francis.lacoste@xxxxxxxxxxxxx

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     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: This is a digitally signed message part.