Re: Question about API wrapper design
I came across a similar problem/question when coding the lastFM API wrapper: http://lastfmapi.riaforge.org/ I created a separate cfc for each logical part of the api and then created a single component that took care of instantiating and giving access to the various parts. I'm not sure I'm 100% happy with that choice but it did keep code organised and avoided a 10,000 line code monster cfc! My 2c. Dominic On 17 April 2011 04:55, Jeff Gladnick jeff.gladn...@gmail.com wrote: hmm. This sounds too complicated for the average user, but I am curious to know more about this. For the same reason I am hesitant to have multiple files extending a base class. For that I like mark's suggestion about the single cfc. I want this to be as plug and play as possible for people. 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 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: ~| 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:343803 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Question about API wrapper design
@Mark Drew: So just to be clear, your recommendation is: 1) One single file 2) separate methods for each functionality (instead of using arguments) that sounds reasonable. ~| 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:343799 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Question about API wrapper design
hmm. This sounds too complicated for the average user, but I am curious to know more about this. For the same reason I am hesitant to have multiple files extending a base class. For that I like mark's suggestion about the single cfc. I want this to be as plug and play as possible for people. 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 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: ~| 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:343800 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Question about API wrapper design
The person method was private, only called by the other methods. andy -Original Message- From: Jeff Gladnick [mailto:jeff.gladn...@gmail.com] Sent: Saturday, April 16, 2011 10:55 PM To: cf-talk Subject: Re: Question about API wrapper design hmm. This sounds too complicated for the average user, but I am curious to know more about this. For the same reason I am hesitant to have multiple files extending a base class. For that I like mark's suggestion about the single cfc. I want this to be as plug and play as possible for people. 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 ~| 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:343801 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Question about API wrapper design
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:343768 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Question about API wrapper design
I've done this quite a bit. Perhaps some of my code could give you ideas? Start with http://foursquarecfc.riaforge.org then check my other projects. On Apr 15, 2011, at 5:08 PM, 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:343769 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
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:343770 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Question about API wrapper design
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
