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