This is getting real interesting. Thanks AD7 and Martin.
>
> 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(...)
> )
>
> }
Why is inheriting functionality through a Behavior better than
inheriting from a parent Base class?
>
> Whenever you use copy and paste - IME you're on the road to
> maintainence hell.
>
No code is being copied, just an empty child class from base/ to app/.
Isn't that exactly the same as what we all do with the empty
AppController when we copy it to app/, then extend or override as
necessary?
>
> 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?
In app/ you do:
Class Account extends BaseAccount{
public function login(){
parent::login();
... any additional funcitonality we want.
}
}
> OR
> what if a client doesn't want something that he's inheriting at all.
>
How would using a behavior help here more than straight inheritance?
>
> The main benefit of plugins is that you can share the same code across
> different apps. e.g. you could create an accounting plugin and /
> outside/ of these 2 projects use it.
>
Why is a plugin better for sharing across apps than a subfolder of
base classes?
Just as I would include the plugin in the new app, I could just as
easily include the subfolder in the new app (assuming the code
contained the same things).
At least with the base classes, I can extend override them, and still
easily apply future bug fixes to the base classes. With a plugin I
would have to modify the plugin if I wanted it to behave differently,
and then I have a different version of the plugin floating around.
>
> 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 a plugin for 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)
>
Is your preference for getting functionality through behaviors/
components vs. inheriting from a base class, because of a "favor
composition over inheritance" thing?
>
> 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 isolated plugin than a mammoth of an application).
>
Why is an app comprised of 20 plugins less mammoth than an app
comprised of 20 subfolders (assuming the code in each subfolder is
identical to the code in each plugin, and the subfolders are as
decoupled from one another as the plugins are)?
I am really glad and appreciative of you taking so much time to
discuss these issues, AD7. You're experience is well known, as are
your numerous contributions to our community.
On May 11, 7:02 pm, AD7six <[email protected]> wrote:
> On May 11, 5:30 pm, keymaster <[email protected]> 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 a plugin's model, let alone have one plugin access another
> > plugin's models, so I took the additional paths approach.
>
> > It may be it is still the correct approach, and plugin usage 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 accounting plugin and /
> 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 a plugin for 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 isolated plugin than 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 [email protected]
> To unsubscribe from this group, send email to
> [email protected] 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 [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
