My experience tells me that almost all of your limitations did not exist even before 1.3
- plugins couldn't access or extend app's models They could. I did it regularly. - code in the app couldn't access a plugin's models They could. But I would not recommend doing it. (IMHO an app should not break when a plugin is missing) - plugin did not have callback capabilities in their appController like app did (eg. beforeFilter, etc.). They did. - plugin's views had no way of integrating with cake's theme'ing I don't know about themes at all so no comment. - plugin controllers couldn't be managed by Auth/ACL Auth: they could. ACL: no idea. The main gotcha I can think of is the dot notation for targeting plugins. Pizza.PizzaModel or Pizza.PizzaComponent and similar. I have an app that is made up almost entirely of plugins. Only login/ logout and statistics and reporting are the visible "features" residing in the core. The one hack I made to the 1.2 core was to let urls get a bit shorter by not requiring the namespacing part of controllers in plugins. / pizza/pizza_orders is messier than /pizza/orders But this was purely "cosmetic" to get prettier urls. On May 11, 7:57 am, keymaster <ad...@optionosophy.com> wrote: > In the past (cake 1.1, and to an extent cake 1.2) there were > limitations to plugins which prevented their use as a means of > modularizing your app's code. > > For example, > > - plugins couldn't access or extend app's models > - code in the app couldn't access a plugin's models > - plugin did not have callback capabilities in their appController > like app did (eg. beforeFilter, etc.). > - plugin's views had no way of integrating with cake's theme'ing > - plugin controllers couldn't be managed by Auth/ACL > - etc. > > The main reason is that plugins were not originally designed as a tool > for application modularity, but rather were for sharing functionality > across apps. So, there was originally no intent to have them integrate > fully into any app. > > As a result, many people avoided the use of plugins as a means of > modularizing their apps, and instead defined additional paths to all > the cake pieces using the variables for that purpose in config/ > bootstrap. This way, you could have full modularity without any of the > limitations of plugins. > > With all the good new development in plugins since cake 1.2 and 1.3, > in particular the ability to have js/css located inside the plugin > they apply to, I am musing over the possibility of converting all my > "additional paths" folders over to plugins. > > However, I am scared that I will trip over some unknown plugin > limitation which will become a showstopper. > > So the question is: in cake 1.3, are there still limitations to > plugins which native app code doesn't have, or are plugins for all > intents, fully considered as additional controllers/models/views to > the main app, and can integrate freely as any other app code can? > > 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
