Romain Dorgueil

php I see huge controllers ...

2011-09-05T00:00:00+02:00

As I'm lazy today, I will delay the python+wsgi tutorial a bit and finish an article I started months ago. I never took the time to publish it, but as I am re-reading it, I think it deserves it.

A commonly seen web application architecture.

So at that time, I was working for a client which needed some help to make one project live. The project was 90% done, and it was written using symfony (1.4).

It was pretty small-sized: about 10 symfony modules (maybe fewer) and a two part model layer having a doctrine-mapped tiny database, and a kind of facade to Facebook APIs.

But surprisingly enough, a project this small contained a lot of complexity, duplicates, misplacement ...

The project was about functionnal, just needed a "final polish" from a user perspective, and some little missing features, but not huge of a deal.

On the other hand, the application was a hell to read, understand, and maintain already. Even before it went live.

The direct consequence of this is to make each subsequent development longer, and thus more expensive. The less-seen consequence is also to exhaust developpers because it make them feel unproductive. And you don't want your team to be exhausted. Never.

So please, please, please, think about the project lifetime when you're doing development. And even more important, show respect to your present and future coworkers, and thus to yourself ...

Huge controllers

It should be pretty obvious to anybody, but I'm pretty sure all you have experienced this.

People tend to see controller methods as bins they can put any code in. They will just think "Hey, I'm pragmatic, and this works. Yay, kudos from my manager.".

That's for sure a pragmatic way to get kudos at first.

The fact is that the "you're wrong" part is completely invisible to your manager. And one day he wants to go live with his project.

The problems are coming now.

Manager: "Hey the app is slow, speed it up."

Dev: "Well I guess the model calls are getting long, it's doctrine fault."

M.: "Ok fix it."

D.: "Well, I'll have to go through all the controllers, change all calls ... It'll take one week at least."

M.: "Change controllers to fix the model? Huhu... I guess I missed something but hey, you're the pro, go ahead."

Then the developper takes two week to vaguely fix some calls, cache some really long request ... What I'd call "hide problems under the carpet".

But when you go live again, you just notice that only half the model problems are fixed. Woops, it happened that this famous model code in controllers was in fact present in quite a bunch of controllers, and the developper missed some.

And now we're starting to spot the exact same problem with some SOAP calls ...

Of course at the very last, you will end up fixing the app, at least enough for it to survive the ridiculous amount of target traffic, but the overall problem is not there ...

So let me recall some base principles.

One place for each stuff, and each stuff at the right place

Sounds idiomatic, but...

Model logic goes into the model.

The "model" layer is a facade that provides you with a business data access and manipulation API.

Write the API once, and then use it. Said simplier, you're not allowed to access data by anyelse mean. May it be database, SOAP/REST calls, or some other remote service providing some data to you (like Facebook) ...

Let me say it again, it's FORBIDDEN. Thinking of this «shortcut» as a way to speed development up is just stupid.

Organize your model layer

One big misconception a lot of people have is to think as their favorite ORM as the model layer of their project. Yes the ORM is a part of the model layer, but it's not necessary the whole model layer. You're allowed and encouraged to add proxies and facades in it, providing a nice, clean, and documented public API.

In an ideal world, the whole "data access" mechanism should be hidden and only a documented chosen subset of the model API should be used in your controllers.

Group features by concerns

You have plenty of tools to do this that are pretty much language/framework specific. In symfony (1), you have applications, modules, plugins ...

Take 5 minutes to think of the right place to do something, you'll save 10 minutes a day forever. Repeat.

Don't repeat yourself

What? This one again?

Yes, but I'll reword.

You're not allowed to have the same code, or same logic twice.

Let me give you some methodology for this. First of all, you must be familiar with your project, and know the codebase. You will obvsiously write duplicate logic if you are not.

If you're not familiar with the codebase, talk a lot, communicate, ask stupid questions to people around, ask again, grep the code ... In short, find a way to fill your knowledge gap.

If you're familiar with the codebase, then you know that the logic you're writing is already somewhere else. Unless the "elsewhere" code is useable to solve your problem without changing anything, go ahead and write the logic fast and dirty wherever you want, until you get it working.

Now is the time to refactor.

"There are two different times to do something. Now, and later. Later will in fact be never, 95% of the time."

So do it NOW, or it'll never be done.

Take the two code snippets, think of what ideal place this shoud go, what ideal API you want to use to do it ... And refactor now.

By the way it's a great time to add up some doc. Just a bit, just enough. What is this method, what is the input, what is the output. It should not take more than one minute, and this is API part, so you need to understand how it works at a glance.

The whole thing took maybe 10 minutes more than if you left duplicate code, and saved a lot of maintenance time ... An infinite maintenance time.

There should be one-- and preferably only one --obvious way to do it.

The Zen of Python, by Tim Peters

So ?

This article was written looking at a symfony project, but I'm pretty certain it can apply to all PHP projects, and by extend to all web projects designed under an MVC-like architecture.

May it be Python, Java, Ruby or anything ... The general idea is not language specific, even if you may have language specific ways to do the underlying stuff.

If you allow yourself to bypass the "let's do it clean" part, then you're not building web software, you're overcooking spaghettis (and you even forgot the salt).

«Beurk».

python Give your WSGI application super-powers

2011-08-29T00:00:00+02:00

I agree that our last week "Hello World" application was not very impressive.

In fact I don't think any "Hello World" can be impressive at all, unless it has some mighty not-hello-world-at-all features.

Let's sum up what we have so far. We have a python script, that spawns a webserver on port 2222 and answers HTTP requests saying hello.

For a ten line script, it's not so bad, but still hello-word-ish.

Baah.

About middlewares

This diagram is part of the Pylons Project documentation

WSGI introduce the concept of "middlewares" (Les wares du milieu).

It is, like WSGI, a very simple concept. As all your WSGI applications have the same prototype, it's very easy to create decorators that would be reusable WSGI application enhancers.

The picture on right, which comes from the Pylons framework documentation, explain it graphically. Of course the layers presented here are only an example from the said framework, and your setup is only limited by your immagination.

This is not unique to python, nor revolutionnary. The "middleware" concept is pretty similar to ruby's rack or to symfony's filter chain.

The most amazing middleware ever: ajax interactive debugger

Let me introduce a new friend, weberror.

At a first glance, weberror interface may look like any other stack trace dumper from <insert-your-favorite-language-or-framework-here>.

Read stack trace ...

Look at environment ...

Show me the source ...

But if you take a few seconds to explore it, you will get why it's 100 times more powerfull. The huge difference is that you can expand a frame (using the little plus icon) to get an interactive python interpreter in the context of the stack frame.

Type some python ...

Feel like you're within your application.

This is great, but looks like a hell to integrate in some home-made application... Actually it is not! Weberror contains a WSGI middleware that will enpower any WSGI compliant application with its features. Let's add it to our last week's application.

from webob import Response as HttpResponse
from webob.dec import wsgify
from weberror.evalexception import EvalException as AjaxDebuggerMiddleware

@wsgify
def application(request):
    if request.path_info == '/error':
        raise Exception('Guess what, an error happened!')

    return HttpResponse('Hello, debuggable world at %s.' % request.path_info)

application = AjaxDebuggerMiddleware(application)

if __name__ == '__main__':
    from gevent import wsgi
    wsgi.WSGIServer(('', 2222), application, spawn=None).serve_forever()

Note that the feature costs 2 line of python (one import, and the decoration of our original app). We added 2 more lines to raise an error if the URL is /error.

Please note that doing this opens a huge backdoor in your application, as any uncaught exception will give the http client a python shell on your box. Be responsible with what you're doing, or you'll have problems. Huge ones.

To avoid the usual mistake of running the app bundled with the debugger unless we really want to, let's add a --debug command line option that enables it.

We are using optparse module which is deprecated as of Python 2.7. You should consider using the argparse module if you're using a recent Python version.

from webob import Response as HttpResponse
from webob.dec import wsgify

@wsgify
def application(request):
    if request.path_info == '/error':
        raise Exception('Guess what, an error happened!')

    return HttpResponse('Hello, debuggable world at %s.' % request.path_info)

if __name__ == '__main__':
    from gevent import wsgi
    from optparse import OptionParser

    parser = OptionParser()
    parser.add_option("-D", "--debug", dest="debug", action="store_true",
            default=False, help="activate the interactive web debugger")

    options, args = parser.parse_args()

    if options.debug:
        from weberror.evalexception import EvalException as AjaxDebuggerMiddleware
        application = AjaxDebuggerMiddleware(application)

    wsgi.WSGIServer(('', 2222), application, spawn=None).serve_forever()

You can now try the new features.

$ python middleware2.py --help
Usage: middleware2.py [options]

Options:
  -h, --help   show this help message and exit
  -D, --debug  activate the interactive web debugger

Ok, and now what ?

Now you've seen one of the most stunning middleware that exists, let's think of other cool usage our framework may need. Note that I'm not claiming all of those features are actually good ideas to be implemented as middleware, but they are implementable this way.

Middlewares can intercept requests ...
- One can route requests between several WSGI applications (subdomains ?)
- One can handle HTTP cache using HTTP headers. If a cached version is there, the request won't go to the next WSGI layer.
Middlewares can intercept outgoing stuff ...
- One can consider logging unhandled errors on a prod server, or even sending mails about them.
- One can look at the request Accept header and provide content type adapters for unacceptable types. You don't know about XML ? Let me present you an HTML view of this file.
Middlewares can put additionnal informations in the WSGI environment dict.
- One can handle session storage/loading.
And much more ...

The drawback of using middlewares is that it adds complexity to your application factory (the callable responsible for building the wsgi app).

As soon as you want to switch components painlessly, middlewares are starting to get in your way. You probably won't ever change the debugger, only enable or disable it, so the middleware solution is fine.

But what about session handling for example ? Or cache backends ? It's completely possible to use middlewares, and you may have a look at beaker that contains middlewares for caching and sessions.

However, we'll add those features using a much more flexible technique very soon.

python WSGI, the first steps

2011-08-22T00:00:00+02:00

Building web apps in python is quite a lot of fun, and so I decided to write a little micro-framework from scratch. Today we will only think about interface with the webserver, using WSGI.

WSGI is the de-facto standard to interface a web application with a server (also known as "gateway"). You may read the PEP 3333 to learn more about it, but here I want to go straight to building a little wsgi app.

WSGI applications have an onion architecture. The application is in the middle, the webserver is outside, and a certain number of middlewares inbetween can gives your application extra super-powers.

Get your environment ready

To build our application, we'll use a virtual environment to isolate our experiments.

Let's install some packages. Depending on your system, python-pip may be not available and python-setuptools will replace it well (you'll need to use easy_install instead of pip to install python packages, but this is outside the scope of this blog post).

    $ sudo apt-get install python-virtualenv python python-pip build-essential libevent-dev python-dev
    $ mkdir wsgi-test
    $ cd wsgi-test
    $ virtualenv --no-site-packages wsgi-test.env
    $ . wsgi-test.env/bin/activate
    $ pip install webob weberror gevent

This article has been written using python 2.6, but should be ok for python>=2.5. It probably needs some adjustements for python>=3.0

First application

A WSGI application is basically a python callable which takes some parameters and returns an iterator on the response body parts. The input parameters are an environment dict, and a start_response callable which you'll call to start sending the headers.

Let's write the first app.

def wsgi_app(environ, start_response):
    start_response('200 OK', [])
    return ['Hello, little world.']

if __name__ == '__main__':
    from gevent import wsgi
    wsgi.WSGIServer(('', 2222), wsgi_app, spawn=None).serve_forever()

This app is a bit minimalist, but it works. You can run the file and check http://localhost:2222/.

We're using gevent to embed a webserver in our application because it's fast and easy. Almost every webserver have WSGI support, either builtin or using extensions, so you can switch to whatever you like. Using Apache for example, you can run your application using mod_wsgi. Configuring a web server is out of this article's scope.

Getting programmer friendly

Of course, it's always annoying to talk raw WSGI. You will forget some headers, behave badly, kill people around you ... But we have installed a tool that will transform the environ dict into a nicely formated python object.

Let me introduce my good friend webob.

from webob import ( Request as HttpRequest,
                    Response as HttpResponse )

def wsgi_app(environ, start_response):
    # Create request from WSGI environment.
    request = HttpRequest(environ=environ)

    # A real app would look at the request before giving blind answers.

    # Create a response
    response = HttpResponse('Hello, better world.')

    # Communicate
    start_response(response.status, response.headerlist)
    return response.body

if __name__ == '__main__':
    from gevent import wsgi
    wsgi.WSGIServer(('', 2222), wsgi_app, spawn=None).serve_forever()

This is a bit better. But hey, we can then separate the WSGI stuff, and the request-to-response process.

from webob import ( Request as HttpRequest,
                    Response as HttpResponse )

def web_app(request):
    return HttpResponse('Hello, nice world at %s.' % request.path_info)

def wsgi_app(environ, start_response):
    # Create the request
    request = HttpRequest(environ=environ)

    # Build a response from this request
    response = web_app(request)

    # Communicate with gateway
    start_response(response.status, response.headerlist)
    return response.body

if __name__ == '__main__':
    from gevent import wsgi
    wsgi.WSGIServer(('', 2222), wsgi_app, spawn=None).serve_forever()

Pythonize it

The good news is that the webob library includes a decorator that is able to turn any request-taking/response-returning python callable in a WSGI-capable callable.

The last version of this program, which does nothing more than the last one, follows.

from webob import Response as HttpResponse
from webob.dec import wsgify

@wsgify
def app(request):
    return HttpResponse('Hello, short world at %s.' % request.path_info)

if __name__ == '__main__':
    from gevent import wsgi
    wsgi.WSGIServer(('', 2222), app, spawn=None).serve_forever()

This is all for today, but there is a lot more to come so stay tuned.

Related informations

life Champagne!

2011-08-20T00:00:00+02:00

After a few years of thinking and about one year of getting things ready, I'm glad to announce that my company is up since 1st of August.

I will be doing a lot of things, but for the public part it's mostly around git/sf2/python training and consulting. You can contact me for more informations.

dynamics The end of Dynamics

2011-08-19T00:00:00+02:00

For a few months, I did not have time to enhance dynamics. I'm currently building up some exciting projects and this leaves me a very few time to invest in "just-for-fun" stuff.

Additionaly, the excellent assetic library (included in Symfony2 standard distribution) does a very similar job (still I'm not sure it knows anything about dependencies), but in a much more powerfull way. There is plenty of gadgets and fancy stuff all around, and I'm sure you'll enjoy it.

So hereby I decided to make official the end of my involvement in sfDynamicsPlugin.

The documentation website will stay up, but don't expect anything to come out. Of course I cleaned up some blog articles about the dynamics releases, because they became completely useless.

R.I.P.

08/23/2011 update

I got some e-mail and real life comments, so I'd like to clarify some points.

For those who wonders, the code won't magically stop working because of my decision. It has been stable for a long period of time, and if you considered it safe to use yesterday, it is still today.
I also just pushed the "never-finished-1.0"-code to github, which is plain nodeps PHP. You'll find drafts of frameworks adapters in the contrib directory (only sf1 adapter actually works). If it can be of any use, feel free to do whatever you please with it. You'll find the generated documentation (same state as lib) under an obscure hidden directory on the dynamics website.
If someone thinks dynamics is enough usefull to deserve it and want to take over the project, I'll be glad to help.

database Handling empty WHERE IN clauses in DBALs

2011-01-10T00:00:00+01:00

I recently had a look at a project making heavy use of IN clauses. I'm not advocating such an usage, as IN clauses can be pretty expensive, but there's one special case that came to my concern. This case is the most trivial one in the world, where the set we compare our value to is empty.

Doctrine is translating empty ->whereIn() clauses to exactly nothing, resulting in having the pseudo request SELECT * FROM user WHERE login in (); into SELECT * FROM user;. In my opinion, it's the exact opposite of what you expect.

<?php
$q = Doctrine_Core::getTable('Fruit')
        ->where('color = ?', $color)
        ->whereIn('country', $countries)
        ->execute();

This little snippet is getting a collection of fruits of a given color, and coming from a list of countries. Actually, if the country list is empty, it will return the whole list of fruits of $color, completely skipping the country part.

I wondered a bit why this was, and talked some guys about it with who we agreed it is a little weird. x IN () is invalid SQL, but deleting the clause to avoid the error is not a solution.

After a little chat about it with Jonathan, I decided to look some other ORMs around, written in various languages. I already knew how Propel do handle the problem, but I wanted to see other languages doing it. I opened SQLAlchemy and django.db in Python and RubyOnRails / ARel in Ruby, to see what solution they did adopt.

The fun stuff is that they all used different solutions, so I thought it was an interesting point to share.

Understanding the problem

The problem is not as easy at it may seem.

The x IN y statement can be nested in a complex expression, an it can also be in a subquery used in a more complex query.

For a simple SELECT * FROM user WHERE user.id IN (), you can be pretty certain that the query won't return any result, and you should be able to programmatically skip the query, as the logic of "Give the users which ids are within this empty set" is of course easilly simplified to "Give me no users please".

But for complex queries, you must replace this invalid SQL part by something equivalent, to allow its usage within a superquery, or other complex statement. This is what the majority of the ORMs out there are doing, except for django which also has an elegant solution.

The quick and dirty hack - Propel 1.2/1.3

I know it was done this way some years ago and did not want to investigate what is done in recent version of Propel. If some of you have the code examples, I'll be glad to add Propel 1.5/1.6 examples.

Propel does one of the simplest stuff. It replaces the a IN () part by 1 <> 1. Of course this will be false, and even if it's "hackish", it works.

It's important to note the result of 1<>1 in SQL, which is 0 (or maybe false, depending on implementations).

mysql> SELECT 1<>1;
+------+
| 1<>1 |
+------+
|    0 |
+------+
1 row in set (0.00 sec)

SQLAlchemy's solution

SQLAlchemy, a very popular and very powerfull python ORM, is doing yet another hack of the same kind.

What is great is that even if the part handling this case is hard to find, the code itselfs consist about only of comments, so anybody can get it easily.

if len(args) == 0:

    # Special case handling for empty IN's, behave like
    # comparison against zero row selectable.  We use != to
    # build the contradiction as it handles NULL values
    # appropriately, i.e. "not (x IN ())" should not return NULL
    # values for x.

    util.warn('The IN-predicate on "%s" was invoked with an '
              'empty sequence. This results in a '
              'contradiction, which nonetheless can be '
              'expensive to evaluate.  Consider alternative '
              'strategies for improved performance.' % self)
    return self != self

The a IN () statement part is translated to a <> a. What it does change from the other hacks, is that the result value will be different wether a is defined or not.

mysql> SELECT 42 <> 42;
+----------+
| 42 <> 42 |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

mysql> SELECT null <> 42;
+------------+
| null <> 42 |
+------------+
|       NULL |
+------------+
1 row in set (0.00 sec)

It looks interesting, but I'm wondering if it's an accurate mimic of the desired behaviour. We'll discuss this in the last chapter of this article.

The pythonic way - django.db

Django is the one that makes the less magic possible happen.

It's easy, it does not translate the code into anything, it remains the invalid x IN (). As the RDBMS won't be happy with this, it'll raise an exection. Same behavior for SQL and ORM, nice and damn fuckin simple.

return ('%s IN (%s)' % (field_sql, ', '.join(repeat('%s', len(params)))),

And the latest Ruby on Rails development does the same

Since I started to write this article, this commit changed the way it's handled in RoR, and it's now doing the same stuff as Django.

It tried to do clever stuff before, and that was just "looking" clever, so I'm pretty glad they changed this. If you're curious, you can read the new and old code.

As you may know, RubyOnRails has a relational algebra library named ARel, that is able to parse a ruby query into an abstract syntax tree, and then compile it into any query language, most probably some kind of SQL, but you can write visitors to produce about anything.

module Arel
  module Visitors
    class ToSql < Arel::Visitors::Visitor

      # ... TRUNCATED ...

      def visit_Arel_Nodes_In o
        "#{visit o.left} IN (#{visit o.right})"
      end

      # ... TRUNCATED ...

    end
  end
end

The (true, false, unknown) algebra

To understand all ORMs' solutions, we need to understand what NULL means.

What makes difference between everything here is that relational database engines uses a ternary logic algebra instead of the regular boole's algebra to evaluate logic statements.

There are true values, false values, and unknown values. Logic tables are so enhanced to use those "new" logical values.

For example, true AND unknown is unknown, because the evaluation of the right operand is required to know the expression's value. On the other hand, false AND unknown is false, because false and anything is false. No need to know the value of the right operand to know this.

Looking at the following truth table will give you a good insight of this logic.

A	B	A OR B	A AND B	NOT A
True	True	True	True	False
True	Unknown	True	Unknown	False
True	False	True	False	False
Unknown	True	True	Unknown	Unknown
Unknown	Unknown	Unknown	Unknown	Unknown
Unknown	False	Unknown	False	Unknown
False	True	True	False	True
False	Unknown	Unknown	False	True
False	False	False	False	True

Source: wikipedia, "ternary logic" article.

Conclusion

The only conclusion I can come to is that amongst the ORMs I looked at, Django and RoR are obviously correct. Funny right? The only ones who are correct are the ones which did not try to do anything clever or complicated.

Strangely, the Propel hack seems to be correct too, but I'd like to have some comments from database experts out there, because I'm still not 100% certain about two points.

Is my ( Unknown IN () ) == false assertion correct? I'm assuming that if your question is "Is this value present in this set, which is empty ?", the answer is "Definately not", and not "I don't know", whether or not you know the value of "this". The doubt is in "can this unknown be nothing at all"?
Does the concept of "empty tuple" makes an sense at all, from a relational algebra point of view?

the roots HTTP is the web's language

2010-01-24T00:00:00+01:00

Everybody working in web development knows about this, right?

I realized recently that it was far from being true. While frameworks and ORMs make web developers' job easier and easier, more and more people comes to develop websites without knowing about the real basics. They use relational databases without knowing anything about SQL, and they develop websites without understanding how the client will talk with their website.

I don't pretend to make a revolution there, but if I bring my car to the car mechanic, I hope he will know a bit more about it than "engine makes power, and so the car is working". So are my exigences when I ask a specialist to work on a website.

To give a parallel with playing music, you can learn to play some songs without knowing anything about harmony and rhythm, but is you want to get serious about what you play, it will become an absolute requirement.

I so decided to make some short articles explaining in simple terms what those basis are, to my humble opinion. First one is about HTTP.

So what is HTTP ?

HTTP is a communication protocol that comes at application level. In easier terms, it means that it's a language that allows two applications to communicate by exchanging messages. How those messages will transit between the two applications is not HTTP purpose, and in a network-less world, you can even imagine exchanging messages on floppy drives. In the real world, we prefer make it transit over networks, using some low levels network protocols like TCP/IP.

As it's true 99% of the time, we will assume it's always true: HTTP is the communication language, TCP/IP will handle the transport of HTTP messages between actors.

Let's go back to the original definition.

HTTP 1.1 (the last protocol version) is defined by RFC 2616, which says: The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World-Wide Web global information initiative since 1990.

...

The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content.

This is the absolute minimum to know. HTTP is a communication language, and works in a request-message, response-message way. This is extremely simple. The RFC then explain that it can do much more complicated things, like handling messages that will go through many nodes before reaching destination, but let's keep it simple, and say that from a client or server point of view, it will result in exactly the same thing.

The RFC also makes clear that HTTP is not dependent on the transport mean:

HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.

And it will be out of the scope of this blog post too. HTTP doesn't care about how the message transport is done, but it's usually handled by TCP/IP.

Messages, requests, responses

So the basic communication tool will be messages. A client to server message is called a request, and the server to client "answer" is called a response. Even if it may seems obvious, a response cannot be the server initiative: a client must have made a request, and server response is the response to this request.

Now we're pretty confident about HTTP messages being Tupperware boxes containing informations. Let's make a step forward and look at how this box content is structured.

Messages consists of three parts: the start line, the headers, and the body. As each part has specific rules depending on if the message is a request or a response, we'll have a look at both separately.

The request

The request start line is pretty easy to understand, it will tell the server what we are requesting.

GET /path/to/file/index.html HTTP/1.0

Here it tells we're using HTTP GET method, to retrieve resource located at the /path/to/file/index.html URI (uniform resource identifier). It also contains what protocol variant we're using, to be sure we speak the exact same language.

I will come back a bit later on what are HTTP methods, and will refer them as "methods" from now on.

After this, the client will send the headers. Headers are a key-value list of properties, that transmit various informations about the client, it's capabilities, what it's expecting, and the message itself. I won't go over every standard request headers.

Depending on what method is used, the request's body may or may not contain data. For example, if we simply get google's homepage, it won't contain any data. If we're uploading a file, or POST-ing form data to the server, the body will be those data container.

The response

Once server received the request, it will pass it to a handler, which can be about anything. In PHP applications, hosted on an apache server, chances are that apache will call mod_php to handle the request, and build a response it will send back to the client. But that's only one possibility amongst a huge infinite list, which is outside the scope of this blog post.

Anyway, the handler takes an http request as its input, and builds an http response, starting by the response start line.

HTTP/1.0 200 OK

This is a pretty standard response. Server starts by saying which protocol variant it's using, then sends a computer readable status code, followed by an human readable translation of this status code.

A complete list of HTTP status codes is available at many places on the internet, and it's useless to know them all. Googling "http status code" when you're looking for the adequate status should be far enough.

The most important thing to know is the different status code classes, defined by the first digit of the code:

1xx: Informational - Request received, continuing process.
2xx: Success - The action was successfully received, understood, and accepted.
3xx: Redirection - Further action must be taken in order to complete the request.
4xx: Client Error - The request contains bad syntax or cannot be fulfilled.
5xx: Server Error - The server failed to fulfill an apparently valid request.

Some practical direct application of this is when you need to choose between sending back a 404 error and a 500 error. 404 is client's fault. He asked for something that does not exist, and you tell him so. No problem. 500 means that server tried hard to build a response, but something forbid it to achieve its goal. This is a server-side application problem, and you should monitor, and correct this as soon as possible.

After sending the start line, the response, being a faithful HTTP message, will go on by sending the headers. Like for the request, headers will give informations about the server and the message content. You can consider it as the README file that will help the user agent (http client software) to understand the response.

Then, the response message will often contain a body (unless you're using some method requiring not to have it), and the most seen cases are either HTML content, XML/JSON (or similar) response that will be treated by a client-side web application (flash, javascript, ...), or binary content (for a file download, for example).

HTTP methods

What is it? Beside being one word in the request start line, the HTTP method is the client's way to tell the server what kind of operation it wants to perform on the resource requested. The method used in a request have direct implications on what kind of work you can do server-side, and should be choosen carefully (of course, you can break this rule, but it's a very bad idea).

Safe methods

Some methods are said "safe". This means that request is a retrieval operation, and should not do any other work. Notice that "should" does not mean "must", but user cannot be held responsible for breaking something if the method used was "safe".

For example, you should not allow GET methods to create, delete or change files, database records, or LDAP nodes (non exhaustive, of course).

This is the case of GET and HEAD methods.

Idempotent methods

Idempotents methods are those which won't have any side-effect if repeated more than once.

For example, the DELETE method, which asks for a resource deletion, should have the exact same effect if it's called only once on resource A, or if it's called ten times. The overall effect should be the resource deletion (if allowed), not less, not more.

This is the case of GET, HEAD, PUT and DELETE methods.

Non-safe and non-idempotent methods

But of course, some requests needs to take risky and/or non-repeatable actions server side. When an user agent uses such a method, he will be aware of the risks.

For example, POST-ing a comment will create a database record, and if you make twice the same request (unless some protection has been developed to prevent this), you will actually create two database records.

It's the exact reason why browsers ask for user confirmation before repeating a POST request, if user asks for a refresh. It's also the reason why you should redirect to a safe idempotent resource after a successful form submission, to forbid user to be able to repeat request.

This is the case of POST method.

And the real world

All those methods are defined by the HTTP RFC, but the real world is much more restricted than that. In fact, modern browsers only support GET and POST methods, so you should only care about those.

You should just keep in mind that other HTTP methods exist, and for example HTTP extensions like WebDav (which is used by microsoft and their "online folders") use them. A simple way to try out PUT, DELETE, or any other method is to use curl as an http client.

To learn more about specificities of all methods, you can still refer to the original RFC.

Example

The request...

GET /index.html HTTP/1.1
Host: www.example.com

Nothing complicated here, but for curious people (and you should be curious):

example.com is a special domain reserved by the RFC 2606. This domain won't bring any conflict with a real domain, never. You should use it for all your tests and examples.
The "Host" header is required by HTTP 1.1 protocol, and is used by web servers to provide name based virtual hosting of different websites on the same IP address.

and the response!

HTTP/1.1 200 OK
Date: Sun, 24 Jan 2010 22:38:34 GMT
Server: Apache (Boubounetout/Linux)
Last-Modified: Fri, 01 Jan 2010 23:11:55 GMT
Etag: "f3f80-1b6-de1b034b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8

<html>
  <head></head>
  <body>
    <h1>Welcome</h1>
    <p>Hello, world!</p>
  </body>
</html>

Conclusion

I hope that I'm far from being alone claiming that this is the very basis of any serious web development, and that it will makes your web developer life easier just because you understand the underlying communication language. Yes, HTTP is definitely the web's language, and you should be aware of it.

Ok folks, this will be all for today. But keep tuned, next episodes are already in the pipes.

Thanks to Bertrand Zuchuat for giving feedback and ideas before the article publication.

software All about backward compatibility...

2009-09-23T00:00:00+02:00

Backward compatibility sounds nice, but it's not so easy to respect it in big projects. And the whole interest is on big projects: it's maybe not such a problem if your grand-ma's blog breaks its API on each release, but there would be a revolution (or not?) if win32 API was changing on each ~~enslavement~~ service pack microsoft releases.

Here is a real story case study of a BC break that happened on the PHP language itself.

It's always tempting to say «hey, this feature is so great, and has so little impact on the way it works, it may be cool to include it it the stable branch, don't you think?». Well, it can be cool, if it cannot have any effect on existing projects. But let's think again. How can it have no effect on the existing projects? And if it has no effect, why include it in this branch?

I don't think there is a definite answer to this, as it may have pros sometimes. But most of the time, it will have much more cons than pros. And if you doubt, forget it. Bigger is the project you work in, more it will have users depending on it, and if there is any way users could have used the old "buggy" feature, for sure they did.

I want to expose some real life case that happened recently, on the PHP distribution itself, showing its snowball effect through symfony to real life projects.

Let's have a look at this php bug report. It says «spl_autoload_functions() should return object instances, not class names, when appropriate.»

Two words are really interesting in this bug report. It is "should" and "when appropriate". There is many assumptions behind this. When is this "appropriate"? Why "should" it return instances? I would better rephrase it as «Feature request: spl_autoload_functions() must return object instances, as it is more appropriate than strings containing class names.». The overall formulation is not so much important as the facts that:

It is a feature request, not a bug
The function is currently working, but its behaviour can be changed to a more convenient one.

But it's ok, right? The target version was 5.3 while still no stable releases existed.

Yes it is.

Oh wait, let's read the comments now.

«Thanks for the fix. Do you think, by any chance, we can sneak this into PHP 5.2, or is that impossible?»

The definite answer to this question should be «It is actually impossible. Introducing a behavior change into 5.2 (years) stable release would break backward compatibility.»

And the patch made it to PHP 5.2.11.

Is there any consequences? Yes of course. In fact any symfony 1.3 projects were broken at this stage, because symfony used this behaviour with the reintroduced sfAutoloadAgain autoloader, which checked the return value for strings, and got instances, causing an infinite loop that made apache segmentation fault.

This is now fixed, by http://trac.symfony-project.org/cha..., but was the feature worth the hassle? How many projects can this kind of change break?

So for all you that work on big projects, think well, then think again, then don't do such a change. Usual formula says «With great power comes great responsibilities». I'd add «Great notoriety induce great responsibilities».

Yes millions of people uses PHP, and that's the main reason why stable branch should stay stable. Rock solid stable.

And it's the same reason why symfony branches stay stable, as much as possible. And any exception to this always have bad feedback.

(thanks to Pierre Joye for his reminder at http://news.php.net/php.internals/4...)

Note: Software stability does not only mean bug-free. It also means «not changing», and it's the main definition used there. Bugs are annoying, but they can be fixed to get the wanted behavior back, so it's not a problem. And the only wanted behavior of a stable piece of software is the behavior it always had.

symfony How to render a component in an action with symfony 1.1+

2009-03-12T00:00:00+01:00

<?php
public function executeBarfoo(sfWebRequest $request)
{
  return $this->renderComponent('my_module', 'my_component', array());
}

database Foreign key's onDelete for dummies

2008-07-10T00:00:00+02:00

Any modern relational database engine supports the onDelete and onUpdate attributes on foreign keys. Propel and Doctrine of course allows to define it in the schema file (yaml or xml) and I believe it is important to explicitly set it.

Restrict mode

«Better do nothing than something stupid.»

The default behaviour is ON DELETE RESTRICT. This is the most secure setting, so it is normal to have it as default.

If we try to DELETE a record referenced by the current object, the database engine just raise an SQL error. If it was not an error to DELETE this, you will have to start by removing the linked object, or setting the foreign key value to something different.

Cascade mode

«No need to keep obsolete things.»

But our database engines are able to do better. For example, if you have an user's settings table and you delete an user, you may not wan't to keep his settings. You just set ON DELETE CASCADE on user's setting foreign key column referencing the user table, and if a user is ever deleted, all his associated properties will be destroyed.

Along with ON DELETE CASCADE, we usually add a NOT NULL constraint (or required: true), as the existence of current object is directly related to the existence of linked object. This may be wrong from time to time, but it is usually the case.

Set null mode

«We don't rely on this. Just forget it.»

The last behavior is the ON DELETE SET NULL option. It does exactly what it says. If linked object is removed, we set our foreign key value to null.

This the behavior you may want to use for articles having a link to their author for example. If the author is removed from database, we don't want to delete his articles, so we just loose the author information (well ok, this is a simplification, but it basically shows the idea).

Why I think we should explicitly use it

The default database engine behavior is «I don't know how to handle it». Setting it will add power to your database model, while taking profit of your RDBMS features. Not setting it is like saying «I don't know which way I want my database to behave in case we delete a linked object», and that's like saying «I don't know how I want my model to react». Thinking a little to understand which way you want it to work will make you certain you're understanding the behavior you need in your project.

How to set it in your favorite ORM

schema.yml with Doctrine

Article:
  columns:
    title:   string(255)
    body:    string(4096)
    user_id: integer(4)
  relations:
    User:
      onDelete: CASCADE

PHP model with Doctrine

<?php
public function setUp()
{
  $this->hasOne('User', array('local'    => 'user_id',
                              'foreign'  => 'id',
                              'onDelete' => 'CASCADE'));
}

schema.yml with Propel

    data_id:  { type: integer, primaryKey: true, foreignTable: data, foreignReference: id, onDelete: cascade, onUpdate: cascade }

schema.xml with Propel

<foreign-key foreignTable="data" onDelete = "setnull">
  <reference local="data_id" foreign="id" />
</foreign-key>

symfony Overview of symfony 1.1 event dispatcher

2008-04-30T00:00:00+02:00

As you may now by now, Symfony 1.1 introduces a new powerfull event dispatcher inspired by Apple Cocoa's NotificationCenter. Basically, it allows any entity to "listen" to events, and get a call on the registered callback if this event ever happens.

Symfony 1.1 provides some default events you can listen to, but of course you can create your own events if you need.

Listen to an event

To listen to an event, you need to use the "connect" method on the event dispatcher instance. The first parameter is the event name, and the second is a PHP callable that will get called if the event happens.

<?php
$dispatcher->connect('user.change_culture', array($this, 'listenToChangeCultureEvent'));

Create a custom event

To use the dispatcher for your own needs, you just need to define your event name in your project specifications, and send notifications to it. Depending on the behaviour needed, three options are offered:

Simple notifications

The simpliest way is to notify all listeners with the ->notify() method.

<?php
$dispatcher->notify(new sfEvent($this, 'my.super.cool.event'));

Notifications until something

Sometimes, you prefer to notify all listeners until one says "Ok guys, I handled this one. Don't worry about it anymore".

<?php
$dispatcher->notifyUntil(new sfEvent($this, 'my.super.cool.event'));

The first listener that will return non-false value will stop the event chain.

Filtering notifications

The last notifying method is called filtering. You set this up when you want to permit anything to act as a filter on something, meaning any listener can modify a source object.

<?php
$dispatcher->filter(new sfEvent($this, 'my.super.cool.event'), $objectToFilter);

Every listener must return the filtered value (or the original object if nothing was done) to pass to the next listener.

Practical use: Register routes in your plugins

One of the first practical applications that came to me was the new way of registering routes in plugins. In symfony 1.0, a coincidence made possible to use the routing in a plugin's config.php but that's not possible anymore in symfony 1.1, so you have to use the event dispatcher. To accomplish this, we're going to set up a routing.load_configuration listener in the plugin's config.php:

<?php
$this->dispatcher->connect('routing.load_configuration', array('myPluginRouting', 'listenToRoutingLoadConfigurationEvent'));

Then you just need to create the callback class/method:

<?php
class myPluginRouting
{
  /**
   * Listens to the routing.load_configuration event.
   *
   * @param sfEvent An sfEvent instance
   */
  static public function listenToRoutingLoadConfigurationEvent(sfEvent $event)
  {
    $r = $event->getSubject();

    // preprend our routes
    $r->prependRoute('my_route', '/my_plugin/:action', array('module' => 'myPluginAdministrationInterface'));
  }
}

Here we go :-D

symfony Don't be fooled by awkward view.yml js/css positionning syntax!

2008-04-21T00:00:00+02:00

Short post today about advanced view.yml configuration (in symfony 1.0, and 1.1) for assets.

You can give additional options to javascripts: and stylesheets: sections, but the sin equa non condition is to know about the yet very un-documented view.yml assets syntax.

So here it is:

  javascripts: [ jquery: { position: first } ]
  stylesheets: [ mycss: { position: last, media: screen } ]

I don't know if there are others options like thoose available, but taken the 'position' attribute apart, which is extracted to become the $position method argument of sfWebResponse::addJavascript() and sfWebResponse::addStylesheet(), any other option is passed in the $options array.

Methods prototypes below:

<?php
class sfWebResponse ...
{
  /* ... */
  public function addJavascript($js, $position = '', $options = array());
  public function addStylesheet($css, $position = '', $options = array());
  /* ... */
}

symfony plugins Complex relations population in propel 1.2 / 1.3

2008-01-31T00:00:00+01:00

This plugin is mostly a workaround for propel 1.2/1.3 limitations. If it's an option, you should consider using Propel 1.5 instead.

Since quite a bit of time, I've been faced with an annoying problem on every projects I use propel on. Propel builders only generates some specific cases selection methods, which consists of pretty ugly copy paste of the same code to populate the objects, and if your needs are not satisfied by the finite little number of propel handled cases, you'll have to either use pure SQL, or write a custom doSelect method. That seems okay at first sight, but it is not. In fact, you're about copypasting the propel generated method, and that's a rude violation of D.R.Y. principle.

I found no solutions during the two last years, but maybe things will change soon with the new sfPropelImpersonatorPlugin. This plugin is aiming at doing arbitrary object population based on informations provided by propel's introspection methods (DatabaseMap/TableMap/ColumnMap) to link populated objects.

The plugin is currently in very early stage, but is working pretty well for my needs, and I'm looking forward to know what others are thinking about it.

Related informations

symfony plugins Using symfony forms before 1.1

2008-01-07T00:00:00+01:00

The new symfony 1.1 form/validation framework is 100% symfony-independant, and though is not limited to the (very) awaited 1.1 stable release. To use it in your own symfony 1.0 projects, you can use sfForms11Plugin. It's content is very thin: it only sets up externals to symfony 1.1 form/widget/validator libraries.

To use it, simply add the following external to your project:

sfForms11Plugin http://svn.symfony-project.com/plugins/sfForms11Plugin

Or check it out from your project base directory:

svn co http://svn.symfony-project.com/plugins/sfForms11Plugin plugins/sfForms11Plugin

Let's try it...

Now you'll be able to define sfForm sub-classes to materialize forms:

<?php
class HelloWorldForm extends sfForm
{
  public function configure()
  {
  }

  public function setup()
  {
    $this->setWidgetSchema(new sfWidgetFormSchema(array(
            'name' => new sfWidgetFormInput(),
            )));

    $this->setValidatorSchema(new sfValidatorSchema(array(
            'name' => new sfValidatorString(array('required'=>true, 'min_length'=>1, 'max_length'=>50)),
            )));

    $this->widgetSchema->setNameFormat('hello[%s]');
    $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);

    parent::setup();
  }
}

This class define the model of your HelloWorldForm, and you can now use it in your actions:

<?php
class testActions extends sfActions
{
  function executeHelloWorld()
  {
    $this->form = new HelloWorldForm();

    if ($this->getRequest()->getMethod() == sfRequest::POST)
    {
      if (null !== ($hello = $this->getRequestParameter('hello', null)))
      {
        $this->form->bind($hello);

        if ($this->form->isValid())
        {
          $this->redirect('@hello?name='.$this->form->getValue('name'));
        }
      }
    }
  }
}

At this point, the only little detail still missing is the view:

<form method="POST">
<table>
<?php echo $form; ?>
<tr>
  <td colspan="2" align="right">
    <input type="submit" value="Greetings, Mr Computer!" />
  </td>
</tr>
</table>
</form>

That's it! You now have a simple form, self-validating, protected against CSRF attacks and redirecting to some place if values entered matched our sfValidatorSchema.

Related informations

symfonyCreating custom config handlers

2007-12-24T00:00:00+01:00

This article was written for symfony 1.0 and pre-1.0.

You most probably will have to adapt the code.

When writing plugins, you often want to do it the symfony way, by putting configuration stuff in YAML files to allow the final user to override your default values in a harmless way.

To do this, the correct way is to create a config handler, extending sfConfigHandler, or its child class sfYamlConfigHandler.

Here is a simple one, just dumping YAML data found in your config file into an sfConfig::get()-able PHP dataset.

<?php
class myStupidConfigHandler extends sfYamlConfigHandler
{
  public function execute($configFiles)
  {
    // retrieve yaml data
    $config = $this->parseYamls($configFiles);

    $code = sprintf("<?php\n" .
                    "// auto-generated by myStupidConfigHandler\n" .
                    "// date: %s\n" .
                    "sfConfig::set('my_stupid_config_entry', %s);",
                    date('Y-m-d H:i:s'), var_export($config, 1));

    return $code;
  }
}

We can enhance it, taking care of symfony environments.

<?php
class myStupidConfigHandler extends sfYamlConfigHandler
{
  public function execute($configFiles)
  {
    // retrieve yaml data
    $config = $this->parseYamls($configFiles);

    // get current environment
    $environment = sfConfig::get('sf_environment');

    // merge default and environment specific config
    $config = sfToolKit::arrayDeepMerge(isset($config['all'])?$config['all']:array(), isset($config[$environment])?$config[$environment]:array());

    $code = sprintf("<?php\n" .
                    "// auto-generated by myStupidConfigHandler\n" .
                    "// date: %s\n" .
                    "sfConfig::set('my_stupid_config_entry', %s);",
                    date('Y-m-d H:i:s'), var_export($config, 1));

    return $code;
  }
}

Next step will be to tell symfony which configuration file patterns should be loaded using our class. To do this, add the following entry to config/config_handlers.yml (whether in your app, plugin or module, depending on the scope of your config handler)

config/stupid.yml:
  class:    myStupidConfigHandler

Once this is done, the very little remaining last step is to mak sure you include the compiled yml.php file with the following magic command, that will rebuild it when unexistant or outdated:

<?php
require_once(sfConfigCache::getInstance()->checkConfig('config/stupid.yml'));
/* ... */
$stupid_config = sfConfig::get('my_stupid_config_entry');

easy one :-)

Related informations

doctrine Using DBMS functions with sfDoctrine

2007-10-30T00:00:00+01:00

This article was written for early PHP-Doctrine versions (1.0 or before).

It may not be useable with recent doctrine versions (and most probably not at all with Doctrine 2.0).

I recently had a peek on symfony forum, and seen someone asking "How can I make a SELECT count(*) FROM .... with doctrine?".

An answer to such a question should be pretty obvious as it's of everyday use, but the question seems to have come to life many times as well on IRC than on the forum/mailing list.

Here is my two-cents how-to.

Using builtin DQL aggregate functions

Basically, you can add aggregate functions (functions that operates on a group of records instead of one record, also called GROUP BY functions) to your DQL query the same way you'd do in SQL, provided the fact you're using one of the builtin DQL aggregate functions (COUNT, MAX, MIN, AVG, SUM).

<?php
$result = Doctrine_Query::create()
     ->select('COUNT(t.id) cnt')
     ->from('Table t')
     ->execute()
     ->getFirst();

echo $result['cnt'];

Using DBMS specific aggregate functions

If the function you need is in the list, no need to go further. But some functions are DBMS specific, for example MySQL provides a GROUP_CONCAT() function. It would be nonsense for DQL to provide that, as it would not be translatable in some of the other DBMS SQL, but it would also be nonsense to restrict functionalities to the smallest common functionnalities set of every DBMS that Doctrine supports.

The way to go is to change the portablility level of doctrine, to match your needs. As the name implies, you're loosing in portability between the different DBMS, but you're gaining specific functionnalities of yours.

The following code, running in PORTABILITY_ALL mode, will throw a Doctrine_Query_Exception:

<?php
Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_PORTABILITY, Doctrine::PORTABILITY_ALL);

$result = Doctrine_Query::create()
     ->select('GROUP_CONCAT(t.value) concatedstring')
     ->from('Table t')
     ->execute()
     ->getFirst();

Now remove the Doctrine::PORTABILITY_EXPR bit to this attribute, and you will get the correct result (using MySQL):

<?php
Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_PORTABILITY, Doctrine::PORTABILITY_ALL ^ Doctrine::PORTABILITY_EXPR);

$result = Doctrine_Query::create()
     ->select('GROUP_CONCAT(t.value) concatedstring')
     ->from('Table t')
     ->execute()
     ->getFirst();

echo $result['concatedstring'];

Extending to other functions

Ok aggregate functions are usefull, but other functions can be very handy too, string functions for example. Doctrine manual tells us that builtin DQL string functions are CONCAT, SUBSTRING, TRIM, LOWER, UPPER, LOCATE and LENGTH.

<?php
Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_PORTABILITY, Doctrine::PORTABILITY_ALL);

$results = Doctrine_Query::create()
     ->select('LENGTH(t.value) val_len, t.value')
     ->from('Test t')
     ->execute();

foreach ($results as $result)
{
  echo $result['value'].' => '.$result['val_len']."\n";
}

This code will display all records' value fields, followed by their character length computed by the DBMS, in PORTABILITY_ALL mode.

Now let's say you want to use BIT_LENGTH() MySQL function...

<?php
Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_PORTABILITY, Doctrine::PORTABILITY_ALL ^ Doctrine::PORTABILITY_EXPR);

$results = Doctrine_Query::create()
     ->select('BIT_LENGTH(t.value) val_len, t.value')
     ->from('Test t')
     ->execute();

foreach ($results as $result)
{
  echo $result['value'].' => '.$result['val_len']."\n";
}

This is the way to go again.

No need to say, this extends to every type of functions available in the different DBMS.

Romain Dorgueil

php I see huge controllers ...

Huge controllers

One place for each stuff, and each stuff at the right place

Organize your model layer

Group features by concerns

Don't repeat yourself

So ?

python Give your WSGI application super-powers

About middlewares

The most amazing middleware ever: ajax interactive debugger

Ok, and now what ?

python WSGI, the first steps

Get your environment ready

First application

Getting programmer friendly

Pythonize it

Related informations

life Champagne!

dynamics The end of Dynamics

database Handling empty WHERE IN clauses in DBALs

Understanding the problem

The quick and dirty hack - Propel 1.2/1.3

SQLAlchemy's solution

The pythonic way - django.db

And the latest Ruby on Rails development does the same

See also

The (true, false, unknown) algebra

Conclusion

the roots HTTP is the web's language

So what is HTTP ?

Messages, requests, responses

The request

The response

HTTP methods

Safe methods

Idempotent methods

Non-safe and non-idempotent methods

And the real world

Example

The request...

and the response!

Conclusion

software All about backward compatibility...

symfony How to render a component in an action with symfony 1.1+

database Foreign key's onDelete for dummies

Restrict mode

Cascade mode

Set null mode

Why I think we should explicitly use it

How to set it in your favorite ORM

schema.yml with Doctrine

PHP model with Doctrine

schema.yml with Propel

schema.xml with Propel

symfony Overview of symfony 1.1 event dispatcher

Listen to an event

Create a custom event

Simple notifications

Notifications until something

Filtering notifications

Practical use: Register routes in your plugins

symfony Don't be fooled by awkward view.yml js/css positionning syntax!

symfony plugins Complex relations population in propel 1.2 / 1.3

Related informations

symfony plugins Using symfony forms before 1.1

Let's try it...

Related informations

symfonyCreating custom config handlers

Related informations

doctrine Using DBMS functions with sfDoctrine

Using builtin DQL aggregate functions

Using DBMS specific aggregate functions

Extending to other functions