I'm creating a Symfony bundle in isolation, outside of any Symfony installation, to be used across several of my projects. I'm new to this type of workflow in Symfony and I'm a bit confused about how to best approach it.
I know I can write unit tests in order to test the functional side of the bundle, but I've also mapped out about 25 Doctrine entities that I would rather not have to manually define the getters/setters for.
I assumed I'd be able to install the Composer dependancies and then use vendor/bin/doctrine to generate them, but Doctrine throws an error, saying I should define a config-cli.php file, which is intended to instantiate an entity manager, which requires a connection.
That's fine, but given there is no actual database (in theory), I don't want to define a connection. I just want to generate the entities and test my services with PHPUnit, and then load the bundle into an actual Symfony installation later.
Am I going about this wrong? An article explaining the workflow would be very helpful, but I'm not finding anything through Google.
Generation of getters and setters is a common feature of IDEs. You can use the free NetBeans IDE, while some might prefer to dish out some money for PhpStorm. Both IDEs can generate the getters and setters for you.
So it appears that it's not possible to run the generate:* commands without an instance of the entity manager, not even just to generate the getters/setters. Unfortunately that means a connection is required, which is what I'm trying to avoid for this stage of the development.
I've been looking through some of the more popular Symfony bundles out there, trying to figure out how they handle it. From what I can gather the pattern is to define a base, non vendor-specific model in the Model/ namespace using standard DocBlocks for the properties (which any ol' generator can be used to parse and generate the getters/setters for,) then to extend the class in a Doctrine specific entity within the Entity/ namespace.
As Entity\Foo extends Model\Foo, the type hinting would still be valid, and you only need overwrite the property annotations and any methods requiring Doctrine specific code.
Although it's a little more work initially (ignoring the generation process,) I actually like this approach. Not only does it keep the repetitive getter/setter boilerplate code separate from the Doctrine mappings, but it actually follows best practises by de-coupling the models from Doctrine altogether.
Related
I have started to learn Symfony (4.1) and I have a question about annotations.
As far as I know, annotation are just comments in terms of php and they are not a part of the language itself. However they are rather powerful thing in Symfony.
I want to know, how it all works.
Is there a code preprocessor which parses the source files dynamically and creates new php entities?
But if it's so, how does it affect the performance of an application?
Why should I use special namespaces for certain annotations?
Put simply, I would like to know how do annotations in Symfony work, the mechanism of this feature.
Yes, indeed, annotations are not part of the language itself. But they're also not the part of Symfony framework.
Annotations are usually handled by doctrine/annotations package (most common). It utilizes reflection to read and parse these comments and transform them into annotation objects (every annotation has an annotation class which it represents).
Then, its up to the library to make use of generated objects representing these annotations.
So to answer first question - yes, there is a preprocessor. But it doesn't "create new php entities", because its the job for the library that uses those annotations (e.g. Symfony framework or Doctrine ORM).
How it affects the performance, depends on the library that uses them. If they would be parsed on every request, that would indeed affect performance. So e.g. Symfony and Doctrine ORM cache this data or create proxy classes etc.
So the answer to second question is - it might if used incorrectly, but it usually is not (in production environment) as they are simply not parsed every time.
The last question doesn't really relates to annotations. Since annotations are really classes, the reason for namespacing them is also the same. To avoid conflicts between libraries and for sake of readability.
I wonder if there is an interface that diverse ORM should implement for Symfony or not.
The question came up when I was building a service that accepts an ORM (Doctrine right now), and wanted to declare type.
I guess different ORM have different behaviour and classes... in those cases, how can build entities that do not depend on specific ORM in case one wants to switch later?
Generally, Symfony is agnostic in regard to your choice of ORM.
The standard edition comes bundled with Doctrine and also contains some “bridge” code to ease the integration.
However, you can use any ORM you’d like to. For example, Propel is known to work well with Symfony, too. The Propel team also maintains an integration bundle.
There is no “interface” in the sense of a formal description an ORM has to comply with. There is no such thing as interface SymfonyOrmInterface {}.
Think about it, how and why should Symfony demand this? Symfony is a HTTP framework built on a set of loosely coupled components. Most of these components don’t even know what an ORM is or if one is currently available in the application.
You will usually install your ORM through composer, and it will be available in your business code (assuming that it supports autoloading with PSR-0/-4).
Of course, for a proper integration of an ORM into Symfony, there are some conventions and features, such as:
CLI commands, e.g. for schema updates,
Managing configuration values through the global config.yml and parameters.yml files,
Providing services and dependencies through Dependency Injection.
These are implemented in integration bundles, usually provided by the respective ORM vendor.
For your business code, this means that you can’t just replace one ORM with another one. There are significant differences accross ORMs in regard to storage abstraction, caching, querying, hydration, etc. Replacing an ORM will always require you to adapt your business logic to some exent, and not only in a Symfony project.
I'm trying to add Symfony 2.0 ACL to my frameworkless PHP application. Because of the lack of documentation on how to use Security component as standalone I've got totally confused and I've got stucked with questions: What class to include first? Which object to instance? Is it possible to be used without models and controllers?
Any suggestion on how to start or any good link?
Thanks
The SecurityServiceProvider for Silex might be a good place to start, as it integrates all of the essential component services in a single file. Although large, you'll probably find it much easier to digest than Symfony2's SecurityBundle.
In the interest of maintaining your sanity, you should consider using a service container to organize all of these objects. In the aforementioned provider class, the Silex Application class is a Pimple instance, so you should be able to port it stand-alone Pimple with modest effort. I saw this because integrating a Pimple service container into your application should be less invasive than adopting the Silex framework.
Once you have the essential security component classes working, you should be able to following along with the ACL documentation and add additional services to your container as needed. At that point, the ACL-specific sections of the SecurityBundle might prove helpful, as you can focus in on the relevant bits. Keep in mind that there are multiple cookbook entries for ACL in the documentation.
What class to include first?
You will most likely need to include at least parts if not all of the security core, then which ever ACL implementation that you are wanting to use. You can look at the dependencies that are listed in the beginning of the ACL implementation and see what they extend. For instance, the ACL/DBAL has the following dependencies called in the header:
namespace Symfony\Component\Security\Acl\Dbal;
use Doctrine\DBAL\Driver\Connection;
use Doctrine\DBAL\Driver\Statement;
use Symfony\Component\Security\Acl\Model\AclInterface;
use Symfony\Component\Security\Acl\Domain\Acl;
use Symfony\Component\Security\Acl\Domain\Entry;
use Symfony\Component\Security\Acl\Domain\FieldEntry;
use Symfony\Component\Security\Acl\Domain\ObjectIdentity;
use Symfony\Component\Security\Acl\Domain\RoleSecurityIdentity;
use Symfony\Component\Security\Acl\Domain\UserSecurityIdentity;
use Symfony\Component\Security\Acl\Exception\AclNotFoundException;
use Symfony\Component\Security\Acl\Exception\NotAllAclsFoundException;
use Symfony\Component\Security\Acl\Model\AclCacheInterface;
use Symfony\Component\Security\Acl\Model\AclProviderInterface;
use Symfony\Component\Security\Acl\Model\ObjectIdentityInterface;
use Symfony\Component\Security\Acl\Model\PermissionGrantingStrategyInterface;
But you would probably need to check each of those listed for their dependencies, and load those as well.
I would back-track through the dependencies, and keep track of what needs what. Cull those classes out into a separate location so that you have only what you need, and use some error trapping to determine that you have it all.
Which object to instance?
Your ACL. If the dependencies are all determined, and loaded, then you should be able to instantiate the ACL class object.
Is it possible to be used without models and controllers?
To be honest, I am not sure that using ACL outside of S2 is possible without a WHOLE lot of work, but if you can get it instantiated with everything it needs, then you should be able to use the object without an MVC model.
Unfortunately, from what I understand of S2, it is a full stack framework, and meant to be an all or nothing kind of thing. but if I were going to try and make it work, this would be the way I would go about it.
If u want to understand how to use use symfony2 component and how to integrate that within your project then read Fabien Potencier blog 'create your own framework'
post that will definitely help u to understand core of framework from and how to bootstrap symfony2 component in your project
there is also good document for ACL on symfony website
I am new to ORM and I am really keen to learn it. I successfully managed to install all classes and configurations for Doctrine 2.1 with Zend 1.11.x by following this tutorial.
http://www.zendcasts.com/unit-testing-doctrine-2-entities/2011/02/ Which uses Bisna plugin and doctrine scripts.
Now my problem is he is clearly explaining how to create entities and tables through doctrine classes but do not explain how to auto generate the proxies and repo classes from already existing database which helps me to select, insert and update. I always create my databases using MySQL Workbench.
I also followed the below tutorial as well
http://www.zend.com/en/webinar/Framework/70170000000bSrG-webinar-zf-v-1-doctrine-v-2-20101214.flv
My database is so complex with relationship flowing across every possible way. If I follow the steps which is explained in these tutorials I will never complete my project. Can any one please explain how to start using Doctrine after configuration. Considering I already have a database and my Model folders are empty. I have my folder sructure as below.
C:/zf/library/Doctrine
C:/zf/library/Symfony
C:/zf/library/ZC -- (my model which should contain the proxies and repo of Doctrine. At the moment it contains nothing.)
C:/zf/library/Zend
C:/zf/scripts/doctrine.php
Please help me!
I posted this same post yesterday and no one replied to my post. Please let me know if you need anymore information from me.
Thank you,
Karthik
According to Doctrine you should create your entities first yourself and then create your database schema from these entities.
But because you already have a database you probably don't want that. It is possible to convert your database to Doctrine2 entities in PHP, XML or Yaml.
You should take a closer look at the commandline tools Doctrine offers with the Bisna glue because there you can generate a lot of stuff.
To generate your entities FROM your database consider the following command:
php doctrine.php orm:convert-mapping --from-database php ../library/Application/Entity
You can also define the namespace and a base class which your entities have to extends with: --namespace=namespace and --extends=class.
Doctrine2 warns you to convert your database to entities because not everything could be auto detected or supported. For instance ENUM datatypes are not supported by default in Doctrine2 so converting your database will raise an error.
It's a good idea to check all your entities especially associations before you use them. Hope it helps you.
If I understand your question correctly, you have your entities already configured and need to auto-generate your proxy and repository classes.
Both can be created using the following Doctrine CLI commands from your application's root directory:
php scripts/doctrine.php orm:generate-proxies
php scripts/doctrine.php orm:generate-repositories library/
If you're looking for a way to auto-generate your entity classes, unfortunately I don't think a solution is available for this yet.
A support rep at ORM Designer said they are "working on" this feature and that it is "very demanded." Here's hoping it will be included in ORM Designer 2.0 since there is generally a lot of repetitive work involved in coding/mapping entity classes that could likely be automated.
You can use the orm:generate-entities command if you provide mapping information in either XML or YAML format.
See http://www.doctrine-project.org/docs/orm/2.1/en/reference/tools.html#entity-generation
For development, set proxy generation to be automatic in your config, otherwise, use the orm:generate-proxies command.
Unless you need to customise your repositories, generic ones are created in the entity manager when requested. To specify custom repositories, simply use the repository-class entity mapping attribute.
See http://www.doctrine-project.org/docs/orm/2.1/en/reference/xml-mapping.html#defining-an-entity for an example
Is there a way to use Doctrine using the model classes I've already setup for my Symfony applications without having to call Symfony with all that overhead?
This is more to satisfy a curiosity than anything else. For all the scripts I've used, I've just been able to instantiate Symfony (which typically turns out nice since I have all of the features that I'm used to working with on this particular project. But there has to be a way to load Doctrine and use the Symfony model classes without Symfony... Right?
Doctrine isn't dependet on symfony. Doctrine is a "framework" on its own. It has it's own autoloading and can therefore work with it's classes like a regular PHP app. You can integrate Doctrine with other frameworks if you want (like CodeIgniter or Zend). So you have every freedom you need without the need to do some tedious migration of your models/data/... from one system to another.
I've come to the conclusion there really isn't a way to use the model classes from Symfony elsewhere. With a little work, you can port over the classes to a new Doctrine model (even if you use the generator, since the main model class just extends the base which extends sfDoctrineRecord (from the API docs, you can see which functions will need to be removed).
Otherwise, there isn't a practical way of doing that.
Anytime I need to access the Symfony model, I'm making a task or plugin since I do typically need part of Symfony's functionality.
As far as Symfony2 goes, just looking at the documentation makes me want to run screaming. It's not mature in any form or fashion (but, then again, neither is Symfony "legacy"). So, I'm not sure if the process would be any easier there.