I need the equivalent method in symfony framework which is there cakephp model->save() method , I do not want to use doctrine orm I just need cakephp like solution to my problem
What you're looking for (i.e. $model->save()) is called Active Record. Doctrine was using it in version 1.x but it does not anymore since version 2.x. You need to find some ORM which does and use it in your Symfony application. As far as I know you can't use Cake's ORM as a standalone component hence you can't inject it in Symfony so you need to find some other Active Record ORM.
You should give Propel a try (and its integration with Symfony - PropelBundle
)
You need to take time to approach Symfony2, you just can't look for an equivalent for every single thing. Learning how to do things "the Symfony" way will be worth in the mid/long run, because the logic is different between those 2 frameworks in many places you won't be able to reason like this for long.
A great place to start is the Symfony book: http://symfony.com/doc/current/index.html
Without Doctrine, you don't have the notion of "model". Then you can only fall back to save (array) data manually using PDO.
Related
I've been provided with a large set of JSONSchema (draft 7) describing a model of incoming messages for a SOAP API.
Based on that i have to create/generate PHP/Doctrine entities to save incoming json messages.
Because that is a large set of files, manual work is not an option. I have to build a generator.
I did some research and there are some php libraries that transform JSONSchema to a PHP model, but not to Doctrine entities.
I know there is an ApiPlatrform project - based on Symfony (i use Symfony as well) that has a schema generator tool to generate entities.
API Platform embraces open web standards (Swagger, JSON-LD, GraphQL, Hydra, HAL, JWT, OAuth, HTTP.) but unfortunately it doesn`t support jsonSchema.
Using this generator would be the perfect solution for me because I could go directly from JSONSchema to Doctrine+Symfony entities.
So now I'm looking for the way to transform JSONSchema to , i think it would be best for my project, to Swagger 3 (i could use Swagger later on for my API).
I didn't find any libraries or documentation that will do that.
There are some libraries that can create PHP classes (so far swaggest is best one i think), but none to create entities.
So now i have to options:
1.JSONSchema to e.g Swagger and use ApiPlatform schema generator to create entities
2.I use Swaggest to create PHP model classes and then somehow i convert it to entities
As a third solution i was thinking that maybe there is a way to transfor JSONSchema to mysql database and then create entities from it (there is a symfony/doctrine generator) for that (here im bit afraid of loosing some relations between tables)
Both solutions are good for me , but I think 1 is best.
So my question is , do you guys know any libraries or can you direct me to how to transform JSONSchema to Swagger ?
My goal is to have a generator that creates a nice and clean PHP Doctrine Entities with all relations and preferrably validation without any additional code (some libraries creates a lot of code on top of PHP classes)
Thanks in advance for any help and suggestions
Situation: My boss ask me if I can create an entity from a json file. Not populating one entity with values from the json, but creating a new entity with its corresponding file, table and relations.
Could anybody give me some documentation, or an example or an starting point?
Edit1:
My bad, Cerad. I have been developing web apps with symfony (with doctrine as ORM) for about 2 years now. I'm used to its workflow. But i have never considerated this request.
No, you cannot.
This is totally against the principles of how doctrine works internally. (Caches, Proxies etc)
What is even the use case?
I am switching over to Symfony for a project that I am working on but I need a little advice on how to structure the files when it comes to models and using doctrine.
I have a custom framework that I use, which in turns uses the MVC model. Pretty much all of my MYSQL database queries are stored in the models and I access them through the controller.
Now after looking at Symfony2, my interpretation is that "model" files in Symfony are called Servies. Is this correct?
I have also generated a number of Entities that correspond to my MYSQL database. My question here is do I place my custom Doctrine queries inside the Service files or do I create them inside the Entity files?
I'm a little unsure how to structure this.
Thanks
Pretty much all of my MYSQL database queries are stored in the models
That's bad, but I'll mention about it later.
Now after looking at Symfony2, my interpretation is that "model" files in Symfony are called Servies. Is this correct?
Queries should be done in either repositories or in some cases in services.
If your query returns entities, then it should be repository for sure.
My question here is do I place my custom Doctrine queries inside the Service files or do I create them inside the Entity files?
Entities should be plain PHP objects. They shouldn't depend on anything than other entities. Entities actually doesn't even know anything about database. It's pure object oriented business logic.
Again, all DB queries should be in repositories or services.
I would suggest to go through Symfony Book in first place, to get idea of how "the Symfony way" works.
Symfony is not MVC framework:
Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part [...] Symfony2 is an HTTP framework; it is a Request/Response framework.
And it is great. Symfony allows to make your model as you wish without any restrictions. The Doctrine (ORM and/or DBAL) is a separate set of libraries. You can use any other library, or build your own persistence layer abstraction, or work with native SQL through PDO/MySQLi/etc.
Service is just an object that registered in the container and have some dependencies. Services can doing anything. They can represent your model, but it is not a requirement.
Organizing Your Business Logic (The Symfony Best Practices)
Doctrine ORM Best Practices
I was going through the Symfony2 best practices and got confused on two things:
1 - Annotation usage - It says that for Routing and Cache we should use Annotations. But, I prefer to use annotations for ORM & Validation and YAML for Routing (one single file for all routes). How it is a bad practice?
http://symfony.com/doc/current/best_practices/controllers.html#routing-configuration
2 - For reusable bundle (never created one), if I wish to include any JS library like jQuery then it's not a good practice? Confused.
http://symfony.com/doc/current/cookbook/bundles/best_practices.html#vendors
Please note that "Best Practice" doesn't mean that doing anything different from what's suggested is wrong. Instead, anything is perfect if you know why you're doing it. The Best Practice guide is designed to take away some decisions for beginners. They already have a hard time learning the framework, having to make decisions like where to put code and which format to use would make things infinitely more difficult.
With that in mind, the reasons for the best practices you mentioned:
1 - Annotation usage - It says that for Routing n Cache we should use Annotations. But, I prefer to use annotations for ORM & Validation and YAML for Routing (one single file for all routes). How it is a bad practice? http://symfony.com/doc/current/best_practices/controllers.html#routing-configuration
Having less files makes it easier to follow what's going on. Imagine having a route, controller, an entity and some validation. This means that one has to learn the following locations: app/config/routing.yml, src/AppBundle/Controller/StaticController.php, src/AppBundle/Entity/SomeEntity.php, src/AppBundle/config/validation.yml and src/AppBundle/config/doctrine/SomeEntity.orm.yml. That's quite a big list to get familair with.
If Symfony recommends to use annotations for everything, you end up with the following list: src/AppBundle/Controller/StaticController.php, src/AppBundle/Entity/SomeEntity.php. That's quite an improvement. This is the reason that Symfony recommends to use annotations if you're starting to learn the framework. If you're familiar with Symfony, you probably make your own choices and decide which format you like and which you don't like (some people like annotations, others hate them and prefer XML or YAML).
2 - For reusable bundle (never created one), if I wish to include any JS library like jQuery then it's not a good practice? Confused. http://symfony.com/doc/current/cookbook/bundles/best_practices.html#vendors
It's often not very great to commit dependencies. For that reason, Composer was created. For front-end dependencies, Bower/BowerPHP was created. Using something like that means your code is easier to share.
Of course, as Symfony is a back-end framework, it's perfectly fine to use jQuery or whatever library you like.
1.that say:
Make your controller extend the FrameworkBundle base controller and use annotations to configure routing, caching and security whenever possible.
for that you have thin controller and you can only have routing & caching & security in your controller as annotaion.
orm mapping & validation are in entities no in controller
and that say:
In addition, using annotations for routing, caching and security simplifies configuration. You don't need to browse tens of files created with different formats (YAML, XML, PHP): all the configuration is just where you need it and it only uses one format.
because, routing & security & caching are related to a controller, but orm mapping & validation are diffrence and can use in onther places(controllers, repositories, services and ...)
2.
For reusable bundle (never created one), if I wish to include any JS library like JQuery then it is not good practice
and if you will use third-party bundles, that is better that you use a depedency manager as composer or bower.
see sonata admin bundle that is a good & big project that use bower for third-party bundles as jquery, bootstrap & ...
We're planning a new intranet for our organization. Some part is like a CMS, and there are some custom-made applications.
The Symfony2 CMF distribution looks fine for building the CMS part of the intranet, but other parts like Doctrine, "normal" SQL databases, etc, looks better for the custom-made applications for the intranet.
Because I need common authorization and authentication system for this intranet (against an Active Directory), I supose that I'll get better results building all in only on app. So, can I mix a CMF application with a normal application, and both use the same database (an Oracle DB)?
Yes you can easily mix the CMF with other Bundles. For example the routing allows using both routes from the CMF as well as "static" routes defined in yml files. Also you can easily also add the ORM next to PHPCR ODM. If you use Doctrine DBAL for storage in PHPCR, you can even reuse the same connection configuration with the ORM etc.
In brief yes it is, and I do this in my own Symfony2 project. I combine both SF-SE and SF-CMF bundles.
In fact, with Symfony2 it's very simple (this is just a matter of choosing the most suitable Bundles; SF is a very decoupled framework, which is why I don't plan to migrate to any other solution for the moment), but I'd like to share some of my experience with doing that. Actually the one most important question to think through to make a decision about how to combine both "worlds" is this:
Composer.
After some inquries I found out that since Symfony CMF is (in a way) based on Symfony SE, and not vice versa, it's better to start with the latter, as it contains the most core features (though I did it also in the opposite way, rather not recommended). So just take a SF-SE's composer.json, take a look at bundles from there you need, and then take a look at differences within SF-CMF's composer.json. You should end up with the most suitable set of bundles.
The basic features from these bundles to look-up for are:
MODEL - Doctrine ORM, PHPCR-ODM, or both - if still not sure, don't hesitate to ask a comment, I'll share here my experience furthere.
ROUTING - the primary question here is how flexible routing do you actually need? If not sure, I'd go with standard SF Router, and then possibly replace it e.g. when still on a dev stage.
OUT-OF-THE-BOX CMS FUNCTIONALITY - bundles such as CreateBundle, MenuBundle or MediaBundle may help you building surprisingly fast, but not quite flexible soltions. In general, I ended up without using most of them, and if using, then I mainly take some Interfaces I do implement in my own Bundles (to ensure future compatibility with possible other bundles to be potentially used).
Besides of these above, I created a number of Bridge Design Pattern and Provider Design Pattern solutions to make some bundles working together, to adjust their functionalities, or simply to decouple things.
In programming almost everything is possible. But think about restrictions delivered with CMF (routing for eg.).
Maybe you should consider Standard Symfony with Sonata? I think CMS pages it's only small part of your system and implementation it in standard symfony will take smallest part (and cost) of whole project.