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 -~----------~----~----~----~------~----~------~--~---
