Some additions to the above
with this method you could use *all* classes in an extension to
inherit from in your app. (as long as they obey the conventions)
Also, you could "directly" integrate components,models,helpers,.. from
an extension like $uses=('CoolCakeUser','Post') in your app.
For controllers however we would need to add some functionality to the
cake core, so that it - just like in the way it can "recognize" when it
deals with extensions based on the proper classname and the $extensions
variable - would directly open the controller in the extension
directory, when you call an action like mysite.com/coolcake/users/index
Same goes for views. the cake core like it is now isn't prepared for
views residing in an extension, i would fix this by calling them by
$this->render('coolcake/users/view'); so that it can (again) simply
recognize you're dealing with an extension (based on the fact that you
use more then 2 things between slashes, and the first one happens to be
a string that "happens to be" in your $extensions array ;-) and open
the right file.
In conclusion:
advantages:
1) no performance hit ( i checked how cake core handles
$controllerPaths, working like that needs more filesystem calls then
this method)
2) easily swapping in/out/updating of 3rd party code/library
2 bis) ability to work with svn:externals
3) separation between code that is meant to do a specific thing
3) using 3rd party code like if it was inside your app (use them
directly or inherit from them)
disadvantages:
1) could impose conflicts in naming. But when you download code from a
3rd party and integrate them in your app, you have the same issues. I
proposed a solution for this which means your classnames will become a
little longer, but very recognizable for php code in the cake core.
This also requires a certain "discipline" of the 3rd party author (to
choose a unique name for an extension for example), discipline that is
otherwise a bit more neglected. We now have classes on the bakery
called "mailercontroller" , "protectorcomponent" or "userscontroller".
(i'm guilty of that last one) just to name a few. All classes that are
meant to be put in app directly, which gives a high risk of duplicate
classes . with the proposed conventions i think this would improve a
great deal.
2)fixing bugs that could be at several locations will be harder.
(..but writers of extensions shouln't release buggy code offcourse ;-)
obviously, my opinion is biassed, i really like my own idea. It woud
be great if i could convince cakephp devs to implement this, but if
don't... they probably have their reasons ;-) Although then i would
really like to hear those reasons.
if you guys think this idea is _not_ good, please explain why, i want
to think further about this, propose ideas and discuss.
If there is a solid argument about why this isn't good, i'll shut up
and be very glad i learned something.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
