Database Adapters in INI File
Locked
 
|
Hi,
I thought that something like resources.db.adapter = "PDO_MYSQL" resources.db.params.host = "localhost" resources.db.params.username = "user" resources.db.params.password = "user" resources.db.params.dbname = "database" guestbook.resources.db.adapter = "PDO_SQLITE" guestbook.resources.db.params.dbname = "guestbook.db" would work as I thought that the module specific initialization would take precedence over the general one. What would be the best way to achieve this? I don't want to fetch the correct adapter and do all the other manual setup any time I am instantiating a new class in a module. I prefer to have the module's database adapter override the default adapter. -- Cheers, \\|// Vince (o o) ----------------------------ooO-(_)-Ooo------------------------- ''' (o)_(o) [ ][0][ ] ô¿ô (=°o°=) World Domination by Copy and Paste [ ][ ][0] - (")_(") [0][0][0] () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Ooo. ---------------------------.ooO----( )------------------------- ( ) (_/ \_) |
signature.asc (202 bytes)
|
|
|
Hi,
keith Pope schrieb: >> resources.db.adapter = "PDO_MYSQL" >> guestbook.resources.db.adapter = "PDO_SQLITE" > You would probably need a FC plugin or action helper for this, > Zend_App works before the dispatching process therefore it does not > know what module is being requested, so if you are using zend db table > the default adapter is set in the main db resource etc. > Also I dont think the db resource will be called twice in this setup, > you will need to have a module specific resource that you create > yourself. Okay, but aren't the module resources intended to be module-specific extensions? At least I think that they should behave like that. If there isn't any drawback to this kind of usage we could even think of implementing this kind of "overriding" resources ... what do you think? That put aside, I thought to simply extend the module bootstrapper in order to take care of module specific setups. I currently already have a ModuleConfig resource which reads module specific config files and uses the data, but unfortunately - as far as I think I understood the new bootstrapping process - all modules will be read during the bootstrap process itself, which will lead to a "the latest config wins" scenario. This leads me to the conclusion that it is okay to read the module configuration from the config files during bootstrapping, but to ignore the config resources as long as the module isn't called. There comes your idea of a service layer into place, if I understood that correctly. So I guess I should write a fc plugin or action helper that will overwrite the application wide settings with the module specific settings. So if all this should sound reasonable: - Shall I choose a fc plugin or rather an action helper (and why ofc)? - Should I keep the application wide settings or should I overwrite the duplicate resources with the module settings? Thx in advance :) -- Cheers, \\|// Vince (o o) ----------------------------ooO-(_)-Ooo------------------------- ''' (o)_(o) [ ][0][ ] ô¿ô (=°o°=) World Domination by Copy and Paste [ ][ ][0] - (")_(") [0][0][0] () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Ooo. ---------------------------.ooO----( )------------------------- ( ) (_/ \_) |
|
|
In reply to this post by keith Pope-4
Hi,
keith Pope schrieb: >> If you are interested in the fixes that I had to make, just let me know. >> I always feel bad when bothering ppl too much - that's why I don't write >> them down here. :) > Any bug reports are much appreciated :) First I had to rename index.php.dist to index.php - no big deal. Next thing is that the .htaccess has to be modified like this: RewriteRule ^.*$ /index.php [NC,L] because otherwise it will loopback to itself depending on your web server setup - already mentioned that on IRC as it is wrong in the quickstart as well. Finally I had to add the get_include_path() in order to make all the Zend stuff accessible like this: $paths = array( realpath(dirname(__FILE__) . '/../library'), '.', get_include_path() ); I guess that was it basically ... > With your module problem, you are right that all modules are > bootstrapped on startup, so for runtime/dispatch aware config you need > to use another method like an FC plugin or Action Helper. Remember > though that the Zend_Application and all its resources are available > via the front controller, so you can still enter module specific in > your main app config file and access them later via the FC, its > getInvokeArg('bootstrap') I think, though I assume this is documented. I always thought that I am quite an experienced developer - but all this bootstrapping, plugging, helping etc sometimes simply lets me scratch my head, break down and cry ... :) Just to give you the right impression: I am a self-employed developer and doing this since almost 20 years - but I feel like a complete noob when it comes to ZF :) So bare with me if I should sound stupid - cuz I am trying to break it down to the maximal possible simplicity cuz asking simple stupid questions might hinder me from thinking to complex again (just dumped two years of development in favour of a "nicer" approach with 1.8 :() Did you have a look into the ModuleConfig resource yet? It now works at least that way that the module resource is used - I see the guestbook now. Your approach with the service level is for the moment to complicated for me to implement, thus I will try to find a way that I - and other beginners - could easily understand in order to give (almost) self-contained modules a try. As I cannot "overload" the db config as sketched in the initial mail (module.resource.db.dbname = ...), I need to keep the config for the module separately. The current approach with the ModuleConfig resource would allow me to do so ... At least I see now that I must *not* overwrite the application resources, as all modules are bootstrapped at once - by that the last resource would win. There your suggestion comes into play: fc plugin or action helper. Which would you do and why would you do it? I am always unsure whether to realize something this way or that or a complete other way ... > Me and Matthew did talk some time ago about the way Zend_App works and > he was looking at other ways of having module specific config etc, > that conversation should be on the list achieve somewhere. Do you have a date or some key words I might be able to search for? As modules are treated so "badly", there are not very many really *good* and sophisticated approaches towards this - and all I want is the input and insights of the *real* cracks in zf; I don't want to ruin another two years of coding due to bad design ... :P I wish you two had made a blog post about how to approach this - the right - future proof way :) > Also with the way Zend_App bootstraps: > > Main bootstrap is executed the class resources are executed first and > in the order they appear in your bootstrap class, then the plugin > resources are executed (db,routes,locale,etc). > Modules is a bootstrap plugin resources, so when this is called it > loads all the module specific bootstraps and executes them, Zend App > tracks which resources have been executed so nothing is called twice, > so I think if you use the db class resource it will only ever be > called once, you may want to test this by echoing something inside the > db resource so you know how may times it is being called. > Hope that makes sense :) So we will have all resources set up during bootstrap, but the database will be initialized only once ... that perfectly explains why I cannot easily override those parameters, thanks. From the top down point of view, I'd say: - I keep the module resources in the module bootstrap (with my current resource handling this) - The db (and other) bootstrap should be called when a module is "entered" - by this the parameters could be quietly injected How does that sound? Be honest ... :P Well, thank you very much so far - your input is the most precious one since I started from scratch ... and if you should prefer some instant messaging or other means of communication, please let me know ... -- Cheers, \\|// Vince (o o) ----------------------------ooO-(_)-Ooo------------------------- ''' (o)_(o) [ ][0][ ] ô¿ô (=°o°=) World Domination by Copy and Paste [ ][ ][0] - (")_(") [0][0][0] () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Ooo. ---------------------------.ooO----( )------------------------- ( ) (_/ \_) |
Loading...
| Powered by Nabble | Edit this page |