launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #03100
Re: Adapters & API (was Re: Exposing newCodeImport)
On Mon, 29 Mar 2010 18:11:26 +0100, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
> On Mon, Mar 29, 2010 at 5:55 PM, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
> > On Mon, 29 Mar 2010 17:21:56 +0100, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
> >> I think ultimately you'll need to be explicit. For example,
> >> IBranchTarget(sourcepackage).name != sourcepackage.name for any
> >> ISourcePackage.
> >
> > Right, that's true, which pretty much rules out the invisible to clients
> > approach, unless a prefix is added.
> >
> > branch_target_name
> >
> > would be ok in my eyes, but
> >
> > branchTargetNewCodeImport()
> >
> > or similar would not be.
> >
>
> I guess you could implement IBranchTarget(obj).name and
> IBranchTarget(obj).newCodeImport() on the client-side too.
As sugar for this case, or are you speaking about something else?
This would obviously mirror the LP internals more closely, but I'm not
sure how it could be communicated in the WADL that these were adapters,
if we wanted to go for an approach most similar to the current LP code.
> >> > If there are writeable attributes in any adapted objects then you have
> >> > the choice between a PATCH to the object and it's adapted version that
> >> > would have to infer which attributes are associated with which object,
> >> > or two PATCH requests with the inherent atomicity concerns.
> >> >
> >>
> >> I'd lean to the second – to being explicit. The atomicity concerns
> >> would not be unique to adapted objects.
> >
> > True.
> >
> > I think we are in agreement then.
> >
> > There's pretty much nothing that would stop you implementing this
> > approach now, just without any sugar to make it easy to do so. Should I
> > have a look at doing it this way for IBranchTarget.newCodeImport()?
> >
> > Actually, perhaps I don't want to volunteer for that, as I'm not sure
> > how I would implement the canonical url for IBranchTarget, given that it
> > would change based on the target, and IBranchTarget doesn't actually
> > have any attributes for gettting the original object.
> >
>
> It's not on the interface, but all of the implementations define a
> 'context' property.
Ah, thanks.
James
Follow ups
References