Reaching deep into the I18n core
When creating truly internationalized content, you need to think of a few things - first, what country your are in, and secondly, what the locale is in that country. Why should you care? User input.
While Symfony does have handy features via sfI18N, it doesn’t expose some of the methods needed to correctly parse strings. While string parsing isn’t meant to be the scope of this post, I’ll explain how to get your hands on the number formatting information to enable your application to correctly parse input strings and/or display them in templates (although, I might remind you of the Number helper and its application within the view layer, to aviod logic duplication when that’s already been taken care of).
When you want to get number format information, you simply create an instance of sfCultureInfo, like so:
$culture_info = new sfCultureInfo(sfContext::getInstance()->getUser()->getCulture());
$number_format_info = $culture_info->getNumberFormat();
$negative_sign = $number_format->getNegativeSign();
$decimal_sign = $number_format->getDecimalSeparator();
This gives you the chance to write your own number parser according to the expected format and/or use locale-specific settings for different purposes for user-friendly input, not just sfI18N::getTimestampForCulture().
February 13th, 2008 at 3:52 pm
symfony sucks!
no debugger in eclipse
nothing works
the manuals are a mess - following them leeds you nowhere
yml is stupid
February 13th, 2008 at 6:04 pm
<13-year-old>
you arunt using symfony
so by definishun u suck!!1!
</13-year-old>
Thank you for that creative insight into what you call argumented criticism. I’ll be sure to note that my configuration is stupid and the documentation leeds you nowhere. Whatever that may mean. And just to make end meet, I’ll pass on this message to the lead developers and of course notify Yahoo! of their grave miscalculation in their framework of choice.
March 18th, 2008 at 4:14 pm
Seriously. When I create something from scratch I absolutely know what will happen next. I guess, Symfony might be really great if you know how to handle it. But at the moment I agree to shai. The learning curve is quite strange. (And I already made huge apps)
It’s just that I think I have to change the whole way to development. And that makes me feel completely mad
March 18th, 2008 at 4:50 pm
While that may seem so, the truth is that Symfony does encourage you to think in a radically different way than what you were used to when you did procedural programming in straight PHP. But this results in two main advantages - you tend to have a firmer grasp of PHP and OO-related concepts and, more importantly, in a team-based development cycle, there is much to be said on code understandability and documentation. Symfony is well stocked with users and developers alike, so support is bustling (check out the IRC channel, for example) and documentation is being refined daily, not to mention a comprehensive test suite for each of the building blocks and PHPdoc documentation.
Does YOUR code offer such support? Not to diss or anything, but we’ve switched from a home-grown fork of Mojavi (an ancestor of Symfony, too) to Symfony and I must say that having not to really on internal development of the framework really frees you of most of the worries of compatibility, support and future-proofness. And allowing for tight schedules, you may not have the luxury of taking the time to write tests for both the framework and your projects - leaving the code largely untested for some assertions you assume are correct. This leads to hidden bugs and holes and maintenance gripes (like switching from PHP4 to PHP5 - you’re the one who has to manage both the libraries and the business code instead of just the latter).
All those things considered - the learning curve is but a minor setback, since you’ll be saving at least as much time on project deployment, support, upgrades and debugging.
April 20th, 2008 at 2:15 pm
The fact of the matter is, MVC is subject-oriented, not object-oriented. I often wonder how MVC-advocates, especially when it comes to PHP, insist that their frameworks encourage radical re-thinking of things in object-oriented terms when their framework diminishes the application of tried and tested design patterns (even if the framework is implemented with such).
It’s not as black and white the case being that before symfony (and other MVC frameworks) people were writing only procedural code. I can think of plenty of examples where I have used object oriented patterns to fulfil the functional requirements of an application.
The documentation is comprehensive for symfony. The PHP manual is also so but the difference is that it does not TELL you how to write an application and instead encourages you to learn the fundamentals of the language.
My point is, PHP already offers you everything you need to develop a web application and if the need be - to develop your own set ways of developing applications. If you don’t trust or feel insecure about your methodologies the temptation is there to plug the gap with frameworks with arguments like “yeah well yahoo uses this”. If you don’t trust in your own methodologies then you should not be using the language for enterprise projects - you should be studying it.
April 20th, 2008 at 2:59 pm
While it may be true that with pure PHP you aren’t forced into rethinking your way of coding, it also brings about a very valid point regarding newcomers to the web landscape - how to go about learning it and harnessing its power without risking significant security vulnerabilities (since your public interface is open to the world, not a select few).
While it is true that Symfony makes you go out of your way to implement something that you can’t using the prescribed development guidelines, it does teach you to accept a different point of view. It is a domain-specific subset of PHP, if you will - in which problems are solved in a way that the authors and the community deem optimal, given the amount of work and progress achieved so far.
Yes - PHP does offer you the freedom to do anything you want - from implementing a full-blown MVC framework to just using
print_r($_REQUEST);. However, when you have a gazillion options to choose from, with only a few paths leading to an acceptable end result, chances are that trial-and-error (which is THE leading way of learning in PHP for most, if not all, beginner programmers) will lead you down the wrong path of thinking about solving a given problem, since most problems can be solved procedurally without even knowing about objects in PHP5 (or any version for that matter).Your last point of now trusting your own methodologies is however refuted in my previous post - we have been using a home-grown framework which could still stand up to the most complex of frameworks available today - but the switch to Symfony was made due to the time and cost analysis involved in the decision to not support and develop our own framework, rather to focus on developing client applications without devoting too much time on the “meta” stuff - the underlying architecture. With our own framework, bugs and features needed to be implemented and everything had to be done in-house, while with Symfony we can leverage the time by co-developing the framework and having more time to devote to finishing our end products.
So, in a nutshell: Symfony teaches a (wo)man how to fish, while PHP just shoves a fishing pole in one’s hand and waves goodbye. Sure, there are different ways to fish - but the end result is you know how to fish and are free to explore different styles and techniques. With the latter, someone might even use it to bash fish on the head. Crude, but it might work.
April 30th, 2008 at 11:13 pm
I find the post above supremely insulting. I went to university and learnt object oriented development via Java. Then I moved to PHP. I did not learn the language by ‘trial and error’. I read the manual. And I like the wonderful power of PHP with full object orientation supported. You can easily write clean, clear, understandable code with PHP.
With Symfony, a whole load of concepts which are meaningless (’application’,'module’) are introduced, no forced, on the user. Symfony is not a handy set of classes which come together, or even a nice library for speeding up development. It is a dream world forged in it’s creator’s head. It forces the user to (i) learn a way of operating which is way more complex than the actual underlying language and (ii) write all their code to fit in with what suits Symfony, which means the code becomes terribly unportable, and would likely have to be rewritten to be moved away from this environment.
The only people who will ever benefit from Symfony are those people who are so impatient with something that they are willing to take the small shortcuts Symfony might eventually offer (after the huge learning curve) and happily pay for them with an application which is stuck inside a huge, hulking monolithic fantasy world created in PHP by Symfony’s creator, which needs constant upgrades to keep it’s many (mostly unused by the end application) cumbersome libraries up to date. Oh and if they do get up to speed on PHP and decide their application could be done simply and cleanly with a few classes and some scripts, they will have to rewrite the whole thing, because any real PHP in their application will be so buried and intertwined with Symfony, recovery will not be an option.
May 29th, 2008 at 3:00 am
@John, I feel your pain. I’m currently having to rescue a buried Symfony application after the original developer took a leave of absence. I’ve told my client that we must extricate it from Symfony as a top priority, before development costs spirals and it brings down his company. He understands - I’m one of the lucky ones.
May 31st, 2008 at 6:16 pm
@John: I don’t get exactly how I might offend someone with a formal education on the subject, since I’ve only explained that Symfony enforces its own way of dealing with a specific problem.
To reiterate my standing - while I do admit there are LOADS of other frameworks and libraries, even vanilla PHP, that in many cases are more appropriate to use in place of Symfony. And I share your opinion on some aspects of Symfony, especially the Javascript helpers (since I’ve moved into interface design).
Still, I don’t understand your offence at my post stating that you’ve had formal education. Yes, I agree, you don’t belong in the category of people mentioned in my post (which, I might add, represent the majority of development going on on the web), neither do I belittle your academic prowess. I haven’t painted a black-and-white picture, and neither have I stated that it’s only Symfony-or-die.
Having the benefit of being introduced into the Java world, you’ve had insight into how OOP works and had directed learning towards a goal of understanding the underlying system. The manual worked for you, because you already understood the concepts, you only needed to familiarize yourself with the syntax, more or less.
The problem is that guidance like that for someone with no formal education on the subject is hard to come by, or sometimes seems unnecessary, since PHP enables you to build something pretty quickly on its own, albeit just about. But sometimes that’s enough for people - especially the people that use code monkeys to build “corporate websites.” And that’s the sorry state of affairs we have to put up with.
Again, to clear the air - I’m saying that guided learning is something every beginner should seek to benefit from, and Symfony is one such system. As you pointed out, it does introduce “meaningless” concepts like “modules,” “actions” and such. Still, so do most OOP frameworks on the market today. What is a “controller?” These do have meaning and abstract the flow of code into discrete chunks of congruent blocks which then come together to form a response to user interaction. While Symfony’s way of dealing with the problem may not suit your way of thinking, it does not mean it doesn’t address the problem domain it is meant to solve.
It all just boils down to the individual - if one is adept enough to think outside the framework, they will see benefits of doing things their own way. Heck, I see benefits of avoiding Symfony in certain cases, and so do the authors. If not, most will be content with working with an iron set of rules to follow.
At least Symfony’s are better documented than most, which is especially helpful with legacy projects left behind like in Rob’s case.