4 ms·
The original commenter might have their own thoughts, but after using both Symfony and Django here are mine: - A well organized, much more cohesive plugin stru
by stevenwei 16y ago
The original commenter might have their own thoughts, but after using both Symfony and Django here are mine:
- A well organized, much more cohesive plugin structure: http://www.symfony-project.org/plugins/ http://www.symfony-project.org/plugins/
Plugins are versioned with compatibility matrices for each major Symfony release, and indexed in a centralized location.
- Much better extensibility of both framework and plugin classes. You can easily subclass any existing model class to customize to your needs. Django is severely lacking here (e.g. customizing auth.User to accept an email based login without breaking existing apps that rely on auth.User).
- Much better customizability of the admin interface.
- Very powerful model level validation. This isn't Symfony so much as Doctrine, which is the best PHP ORM I've ever worked with.
- symfony project:deploy production is pretty sweet.
Of course, in general, I still prefer Django to Symfony.
- PHP as a language is so unexpressive that Symfony has resorted to using YAML files and code generation to represent configuration data and model objects.
- The code generation gets a bit unwieldy at times (tons of classes and empty subclasses).
- Frankly, if your language is so verbose that you end up needing to store your data in a different format (e.g. YAML and PHP, XML and Java), you're using the wrong language.
- Jinja2 is also a much nicer templating language than straight PHP.
- MWinther 16y agoWhen it comes to authentication, wouldn't it be rather easy to subclass the ModelBackend class to simply use email instead of username if that's what you want? And if you want to extend user.Auth with more user data, they have a way of doing so as well, without subclassing: http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/ http://www.b-list.org/weblog/2006/jun/06/django-tips-extendi... Could you be more specific as to what kind of things the Symfony/Doctrine model level validation can do?
- stevenwei 16y ago1) Yes, it is possible to subclass the ModelBackend. That's not the only step involved in switching from username based logins to email based logins, however, since the default User definition has defined a required username CharField that takes some hackery to get around. 2) Symfony does the same thing with a one to one User <-> Profile relationship. I find this to be a silly hack in both frameworks that creates extra database JOINs for no reason. If I want to place a foreign key on the user table because multiple Users can belong to a single Account, I shouldn't have to go through an additional join table. 3) You can configure Doctrine to raise an exception if you try to save() a model object with invalid fields, and check if the fields are valid at any time with isValid(). It makes a lot more sense to me to do this at the model level since there are many scenarios where you still want validation and aren't actually using forms of any sort.
- jbox 16y agoRe. customizing auth.User to accept email based login - There isn't a completely DRY solution for this, but it's got much better - here is a tiny app that will do it for you: http://github.com/johnboxall/django-email-auth http://github.com/johnboxall/django-email-auth
- stevenwei 16y agoDoes this actually work? It seems to me there would be a major bug since the existing auth.User email field definition is not unique and allows blank values, and this app doesn't do anything to check against that, nor does it do anything to remove the existing username field definition.
- jbox 16y agocustomizing auth.User to accept an email based login This app solves the problem by allowing users to log in using their email address. It's not a bug that it doesn't deal with account creation - it's outside the scope of the app. That said, it is fairly trivial to create a registration form that enforces the constraints you mentioned.