Influence the future of symfony

February 19, 2009 · Published by Avatar of Fabien Potencier Fabien Potencier

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 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.

Published in #Community

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

Avatar of Kris
Kris said on Feb 19, 2009
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.
Avatar of Matthias
Matthias said on Feb 19, 2009
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.
Avatar of spasic.dejan
spasic.dejan said on Feb 19, 2009
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.
Avatar of tenshu
tenshu said on Feb 19, 2009
-- "Languages, libraries and frameworks don't scale. Architectures do."
Avatar of marijn
marijn said on Feb 19, 2009
I love the framework solution:-)
Avatar of Symbiat
Symbiat said on Feb 19, 2009
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.

Avatar of Alan
Alan said on Feb 19, 2009
"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.
Avatar of slantedview
slantedview said on Feb 19, 2009
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.
Avatar of Mark
Mark said on Feb 19, 2009
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.
Avatar of COil
COil said on Feb 19, 2009
I think it's a good decision for Doctrine and Propel, it should stop the ORM war ! :)
Avatar of Arno
Arno said on Feb 19, 2009
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.
Avatar of Nathan
Nathan said on Feb 20, 2009
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.
Avatar of Bernhard
Bernhard said on Feb 20, 2009
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.
Avatar of Crafty_Shadow
Crafty_Shadow said on Feb 20, 2009
"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.
Avatar of Raphael
Raphael said on Feb 20, 2009
@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 :-)
Avatar of saganxis
saganxis said on Feb 20, 2009
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.
Avatar of halfer
halfer said on Feb 20, 2009
++ @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?
Avatar of puentesdiaz
puentesdiaz said on Feb 20, 2009
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.
Avatar of dereck
dereck said on Feb 20, 2009
@puentesdiaz
let's don't start a flame war, but, please, take a look at Doctrine before start saying nonsenses
Avatar of John
John said on Feb 20, 2009
"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.
Avatar of Olmo
Olmo said on Feb 20, 2009
How about improve CLI, or related Windows, performance?

The current lag time for CLI and `symfony test:unit|functional ...` to run is horrid.
Avatar of Malas
Malas said on Feb 23, 2009
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.
Avatar of wissl
wissl said on Feb 24, 2009
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?
Avatar of vitriolix
vitriolix said on Feb 26, 2009
"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.

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.