To realize it as a data source is a possible solution. In NoseRub we implemented the same functionality as a component ;-) So you see: different developers, different approaches to solve the same problem…

In the meantime I would probably realize it as a vendor class (as there is no “libs” concept in the “app” folder). Personally, I don’t see it as a data source, because all the API does is to translate an address to coordinates: you send some data and you get back the same data in a different format. In the end it depends on what your definition of a data source is.

But some days ago I needed a wrapper for the google maps. My question then was: should I build a datasource or a AppModel-class. The features I required from google maps where: to receive the coordinates for an address. So I decided to build the wrapper as datasource (because it returns data).

What do you think?
Simon

@Brandon: Well, I think it depends on your point of view whether it is incorrect to put classes, which do not extend AppModel, in the models folder. If you say all classes in the models folder have to extend AppModel, then you are right, and it’s messy to put other classes into the models folder. On the other hand, if your point of view is on a more abstract level, then the implementation of a model is no longer important. Extending AppModel is one of many ways you could implement, for example, the Post model…

I also use the approach you described for “helper” functionality, but personally I don’t like it. It feels wrong to me to have third-party-libraries and my own code in the same folder…

@Tarique: Yes, you are right, the name is probably a bit unlucky :|

@Martin: I think there is no definite answer to where you should place such functionality. Sometimes the best way is to leave Cake’s structure and to implement it in a way you think is more suitable for the task at hand.

For an app I have build that sends and receives a lot of SMS messages I ended up putting all of the above into a plugin. A controller to handle incoming requests, Models to deal with data and some logic, and a component so that any other controller can decide to send an outgoing message. I am still not happy with it though.

I find a whole lot of people just don’t get the point of MVC but in a reverse way ;)

@Brandon P your example is comparing apples to oranges.

bootstrap.php

set_include_path(get_include_path() . PATH SEPARATOR . ../path/to/vendors/classes’ );

require_once ‘common.php’;

In my app:

Common::getServerTime();

I use a similar technique where I have a static “Common” class that give me access to common functionality that I use pretty much all over my app (in models, views, etc).

I created a ‘classes’ directory within ./app/vendors (imo, a more appropriate place)

./app/vendors/classes/common.php

And then included it on my bootstrap

Then I can use it statically:

@David: Yes, ClassRegistry::init(‘PseudoModel’); still works.