As soon as the followup/cleanup patch for #112805: JSON menu callback for project issues is committed and deployed, we need to port that stuff to D7.
It's a little tricky since the JSON has a specific schema it's going for, whereas in D7 we want to allow flexible field schema on issue nodes. I'm not 100% sure the best way to handle this. We could:
A) Provide a hard-coded system that works with the default node type we ship and then let people change stuff via hook_project_issue_json_alter(). That seems really lame.
B) Have the default JSON menu item iterate over all the fields on the issue node you're viewing and put all of that into the JSON using the field machine name as the key and the value as the value. Or something. So, probably the JSON itself will change from D6 to D7 since the keys will change.
C) Some weird hybrid where we try to map the machine names to the old JSON keys? Seems lame.
D) Forget it entirely and use services as a generic solution. Good luck getting killes to agree to that. ;)
Other ideas... ?
Probably B is the easiest/best option, but we should probably do a little more research before committing to it.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 1585800-port-issue-json-to-d7-9.patch | 3.62 KB | iamcarrico |
| #6 | 1585800-port-issue-json-to-d7-6.patch | 3.41 KB | iamcarrico |
Comments
Comment #1
dww#112805: JSON menu callback for project issues is fixed and deployed, so this is active.
Comment #2
sunI'd recommend going with A) and leaving all of the more sophisticated options to the port to D8, which will then be able to leverage Drupal core's natively built-in mechanisms.
Comment #3
greg.1.anderson commentedOption B seems best to me, but I will defer to greater experience (and more importantly, to those with more time to work on this patch). Whatever you end up going with, I'll do my best to make it work with the Drush issue queue commands. As long as all of the basic information is there for d.o, supporting other project_issue schemas for other sites is a nice-to-have, but not critical. It's not even entirely likely that this feature will be used outside d.o. Maybe it would, but not certainly.
Comment #4
iamcarrico commentedI am looking into the best way to go at this, maybe make a prototype--- although I do think that the services module would be a better idea as it will allow for greater flexibility... which is exactly what we want to be doing.
Comment #5
dwwYeah, but we'll never get killes to agree to running services.module on d.o. ;) Our hands are slightly tied as we do this port...
Comment #6
iamcarrico commentedOkay, I want to see if this is the kind of functionality we are thinking of. What this will do is automatically add in all the fields, as well as some basic fields already being used. Note: for something like a select list, I do not have the ability to right off the bat get their display, just the value in the database. This will cause an error for something like the status field, but could be solved by 1) calling the field definition for EVERY field and having scripts to pull the right data. 2) Changing the machine key for the status field from an integer to a string.
Thoughts on the structure? Improvements? General concerns with my method?
Comment #7
iamcarrico commentedUpdating status
Comment #8
mirzu commentedI looked at the code, and we talked, and either ian or I are going to try using node_build_content($node); To make this more robust. Currently it's a little fragile.
Comment #9
iamcarrico commentedOkay, so I did a whole re-work... what do y'all think?
Comment #10
iamcarrico commentedSo, mirzu and I have had several offline conversations, and we both believe that this functionality (as it can be needed outside of here and is actually useful) should be put into its own module.
And thus I give you "entity_json: the module"
http://drupal.org/sandbox/ChinggizKhan/1672822
Comment #11
dwwExcellent, thanks! This is looking really good. I just reviewed the code and played with it on my local test site. I opened a bunch of issues, most of them minor or quick in your issue queue for everything I found:
http://drupal.org/project/issues/1672822
Seems slightly wonky to set this issue back to "needs work", but not sure what else to do. ;)
@sun, @greg.1.anderson, et al: Please review that sandbox project code and the resulting JSON (see for example what I posted at #1677472: Always provide both IDs and human-readable labels in JSON output) and let us know what you think. Spoiler: the approach taken is basically (B) -- a generic module that iterates over the entity and prints out all the fields, with no attempt at JSON backwards compatibility. Personally, I think that's fine (although I opened #1677484: apiVersion 1.0? ;) since IMHO the apiVersion should probably change).
Thanks all!
-Derek
Comment #12
dwwGiven #1710850: Deploy RestWS for D7 project issue JSON this issue is no longer relevant for the d.o D7 upgrade.
Assuming that goes fairly smoothly, I'm turning this into an issue about documenting how to use RestWS for this purpose when folks are upgrading or installing their own Project* site.
Comment #13
tvn commentedUntagging.
Comment #14
dwwComment #14.0
dwwAdding some strong tags.