@naonak: Yes, that’s a step in the right direction!

@Hannibal: The decision is quite simple. You have to ask yourself the following question: would you write tests for it in your application (if you are into testing)? If yes, it goes to the libs folder, else to the vendors folder.

If you create a library, and put it in your new lib folder, then I get the library from you, where do I put it? It’s third party, not maintained by me, but it’s your library. For the sake of the argument, let’s say we’re best pals working in a company together, but on different projects.

Vendors or libs?

(I obviously need coffee ASAP:))

$vendorPaths = array(APP_DIR . DS . 'libs');

You allays need to use App::import('Vendor', 'my_on_lib'); but files are physically separated.

@nate: I’m looking for a better way to structure cake applications. For me an application consists basically of the following logical parts: model functionality, view functionality, controller functionality, non-MVC functionality, and 3rd party libraries. And so I think this should also be reflected in the structure of the “app” folder and the conventions.

@Brendon: Yes.

@skiedr: Yes, that’s probably the approach I have to adopt myself.

@Chris: Well, not everything does fit into the MVC structure. An example is a utility class which fetches the content of an url, and is used in models and components. Other examples are the classes in the cake/libs folder. If they wouldn’t be part of the framework, where would you place them if you have to write them yourself?

@Hannibal Lecter: *g*. Sure, you can create a subfolder in the “vendors” folder and place your own utility classes there. But as I described in the answer to nate, for me an application consists of five logical parts, MVC plus non-MVC classes and 3rd party libraries, which I think should be represented in the “app” folder.

@David: For me a vendor class is a class which wasn’t written specifically for cake and hence doesn’t follow the cake conventions. It is usually maintained by someone else.

On the other hand, a “lib” class (maybe non-MVC class is more suitable) is a class which doesn’t fit into the MVC structure and is written and maintained by myself.

Somehow it is similar to the “app” and “cake” folder: by convention you work in the “app” folder and you don’t touch the “cake” folder. If we adapt this convention, we could say: you work in the (not yet existing) “libs” folder and you don’t touch the “vendors” folder unless you have to add/update/remove a 3rd party library.

I really would like to see a change of the default folder structure or an insight into the logic which is behind the current one.

The naming of the vendors folder always irritated me.
Maybe it’s because I’m not a native speaker and the *only* thing that comes to my mind when I read “vendors” is “3rd party”.

From the POV of the framework itself, every other lib (not part of MVC) is a vendor lib.
Following this logic should I put the cake libs (not part of MVC e.g. the Xml class) into my vendors folder? Certainly not.

So… what is a vendor class? What is a lib? And what is actually part of MVC?

Seems nate is right and there is no pattern of seperation (necessary) between libs and vendors.

But when there is no difference between them, then my suggestion is to rename the “vendors” folder to “libs”.

And how would we import the classes then?
App::import(‘Core’ …) for the core libs
App::import(‘App’ …) for the app libs

Wouldn’t it be more simple to just create a sub-folder in vendors for your own libs? You get both the separation and you can use the built-in App::import(…).