Vasu Nori wrote:
Try looking at this:On Jan 16, 2008 11:39 AM, Dan Diephouse <[EMAIL PROTECTED]> wrote: http://svn.galaxy.muleforge.org/browse/galaxy/trunk/web/src/main/java/org/mule/galaxy/atom/ArtifactVersionWorkspaceInfo.java?r=60 In my application I have a collection of Artifacts. Each artifact has a collection of artifact versions. So I created a workspace for the artifact versions, but I didn't want to actually list out all the artifacts - that would be wayyyy too much time and too big of a services document. I created an ArtifactVersionWorkspaceInfo instead This is a slightly old example, so there would be 2 small differences now: 1. "id" would now be a URI fragment which you would have to parse. I.e. "artifactVersions/123" 2. I think you would have to return null if it wasn't found. Does that help? Also, I just want to clarify some things: 1. The reason I'm being a stickler about this stuff is that fundamentally I think we're trying to do the same thing API wise. Adapter/CP approaches are rather similar I think. 2. I'm also not saying the CP stuff is perfect. The API/ServiceProvider code could surely be cleaned up. 3. I strongly support the idea that we need an array of CPs/Adapters which don't necessarily require the developer. Like your JdbcAdapter. Or the JcrCollectionProvider. It'd be awesome if we just had a component which people could deploy which would do this. (Which seems to be what you're working on IIUC). 4. I don't really care too much if we go with Provider or Adapter as the name. I just think we should be consistent. It should either be (Service/Workspace/Collection)Provider or (Service/Workspace/Collection)Adapter. - Dan -- Dan Diephouse MuleSource http://mulesource.com | http://netzooid.com/blog |
- Re: FeedServer Review James M Snell
- Re: FeedServer Review Vasu Nori
- Re: FeedServer Review Dan Diephouse
- Re: FeedServer Review James M Snell
- Re: FeedServer Review Dan Diephouse
- Re: FeedServer Review James M Snell
- Re: FeedServer Review Dan Diephouse
- Re: FeedServer Review Vasu Nori
- Re: FeedServer Review Dan Diephouse
- Re: FeedServer Review Vasu Nori
- Re: FeedServer Review Dan Diephouse
- Re: FeedServer Review Jun Yang
- Re: FeedServer Review Dan Diephouse
