On May 12, 8:08 am, Jamie <jamie....@gmail.com> wrote: > I wrote a CMS with CakePHP that uses much the same architecture. > There's a common core that's used by about 30 sites. The classes all > have a "Cms" prefix - CmsAppController, CmsAppModel, etc. The classes > on the individual sites (AppModel, etc.) all extend the core CMS > classes. They're all empty classes - the functionality is in the CMS > core. >If I want to override a function at the local level,
Keymaster - this is the circumstance I meant where if you fix something in your base/core code - you may have to copy-and-paste your fix to the client app. > I can. It > works quite well. The difference between my setup and yours, > keymaster, is that I use plugins instead of the 'additional paths' > setup you've implemented. Basically, there's a core version of each > plugin, again with Cms prefixes on all the classes. When someone > installs a plugin on an individual site, it creates empty classes that > extend those core classes. > > It's a handy setup if you're deploying a lot of websites with similar > functionality. Bugs only fixed in one place (the core), etc. I'm glad > to see I'm not the only one doing it. :) > > As for AD7six's suggestion to use behaviors instead of class > inheritance, I'm not really sure what benefit that brings to the > table. Maybe you can explain your rationale, AD? Just consider how easy it'd be if instead of the tree behavior cake had a TreeModel you extended. Of course, the tree behavior, as with most behaviors, is pretty generic whereas you're both looking at pretty rigid, predefined functionality you're inheriting as a base. > logical sense in keymaster's (and my) case. I don't have the benchmark > stats to prove it, but I'd think that loading a behavior and attaching > it to a class would be more resource-intensive than simply loading a > parent class. And Cake already makes good use of inheritance - our > AppController extends Controller, after all, it doesn't $actsAs > Controller. The thing is there's noting in a controller you don't want to inherit, and you can't extend Object and expect it to just work. I don't know your apps and I don't know your clients but the problem with using inheritance as your one weapon (I'm not saying you are) is what do you do when in ap project you don't want something you're inheriting. E.g. let's say in your CmsFoo model you've got an afterSave method that does <this> and <that>. Your client says "I don't want it to do <that> (e.g. send out notifications)". You can do that by overriding the afterSave method in your (App)Foo model to just do <this>. It's a simple example of course and there are lots of ways to solve it but if your base/core functionality is behavior based you don't include the behavior that does "<that>" and you're done. What's more if for some reason you want to temporarily disable <this> you detach the behavior and your model and application in general works fine without it. I think the most important thing to take away from this thread is you solve the right problem with the right tool in the right place - you might already be doing that because additional paths and plugins (and model -> behavior) solve different problems. Probably a good measure is lines of code. If you end up with less code by reorganizing i'ts most likely a good idea. If you're going to gain 0 - it's as academic as you currently perceive it to be - but know the tools/tecniques at your disposal (keymaster :) ) hth, AD Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
