Actually, believe it or not, many of these issues did exist, but admittedly it was a very long time ago.
For example, it wasn't until late 2007 (Oct./Nov. timeframe if I remember correctly), that the ability for app code to access plugin models was introduced into the 1.2 branch through the use of the Plugin dot notation. Prior to that it was impossible. Not by oversight, but by intention. Plugins were intended to remain optional, decoupled code from the main app, and were not meant to be a means of organizing similiar functionality together. As an example of the feeling towards app organization/modularity back then, I actually dug up this comment by Gwoo (former Project Manager of cake) from late 2007: "Correct me if I am wrong, but it seems some are using plugins to organize parts of a larger application. To me, you are on a slippery slope here to basically negating the whole benefit of a plugin and just making it more work on yourself. Using the config/bootstrap.php to organize your MVC requires a lot less code and should yield the same benefits." That thread is here: http://groups.google.com/group/cake-php/browse_thread/thread/8526219c24ce3a8b/a97e9df193c75748?lnk=gst&q=between+plugins# So, you can see it was originally intended that plugins were not for organizing application code, only for sharing amongst developers. As a result there were several limitations to how apps could use, or more specifically could not use, plugins. While it's true that some plugins are optional and the app should not depend on them, other plugins might neeed to be an integral part of the app, containing code which was just separated off for the purpose of grouping closely knitted functionality together, within the larger app. In that sense, models in one plugin might need to have associations with models in another plugin. (eg. Order belongs to Account, or Order HABTM Warehouse, where accounts, orders, and warehouses are all in different plugins). The limitations back then (I believed based on discussions in this group, though I never tried it) prevented the use of plugins for grouping together functionality within the app. So, I and many other developers used the additional paths to group things together. At some point in cake v.1.2 a number of these limitations were removed, and in 1.3 yet more were removed. So, I'm wondering now that 1.3 is out, is there still a reason to organize apps using the additional paths in config/bootstrap? On May 11, 10:20 am, Martin Westin <[email protected]> wrote: > 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 <[email protected]> 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.organdhelp 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 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
