See also #1119992: Services for Menu? and #1155110: menu_build_tree

The services menu module handles menu support for the Services module version 3.x and later.

A clean and simple services resource that retrieves a menu structure by name.

[Current sandbox at: http://drupal.org/sandbox/robinvanemden/1199250]

EDIT: Sandbox has graduated to Project. Project can be found here:

http://drupal.org/project/services_menu

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ccardea’s picture

I just took a quick look at your project.

.inc file
files[] is for files that contain class or interface definitions that get autoloaded. You don't need to list your .module and .inc files there.

dependencies[] Since your project is specific to Services 3, you should include the version here.

No licensing or duplication issues.

Waiting time for a full review can be 4 - 6 weeks. You can help reduce your waiting time by contributing to the code review process. Please visit http://groups.drupal.org/code-review for details on how to contribute.

ccardea’s picture

Status: Needs review » Needs work
Robin van Emden’s picture

Status: Needs work » Needs review

Made the suggested changes. I will contribute to the code review process, as time permits!

mrfelton’s picture

subs

mrfelton’s picture

Status: Needs review » Reviewed & tested by the community

I've been using the sandbox code, and would like to see this come out of the sandbox on to d.o as a fully fledged project.

ccardea’s picture

Status: Reviewed & tested by the community » Needs review

It's counter productive to change the status of the application without doing a real review. It's good to know that the code works and has users, but that's not really a code review

mrfelton’s picture

Status: Needs review » Reviewed & tested by the community

Ok, well I don't see any issues with the code over and above the ones that I reported in the modules issue queue, which have been committed now.

Only one minor code style thing, which is that there is an inconsistancy in the comment style for hook implementations.

e.g.

/**
 * Implements hook_permission().
 */
/**
 * Implementation of hook_services_resources().
 */

They should both be using the Implements hook_hookname(). format. Is that something that would stop this brom breaking out of the sandbox?

Robin van Emden’s picture

Latest commit fixed the inconsistency reported by mrfelton. As can be seen in the previous commits, some small issues were previously reported and fixed in the sandbox issue cue. (As an aside, there is a discussion on this topic here: Code review in application issue or projects sandbox? - so next time around I will "add a comment to the project application issue to let the applicant and other reviewers know that a 'review' issue" )

ccardea’s picture

Status: Reviewed & tested by the community » Needs work

line 69: $access = $access; Why is this necessary?

Robin van Emden’s picture

Status: Needs work » Needs review

Hi ccardea, now that is a good question. Leftover code, I guess. Line 69 has been deleted.

g10’s picture

Status: Needs review » Needs work
Robin van Emden’s picture

Status: Needs work » Needs review

Merged with g10's GitHub branch (thanks g10!). Cleaned up the code according to Coder module review info. Reverted to the default args implementation in stead of g10's named args, since they caused tests to fail on our test-server.

Also decided to revert to dependencies[] without (3.x), because of #1013302: Versioned dependencies fail with dev versions and git clones . Formally ccardea is right in #1, but adding (3.x) causes lots of headaches for drush and git users. Will add (3.x) to dependencies[] if and when this issue is resolved.

ccardea’s picture

g10 appears to be much more familiar with your code than I am. If he's happy with the changes, he should mark the application RTBC

g10’s picture

Status: Needs review » Reviewed & tested by the community

After reviewing the module in depth, I can confirm the current version (merged w/ the changes from the github branch) does what it claims,
I do not see a reason to hold it further in application state

Robin van Emden’s picture

Thanks, g10.

For general information: attached screen-shots of REST responses returned by "Services Menu" when retrieving an existing and a non-existing menu. Also a text file containing the object returned, a trace from a Flash AS3 app calling AMFServer.

mlncn’s picture

Congratulations!  You can now promote sandbox projects to full status ones.  When you would like further review for any project please do ask at http://groups.drupal.org/peer-review/requests

Further cleanup issues introduced here and new ones can be filed on your project issue queue.  Thank you for your contribution and i look forward to seeing its refinement and development and your continued involvement in Drupal!

benjamin, agaric

Robin van Emden’s picture

Hi Benjamin,
Thank you for promoting the Services Menu sandbox, by bus no less!

Robin van Emden’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Sandbox has been promoted to project - added link.