On May 11, 2:25 pm, AD7six <andydawso...@gmail.com> wrote: > On May 11, 2:12 pm, keymaster <ad...@optionosophy.com> wrote: > > > > > > > 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/8526219c... > > > 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? > > I think it's safe to say that a quote from 2007 isn't fair > justification for not just trying it. I've used plugins almost as long > as they've existed and can't remember having any problems at all > worthy of 'holding back'. > > AD
PS additional app paths and plugins don't solve the same problem, I'm kind of scared what you've been up to if for you they are interchangable. For me additional app paths is for using exactly the same app with different css & a different db whilst maintaining one code base. even so the app contained only auth and user logic and a contact form - the rest was in a common plugin. 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
