thanks for your reply. Thats what I do now. But I am not happy with this. We need this directory for other libs.
One told me, that /vendors is for general vendor-libs used by the whole webserver and /app/vendors is for libs that are only used by the application. In our case, maybe it is special, because we port a quite big application, this is not enough. Vendor is for external libs, right? We need a directory to store classes, which are used directly inside controllers and components and nowhere else. Think of this as a further program structure. I think we are going to introduce an app/lib-Directory. This does the job best, I think. Then, /app/vendors is for external libs, which are directly used in the sources and /vendors for small, external programs which could be used on their own. We have some of them, like a formletter-tool. Thanks very much, best regards, Thomas On Dec 12, 2:37 pm, "themanfrombucharest" <[EMAIL PROTECTED]> wrote: > You can place them in /app/vendors instead of /vendors. > > On Dec 12, 11:00 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: > > > Hi, > > > I would say yes and no. I told you that we port an existing project to > > cake. Therfore, there truely is something to do concerning MVC. But > > there are some objects used in the code, which are good and shouldn't > > be replaced. Think of objects that do actions or hold data. They do not > > have any database-access etc. Actually they wrap downer code to make > > things more readable and easier to understand in the components and > > controllers. > > > These objects are in their own herachie and depend on the actual > > implementation and soon depend on at least the cake-models. They are > > compareable to components, but one should not implement them as ones. > > In my implementation I play with these objects in controllers and > > components. This produces very sweet code, I think ;-) > > > I think the app/vendor dir is quite suitable, but what I think is wrong > > with vendors is, that these objects and classes are absolutley > > project-related (at least the upper, precise ones). They depend on the > > intended usage. > > > What about these? still vendosr? I would place them in some sort of > > app/lib dir. > > > Thanks, > > > Thomas > > > On Dec 11, 6:58 pm, Felix Geisendörfer <[EMAIL PROTECTED]> wrote: > > > > Well to me this sounds like you'll simply have to add some refactoring > > > to your todo list and split up this code into some tasty Cake(PHP) > > > layers (MVC). Otherwise go with vendors. > > > > -- Felix Geisendörfer aka the_undefined > > > --------------------------http://www.thinkingphp.orghttp://www.fg-webdesign.de > > > > John David Anderson (_psychic_) wrote: > > > > > On Dec 11, 2006, at 10:45 AM, [EMAIL PROTECTED] wrote: > > > > >> Hi there, > > > > >> we are porting an existing php-application to cakephp. This goes quite > > > >> harmless so far => very good! > > > > >> But now we want to integrate some existing libs and includes of the > > > >> old > > > >> application into the cake-structure. But I do not know where to put > > > >> them. There are bussiness-logic-units, which are neither components, > > > >> nor models. > > > > >> They also hevily depend on the whole application, so > > > >> calling them a vendor-lib would'nt be right. > > > > > Why not? I guess we need a better idea of why vendors won't work. > > > > > The vendors directories are usually the best places to put this sort > > > > of stuff. > > > > > -- John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
