I smell bloatware. Although having an API sounds like a great idea, it may be too much complexity, for too little a gain. Symfony2 has already taken leaps toward massive complexity - for the sake of "flexibility".
Making symfony so complex means that it becomes unsuitable for 95% of projects. Mamady On Mar 31, 2:51 pm, Fabien Potencier <fabien.potenc...@symfony- project.com> wrote: > We currently have a discussion about translation messages. Keys or > English sentences? Everybody agree that keys are better, but English > messages are best to keep components decoupled. Is there any solution? > Read on. > > One of them is the introduction of the Symfony API. > > I've created a branch for that here: > > https://github.com/fabpot/symfony/tree/api > > and the relevant commit: > > https://github.com/fabpot/symfony/commit/45be152c33546affa4f1de4920ca... > > Don't try it at home as it does not work (I have just moved files around > to have a feeling for the result). > > Here is the commit message: > > added an API sub-namespace > > What's that? > > Symfony2 Components are standalone libraries that can be used without > any external dependencies. But sometimes, you want optional > dependencies. For instance, the Form component supports Twig but if you > don't use Twig, there is no problem. > > Unfortunately, if the optional dependency is at the center of the > component, it's a bit more tricky. The Form/Validator components provide > error messages. Right now, they are defined as English strings, but some > want to convert them to keys. If we use keys, we always need some kind > of "translation" mechanism. But we don't want to force people to use the > Translation component. So, you must provide a simple/fake implementation > if the developer does not need translation. But that's not possible. You > can create a local interface with a local implementation; but the > external dependency won't extend your local interface. You are out of luck. > > That's where the Symfony2 API comes in. > > The Symfony2 API is a set of public interfaces that keeps the components > decoupled but also allows for more optional features to be added. For > the example above, the Form/Validator components can just use the > Translator interface and provide a simple implementation locally. If the > developer wants to internationalize his error messages, he can use the > Symfony2 Translation component or any library that use the Symfony2 API. > So, besides being a nice way to solve the Symfony2 components > dependencies problem, it also exposes a nice API that others can > implement to make their library interoperable with the Symfony2 ecosystem. > > The value of the Symfony2 API lies in the quality of the interfaces we > publish and the fact that we keep their numbers as low as possible (for > instance, do we need the DataCollector interface there? -- probably not). > > The Symfony2 API namespace structure does not necessarily follow the > Component one (Logger for instance does not exist as a component). > > I have collected interfaces that I think should be in this API, but more > can be added. Unfortunately, some components are not ready yet for that > (for instance, the ValidatorInterface relies on Constraint objects, but > there is not interface for them). > > Publishing the Symfony2 API will also force us to think more about our > interfaces (see ValidatorInterface), outside of a Symfony2 context. > > Fabien > > -- > Fabien Potencier > Sensio CEO - Symfony lead developer > sensiolabs.com | symfony.com | fabien.potencier.org > Tél: +33 1 40 99 80 80 -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
