Lullabot / copelandia

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

RestWS and file paths

sirkitree opened this issue · comments

The file path that RestWS serves up for a node object is

field_recipe_photos: [
  0: {
    alt: "",
    file: {
      uri:"http://copelandia.lulladev.com/file/2", 
      id:"2", 
      resource:"file"
    }
  }
]

Obviously that is not the correct uri for the file. Need to figure out how to get the entire uri. Is this a bug in restws?

Looks like it's trying to give you the path to another restws url, of the form file/[fid].

Ah, you're right. If you append.json to that (http://copelandia.lulladev.com/file/2.json) you get:

{
fid: "2",
name: "pokern.jpg",
mime: "image/jpeg",
size: "29333",
url: "http://copelandia.lulladev.com/sites/default/files/recipe_photos/pokern.jpg",
timestamp: "1363803325"
}

I'll use that. I'm slightly non-plussed to have to do another call though...

I agree. It'd be nice if you received the object instead of a URL to an object, IMO. Is that possible with restws?

I agree with @sirkitree seems like that data should be available with the same feed... is that possible...

I don't see any options for it, and https://github.com/Lullabot/copelandia/blob/master/docroot/sites/all/modules/contrib/restws/restws.entity.inc#L325 is where I think it's getting the info for fields. Might take some sort of modification there to make it happen?

I think this issue is related: http://drupal.org/node/1335958

In the above commit you'll see that I looped through and made a call for each image. Not ideal, but works for now.

Looks like the images do not match to the titles, as you refresh you get different image for same title.
I have some css that holds the placeholder open for easier viewing atm.
Perhaps because titles get sorted?

I'm working on refactoring this to be more accurate and use factories

Refactoring complete. Images show up where they should. However, it's still a band-aide and not a fix. I still have to do some crazy workaround to do another call for each file, and even though I'm caching it to make it faster, it's still not something I should have to do.

That last d.o issue was not very specific and the op had a different problem that has since been resolves to i closed it and opened http://drupal.org/node/1978202