I'd suggest that you check 'Log and debug messages' generated when debug is on. This is preety much how I've learned how all is executed.

documented on: 25 January 2007, pezetgee

> I would also like to see the program flow. This is mainly to understand how
> symfony works and learn from it!

a brief overview is given in the documentation:

http://www.symfony-project.org/book/trunk/06-Inside-the-Controller-Layer#The%20Front%20Controller's%20Job%20in%20Detail

documented on: 12 February 2007, francois

I suggest you install xdebug, it is a great extension not just for pretty-printing with var_dump(). It has a "trace" feature which logs into a specified directory every single call made by the PHP engine.

If you use that on the prod environment (therefore excluding all calls related to the web_debug toolbar), then you can read through the framework in a very informative way.

Some hints: My relevant config in php.ini:

zend_extension_ts="C:/PHP/ext/php_xdebug-2.0.0rc3-5.1.2.dll"
xdebug.remote_enable="On"
xdebug.auto_trace="On"
xdebug.trace_output_dir="E:\www\logs"

(Read the xdebug docs if necessary, that "remote_enable" gives you access to xdebug via a command-line client, you can step (by typing commands) through the calls.)

The output of that trace gets written to a file depending on the script called. With the MVC pattern and a single front controller this means it will get overwritten.The setting xdebug.trace_output_name in php.ini can be set to "timestamp". There might be a config option in xdebug to change this but I did not bother to find it so far. Call it in prod 1) with a clear cache and 2) with the cache files already generated and you will see great differences in the generated amount of lines! Wink

It is rather verbose, as _every_ engine call is logged! Get a scroll mouse ready! *g*

xdebug is a great way to inspect any kind of PHP code, especially if you didn't write it yourself. And if I as a PHP hobbyist can use it you professional coders will certainly find a good use for xdebug.

Play around a bit, and use the DBG-client, you will be amazed.

Edit: Here is a link to the documentation explaining which _additional_ functions Xdebug defines, so you can log only some parts of a PHP script: http://xdebug.org/docs-functions.php#tracing . The above php.ini settings slow down your application quite a lot — but you won't need it enabled al the times anyways.

I am thinking about how to grep for only user-defined functions/methods or such. If I could exclude all core function calls the trace would be a lot more symfony-specific.

documented on: 12 February 2007, cprior

> I am reading the paper book version at the moment and it does give the
> general overview. But I am looking for diagrams and source code to be able
> to really master and extend core classes.

Did you run doxygen over the symfony code yet? That is another informative way to "group information".

Because I personally don't find diagrams like http://seagullfiles.phpkitchen.com/images/PSG_WorkflowSm.gif to say that much at all, it is very general and does not teach me much about how to extend or where to plug into a framework. A basic MVC diagram is nice to grasp the pattern, and from then on I find the source code to be much more telling.

In my signature I link to my doxygen output. But I include pretty much all possible information, so a personal version might be better tailored to one's needs. The default config file that comes with the doxygen installation is a good start.

After stepping with xdebug through some of my symfony-installations I also realized _how_ _much_ a framework really does: For example the cache system, a diagram can hardly express the level of complexity without becoming too bloated (Think e.g. inheritance). So many if|else, so many different "environments", so many extended classes.

Anyhow, I don't want to argue diagrams, I am a visual person myself and they can indeed transport a lot of information. It's just that a deeper understanding requires going to "the source". Both Xdebug and doxygen are great tools for that and this thread should contain pointers to them.

The next step is then to compare the design of symfony woth other frameworks or question design decisions! *g* But that is above my understanding. I would think that using custom filters is a feature not many projects require. What might be condensed into a "visual" are the commonly customized aspects, like routing and a user-authentication plugin.

The old book contained some HowTos, their content is promised to be transformed into the cookbook part of the documentation. That might clarify a lot, once this doc-content is back. Right now the book is quite overwhelming for newcomers to the symfony framework.

Btw, the old howtos can be found on my docu-mirror, too! Wink Look at the 0.6.1 version http://cpr.in-berlin.de/mirror/symfony-project.org/symfony_doc_0.6.1

documented on: 12 February 2007, cprior