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 :)
Believe it or not: It does. :)))
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----( )-------------------------
( ) (_/
\_)
signature.asc
Description: OpenPGP digital signature
