Posted by coltrane on July 27, 2009 at 3:06pm
Jump to:
| Project: | Unfuddle API |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
This issue is for discussing the architecture of the Unfuddle API module during initial development
Comments
#1
The particular Unfuddle data types I need to GET and POST for connecting the Casetracker module with Unfuddle is projects, people, and tickets so in the initial commit the .module file contains methods for those types.
I saw the .inc file for holding the implementations of the requests which at the moment is a function for making a GET and another for a POST using curl. Thinking on this over the weekend though I'm not sure a separate .inc file is needed cause it's almost too lightweight. The .module will be heavy if it holds Drupal-specific wrappers for all the http://unfuddle.com/docs/api Usage scenarios though.
#2
Generally, I think the module should do almost nothing but provide methods for other modules and developers to call. That is, the Unfuddle API module shouldn't store any ticket or project information itself. It should be as light as possible and make little to no assumptions on how it's being used. The exception to this is the persistent storage of the unfuddle.com connection strings, but even that could be easily overridden. For instance, the current methods unfuddle_api_get_projects(), unfuddle_api_create_ticket(), and unfuddle_api_get_people() take optional arguments of the Unfuddle URL, user, and password, defaulting to the stored, global data.
#3
The current code is procedural-based but I'm leaning towards a class for code reuse and legibility. I was on the fence about this since it *might* raise the bar for developers to use, but after getting a thumbs-up from a colleague and seeing that the Twitter module uses a class as well I'm going to go for it.
#4
I committed http://drupal.org/cvs?commit=243590 an Unfuddle class which better handles overriding behaviors than the first round procedure code. I also have a casetracker_unfuddle module that makes a good example of using the class and might make a good Atrium feature.
unfuddle_api.inc file probably won't be necessary now unless there are some good ideas for decreasing this module's code weight.
#5
#6
Automatically closed -- issue fixed for 2 weeks with no activity.