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/45be152c33546affa4f1de4920ca14b0a0351620
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
