What I did in some of my projects was to have a base method "person" that the other methods used. Enforce type or variable checking in getPersonByType, but have the bulk of the work done in the getPerson method.
andy -----Original Message----- From: Mark Drew [mailto:mark.d...@gmail.com] Sent: Friday, April 15, 2011 6:13 PM To: cf-talk Subject: Re: Question about API wrapper design Hi there Jeff I think this depends. Who are you writing the API for? I.e is this something you are going to use then let other people use it via RiaForge? Or Are you just developing it to be open source from the get go? I am inclined to have one big file as then it's simple to use as you instantiate it and check out the methods. On the other hand, you might want to return sub objects from your methods (such as arrays of people etc) With regards to Question 2, I simpler methods that are more descriptive would help, such as: getPerson(id) getPeople(Since [optional]) getPeopleByTitle(title) getPeopleByTag(tag) getPeopleByCompany(companyid) getPeopleBySearch(searchterm) getPeopleByCriteria(criteriaStruct) createPerson() savePerson() deletePerson() I hope that helps. Regards Mark Drew On 16/04/2011 08:08, "Jeff Gladnick" <jeff.gladn...@gmail.com> wrote: > >I'm one of the developers working on a CFML wrapper for the highrise >API (highrise.riaforge.org) and we're starting to plan out how we're >going to organize the file structure. > >We have a few choices: >1) Separate file for each type of object (people, task, note, etc) >2) One big CFC file containing functions for each. > >Although it seems like a no brainer to go with #1, I figured it might >be easier for CF developers to integrate into their projects if there >was just a single file to include, rather then a big library. >Advanced users could just strip out what they didn't want/need. > >The 2nd question is about function encapsulation. On the people >object, http://developer.37signals.com/highrise/people, there seem to >be 7 different variations of "GET person" that could all be combined >into a single getPerson() function that had (at least) 7 different >arguments. It seems like we could shrink the codebase a lot more this >way. > >Any suggestions for file & function organization? > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:343775 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
