Last month, I shared my vision for symfony 1.3. To involve the community in the process of deciding what to do for symfony 1.3, I have opened a user voice page (edit: does not exist anymore) where everybody can suggest enhancements for the 1.3 version of the framework.
For now, the most requested enhancement is to work on performance. Enhancing
performance is not an easy task. The framework is already quite optimized and
making it faster will certainly mean removing things, doing things
differently, removing some compatibility layers, and perhaps break
compatibility altogether. The symfony core team will suggest some enhancements
in the coming weeks, explaining the pros and the cons. The community will then
have the opportunity to vote on them and you will have the last word (be ready
to add some ++ or -- strings as comments as you did for the Jobeet design
day).
The third and fourth most voted suggestions are contradictory: make Doctrine the default ORM and do not make Doctrine the default ORM. After some thought, I think I have found a solution to make everybody happy. There won't be a default ORM in symfony 1.3. Whenever you will create a project, you will have to choose between Propel, Doctrine, or no ORM at all.
If you want to vote for an existing suggestion, or add a new one, you still have one week left as the "Feature brainstorming" phase ends at the end of the month.
Another item with quite a few votes is "a better transparency for the development process" -- the user voice page is a good step in this direction -- please make sure your voice is heard! Also, if you entered your votes early in the process, take a look at some of the ideas others have entered in the meantime.
Performance? Why do people ask for such "features"..? IMHO focus should be compatibility to 1.2, so it's much easier to upgrade than it was with the previous releases. That is the real "performance problem".. ;-)
I think it's much more important to continue to make parts more flexible, like the admin generator. For example, allow to change all routes in runtime (so I can integrate admin generators much easier into a CMS) or implement multi column sort.
I agree that symfony perfomed well. It is not THE fastest Framewok, but it has proven his speed in many projects. See delicious, yahoo! answers and at least Dailymotion.
And i love the solution for the default ORM ;) I think this is a compromise that anybody can life with.
-- "Languages, libraries and frameworks don't scale. Architectures do."
I love the framework solution:-)
I agree about the ORM: I feel that Propel has always been given preferential treatment in the default project / module generator tasks. If you really want to make Propel and Doctrine equal, then make both not the default.
"There won't be a default ORM in symfony 1.3. Whenever you will create a project, you will have to choose between Propel, Doctrine, or no ORM at all."
That's a great idea. Make it compulsory to choose yet another config param to start a project.
You could call this idea: "configuration over convention". This will mark memories like no other name.
By the way, maybe you should change the project:init task to use a XML configuration file instead of a set of CLI options.
So far I've been underwhelemed by the way that Symfony still tilts towards Propel as opposed to Doctrine. Ideally, it would be great if the ORM could be completely abstracted and all Symfony features were fully supported in either ORM. I know this is easier said than done... but that would be my ideal.
If no choice is selected by default, you must still choose which one to show "first" or "at the top" which might influence beginners towards one or the other.
I think it's a good decision for Doctrine and Propel, it should stop the ORM war ! :)
Thanks you for the future 1.3 and i hope that you will continue to make good tutorials and helps us with the good pratics of developping website. It's such easy with killer php cli commands . it will be interesting to have easy integration of .xls(x) and .doc(x) file,and with can imaginate openoffice format.
To keep people happy have the system ask you what ORM to use. Please do not remove it.
as for cutting back features please do not do either. You could easily exclude things via the configuration.
If performance is really an issue it really comes down to the OS and hardware a site sits on. I have created and are running a few very major sites for clients running symfony 1.0 They are on dedicated web and sql servers. The most important aspect is the server or servers the site is running on.
While I appreciate the idea of removing the default ORM for sake of equality, I don't think it is a good idea. Removing the default ORM will force beginners to make yet another choice, which will make getting into symfony yet harder. In my opinion, the core team should make a clear statement about which ORM is preferred, even if this may seem "unfair". The big advantage is that plugin developers will know which way to go and beginners will have a clear path to walk along while getting into symfony.
"System vote and comments for plugins" has to be number one for me, followed closely by "Improve sfGuard". I am just astonished that this plugin has stayed at this level for so long.
@Bernhard: good point, 1+ for this I was trying to figure out what the mid- & long-term intention of the core group could be, in order to know where to invest. This also in view for the community, notably when it comes to upgrade some of the excellent plugins to sf1.2 but with which ORM? With that respect, what does the core group think of sfDBFinderPlugin? But anyway, sf is evolving greatly, I enjoy it, and thanks for all this :-)
I agree with Bernhard, even if there are lots of tasks to help us to develop plugins, you have to choose one ORM to start, and if the sf project "recommend" or has preferences about one ORM it 'd be easy to decide to start with Doctrine or Propel. I agree too that for the beginners it's better don't have so many options to configure, maybe a CLI wizard to configure database parameters, ORM and others things can be interesting for newcomers.
++ @Bernhard et al, good idea
I am not in favour of forcing new users to install an ORM manually - let's choose one, and get it to work almost with default settings. More experienced users may prefer to switch to something else, but that's okay - they have the know-how to do so.
When creating a new project, can we at least have the CLI prompt the user for the ORM to choose, and enable the pre-installed ORM from that?
How many voices... :) Well, i don't like the idea of ORM default. How many times we ear, less code, means less errors?
With Doctrine we have write more code. Propel and autocomplete of eclise, just can't be better. So Propel, means less errors (for me).
Make ORM default, is a attack to PROPEL and his future in Symfony.
When Doctrine, can be a ORM more faster that PROPEL, i'll change my idea.
Today i can't appreciate the significant advantage.
@Bernhard: good point. And i feel that PROPEL can be a good chooice.
If Doctrine, can be more OO. Maybe can be easier.
Conclusion: I need see with results, a comparative bewteen DOCTRINE and PROPEL. Or just stop this topics.
@puentesdiaz let's don't start a flame war, but, please, take a look at Doctrine before start saying nonsenses
"In my opinion, the core team should make a clear statement about which ORM is preferred" AMEN!!!!!
Choice is great - but its splitting the symfony into smaller and smaller divisions - and making the number of plugins that fit your sf version and install tiny.
We should choose a preferred ORM and then we can concentrate our efforts much more effectively.
How about improve CLI, or related Windows, performance?
The current lag time for CLI and
symfony test:unit|functional ...to run is horrid.we MUST have a default ORM. It should be the one which is faster and with stable development future. i am not a fan of either one, but we need to know which should we better stick to and invest into learning it.
As symfony is a framwork and no cms out of the box and hopefully never will be, I do not get the arguments for a default orm. of course it will be a little pain having two documentations like we have now and developing/reusing plugins, but for me the first goal of a framework's core is to provide functions nearly everyone needs developing a dynamic website.
Why having a ORM bundled? As far as I remember one thing delicious has tweaked in symfony was simply NOT using orm at all because of performance reasons.
This topic relates to the uservoice page and I do not want to critizise people, but at least the half of the feature wishes are functions that should not be placed in a framworks core, or do they?
"We should choose a preferred ORM and then we can concentrate our efforts much more effectively."
++ ++ ++agree
having 2 ORM's in the core is simply splitting the community in half. Every day I see a plugin in symfony that uses Doctrine that I cannot use because we have deployed with Propel. The project needs to make the hard, objective call. Which ORM more closely aligns with the philosophy and standards of the framework? Whichever that is, pick it, make it the standard and get 100% behind it.