Thanks for the idea Mark, That's yet another way to manage naming in plugins.
/Martin On Dec 19, 9:33 pm, mark_story <[email protected]> wrote: > If you go with the $useDbConfig you can always have multiple database > connections connect to the same database and just implement different > prefixes. This gets around the need for multiple databases. > > var $pizza = array( > 'driver' => 'mysql', > 'connect' => 'mysql_connect', > 'host' => 'localhost', > 'login' => 'user', > 'password' => 'pass', > 'database' => 'my_app, > 'prefix' => 'pizza_' > ); > > For example would still connect to the same database as your app, but > would refer to all its tables via the pizza_ prefix. It also sounds > like a bad idea to have multiple plugins implementing different > users's tables. This will cause nothing but headaches. > > -Mark > > On Dec 19, 8:31 am, Martin Westin <[email protected]> wrote: > > > I am interested to hear how others handle names (of classes and > > therefore files) inside plugins. It has been up for discussion before > > but I still feel this is an area that could be brought to the front > > once more. > > > So, what's the problem? > > Anything you create in a plugin can (not will) conflict with something > > in another plugin or the main application. The main point of conflict > > as I see it the database. The other main problem I have is ugly urls. > > I also dislike classes and files named identically in the same > > project. Searching for the file message.php should ideally only give > > me a single file in a project. > > > I want to avoid manually specifying names (uses, usetable...) at each > > level of my application. I also want to avoid specifying custom routes > > for each and every possible plugin I might possibly have installed. > > > A quick run-down: > > The table-name relates to the Model-name which relates to the > > Controller-name which relates to the url. A database in MySQL (and I > > believe most other rdbms) can only handle a single table called > > "messages", a single table called users, and so on. Following the > > suggestions in the manual I can create tables like forum_messages, > > forum_users, webmail_messages and webmail_users. Problem is, now I > > have altered the names of everything all the way to the urls. > > > That's enough detail, I think. Now, how to avoid these problems? As > > you can imagine I would love to see a good idea implemented and > > supported in the core. But that is not going to happen over night, no > > matter how much I ask Santa. So we need a good plan that can be > > implemented in the core in the future and a quick-fix for now. > > Ideally, the two should be compatible. > > > What can be done? There are a few alternatives can see. All asume > > that we do some kind of prefixing with the plugin-name. (Using the old > > Pizza example here) > > > 1. Require special naming of controllers. pizza_orders_controller.php > > (like what is mentioned in the manual) > > > 2. Require special naming relationships between the controller and the > > model of a plugin. OrdersController uses PizzaOrder by default. > > > 3. Require special naming relationships between the model and the > > table. Order useTable pizza_orders by default. > > > 4. Requiring separate databases for each plugin. Generally a miserable > > idea but I chose mention it anyway. > > > So how would one go about these things? > > 1. This requires a bit of hacking in the core. The strong point is > > that this one would keep all files named "uniquely" and it would > > eliminate any problems with conflicting class-names. This would be a > > good official solution but is less suited to personal hacking. > > > 2. This requires some modification of the controller initialization. > > This might even be achieved in PluginAppController::beforeFilter(). I > > have not looked into this too closely but you loose the ability to do > > requestAction to an "identical" controller elsewhere. > > > 3. Similar to 2, this requires modification of the initialization of > > the model. Again, might be possible by using PluginAppModel to alter > > the "useTable" attribute. This way you loose the ability fo inherit or > > associate with an "identical" model elsewhere. A global User can not > > be accessed from a forum User which might be a problem sometimes. > > > 4. Just set the useDbConfig attribute in PluginAppModel and make sure > > you have a db config for each plugin... like stated above... a pretty > > miserable idea since most shared hosts will not allow you to have 5 or > > 10 databases for your single account. > > > For myself, I have so far chosen to make a very small alteration to > > dispatcher.php. My dispatcher adds an extra check when looking up the > > desired controller. Pseudo-code would be "If you are in a plugin and > > the controller is not found then try > > PluginnameControllernameController before abandoning the attempt. > > > + This gives me pretty urls and unique names of everything in the > > plugin. > > - This does not work with array notation or reverse routing of any > > kind. > > > It works pretty well for my needs but a more complete patch would be > > needed for a real implementation. I don't like to promote > > modifications to the core since they must be maintained and can easily > > affect (= break) things I never thought of. For the brave, there is a > > ticket about this where a few have contributed ideas for > > patches.https://trac.cakephp.org/ticket/4659 > > > If you, like me, treat plugins as one would in Photoshop or to make an > > application a bit modular you will sooner or later come upon some of > > these issues. I would like to see a constructive, open discussion of > > the pros and cons of different approaches. > > > Martin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
