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, 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? I mean, class
inheritance is a well-established, core feature of PHP that makes
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.
- Jamie
On May 11, 9:02 am, AD7six <andydawso...@gmail.com> wrote:
> On May 11, 5:30 pm, keymaster <ad...@optionosophy.com> wrote:
>
>
>
>
>
> > > PS additional app paths and plugins don't solve the same problem.
>
> > Firstly, thanks for these responses. I appreciate it.
>
> > Plugins and Additional paths may not solve the same problem, I agree,
> > and that's sort of what I am trying to determine, ie. whether I should
> > keep all my code as additional paths, or reorganize it as a bunch of
> > plugins.
>
> > > I'm kind of scared what you've been up to if for you they are
> > > interchangable.
>
> > I have two main directories parallel to app/ called base_cms/ and
> > base_ecommerce/ , each containing several subfolders, as follows:
>
> > app/
>
> > base_cms/
> > ---------- accounts/
> > ---------- addresses/
> > ---------- admin_panel/
> > ---------- articles/
> > ---------- catalog/
> > ---------- configs/
> > ---------- filters/
> > ---------- comments/
> > ---------- images/
> > ---------- sitemaps/
>
> > base_ecommerce/
> > ---------- coupons/
> > ---------- orders/
> > ---------- partners/
> > ---------- payments/
> > ---------- products/
> > ---------- shipping/
>
> > cake/
> > vendors/
>
> I also used to (e.g. MiBase) do this and as I mentioned/implied in
> some circumstances still do (but not instead of using plugins).
>
>
>
>
>
>
>
> > Each of the subfolders contains one or even several base controllers,
> > components, models, behaviors, views, elements, helpers, etc. as a
> > group of closely knit functionality. All these files are base classes,
> > so they can (and are) extended at the app level to build any app for
> > any client.
>
> > For example, the accounts subfolder contains the base model classes:
> > BaseAccount, BaseAcountGroup, BaseAccountProfile, BaseAccountAddress,
> > etc. and all it's associated base controllers, views, elements,
> > behaviors, etc. I also have child Account, AccountGroup,
> > AccountProfile, AccountAddress models in the base accounts folder,
> > which are simple empty extensions of their Base parent files, and are
> > the files cake instantiates.
>
> > So in base_cms/accounts/:
>
> > BaseAccount extends AppModel - full of code.
> > Account extends BaseAccount - empty.
>
> You should really have there (or equivalent)
>
> Account extends AppModel {
> var $actsAs = array(
> // behavior with all public methods/functionality that currently
> exist in BaseAccount.
> 'Cms.Account' => array(...)
> )
>
> }
>
> > To override at app/ level for any client, I copy Account.php to app
> > level and have:
> > Account extends BaseAccount - override whatever functionality I want.
>
> Whenever you use copy and paste - IME you're on the road to
> maintainence hell. As has no doubt happened in the past 3 years -
>
> what do you do when you update the base model - and you want/need the
> update in your overriden (and therefore disassociated) model in a
> client project?
> OR
> what if a client doesn't want something that he's inheriting at all.
>
>
>
> > The app/Account.php is chosen by cake over the base_cms/accounts/
> > Account.php due to search path ordering.
>
> > When a new customer comes along, I add his unique code to app/, and
> > just extend/override much of the stuff in my base_cms/ and
> > base_ecommerce/ folders.
>
> > At the time I started this, it was not even possible for an app to
> > access aplugin'smodel, let alone have onepluginaccess another
> >plugin'smodels, so I took the additional paths approach.
>
> > It may be it is still the correct approach, andpluginusage should be
> > limited to app independant code. That's fine.
>
> The main benefit of plugins is that you can share the same code across
> different apps. e.g. you could create an accountingpluginand /
> outside/ of these 2 projects use it.
>
> From what you describe I'd:
> * move model code into behaviors
> * possibly do the same with controllers to components (especially if
> you've got a fat app controller or lots of protected/private
> controller functions)
> * create apluginfor each blob of atomic functionality (which most
> likely means folders you mentioned above) - if you deem it appropriate
> to do so.
>
> To me the first 2 points are more important than where your files are
> (which is essentially almost all it boils down to)
>
> hth,
>
> AD
>
>
>
> > It's now more than 3 years later,
>
> I think you only just missed plugins being easy to use. your post is
> really about 1.2.0 or before.
>
> > plugins are more powerful and
> > integrateable into the main app, so I was exploring whether my current
> > architecture is still correct, or I should be considering using
> > plugins instead of my current subfolder strategy.
>
> Try thinking about whatever development problems you've faced over the
> years working on this (and other?) apps - would plugins have helped
> you. I bet they would (if nothing else because it's a lot easier to
> test an isolatedpluginthan a mammoth of an application).
>
> hth,
>
> AD
>
> Check out the new CakePHP Questions sitehttp://cakeqs.organd 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
> athttp://groups.google.com/group/cake-php?hl=en
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
