Influence the future of symfony
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
-- strings as comments as you did for the Jobeet design
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.
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 are closed.
To ensure that comments stay relevant, they are closed for old posts.
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.
And i love the solution for the default ORM ;) I think this is a compromise that anybody can life with.
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.
it will be interesting to have easy integration of .xls(x) and .doc(x) file,and with can imaginate openoffice format.
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.
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 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.
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?
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.
let's don't start a flame war, but, please, take a look at Doctrine before start saying nonsenses
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.
The current lag time for CLI and `symfony test:unit|functional ...` to run is horrid.
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.
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?
++ ++ ++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.