>Historically, between 50 and 60 percent of the federal R&D investment is made in defense.
>[mentions the American Reinvestment and Recover Act]However, despite this shift in R&D investment priorities, defense R&D spending continues to outpace non-defense R&D spending by $20 billion.
They need to switch to a complete distributed architecture.
Where the site, the tracker, everything is hosted by users. This way, no corporate tools can target them.
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/
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.
When 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-extendi...
Could you be more specific as to what kind of things the Symfony/Doctrine model level validation can do?
1) 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.
Re. 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:
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.
models/ORM
Doctrine does better job.
- abstract model definition via yml file
- multiple connections/databases/environments easily managed
- Cool API (shortcuts, relations, custom tables etc.) + DQL for queries + support for multiple DB engines
admin interface / CRUD interface
- they are easy to generate but easier to customize under symfony.
- you can do 90% of the stuff via a config file generator.yml.
The rest is extending the generated code and customizing queries to the model
configuration
- you can do more via the config files in Symfony and control your project/applications vs Django.
forms system
- the abstract forms system comes with generated forms based on your model, widgets with validations, binding with your model, customizable renderers.
You can have a custom CRUD interface up and running and linked to your tables in less than a few minutes.
routing
- routing.yml and sfPatternRouting does a much better job without using complex regex patterns
- Also, all routes are abstract, understandable and well located.
testing
- Unit testing and functional testing is very well done. You can launch specific tests, launch failed tests only, call your model/forms easily because they are all objects, simulate a browser session etc.
You can do all that stuff with Django but will a lot more code.
framework vs API
- symfony abstracts anything useless as a plugin where Django tends to integrate some of it in their Framework (CSV, PDF generators etc.). That's a lack of vision.
Anyway, just a couple of points, I could go on and on ;-)
Because all the things you say are either wrong (multiple db engines, forms for CRUD) or a matter of taste (the use of YAML, regexes for routing, including batteries).
And, for the language thing, PHP is plain horrible.
Agreed. Seems to me his answer is mostly taste rather than actual use.
The thing about "complex regex" struck me as odd. Why are his routing regexes complex? If they're that hard to write, then I'd suggest he'd revisit the routing scheme.
I haven't used Symfony before because I rather not develop in PHP unless I really have to. Having said that, If i ever have to, I'd like to give Symfony a try.
is literally the most retarded syntax I've ever seen for invoking an object callback, and is indicative of PHP's roots as a non object oriented scripting language.
No doubt, the way PHP deals with functions is one of the worst parts about the language. create_function and the rest have been made a bit better, though, with the introduction of anonymous functions in PHP 5.3.
forms system - Disagree, Django forms and generic views let you do the exact same thing.
routing - Disagree. I've used several routing systems across web frameworks and it mostly comes down to a matter of taste. Django's system could probably be a little simpler (most of the time you don't need the full power of regexes to match simple numbers or string) but it gets the job done and stays out of my way.
testing - Disagree. Why did they write their own testing framework (lime) when SimpleTest and PHPUnit already existed?
framework vs API - Agreed. The added downside is that once a third party app makes it into Django core, it evolves much more slowly due to backwards compatibility issues.
Also, I seriously tried to use Doctrine for a PHP project and though it seems great at first, I ended up going back to raw SQL. I have used Django and it's ORM, and I had no desire to do raw SQL.
Symfony seems way over-engineered to me, and the horror of the PHP syntax really turns me off (though I'm quite familiar with PHP). If I'm going to use PHP, I'd rather just do what it is best at and get straight to the point.
The ultimate would be if Adobe's CEO used an iPad to post a message on Facebook which was leaked out because his privacy settings were changed when he wasn't looking, and then Steve Jobs replied.
