I'am new to symfony, even more to symfony cmf. I have project idea and want to get started, but as I'am reading documentation I get more and more confused.
What I need to build is CMS with tree like structure routes and multilingual support for those routes. However I'm confused with this PHPCR stuff as it's new to me and I don't wan't to install java to my server, does that means, I can't use CMF?
I read of Doctrine ORM solution, but didn't find example, clear documentation and there's also 2 more concepts, I can't figure out:
doctrine / phpcr-odm
jackalope / jackalope-doctrine-dbal
How different they are or maybe they complement each other?
So to summrize the question: If someone could explain me PHPCR, PHPCR-ODM, doctrine-dbal, and tell me can I create CMS using CMF and only MySQL database (I saw note that it's possible load routes from DB) and how would one should approach this problem?
The PHPCR story is a bit different from what you know from other DB storage systems. That can cause confusion, so let me explain the concepts behind it.
The basic flow chart can be represented as this:
The Application layer is the PHP code that you have written. To put some data in PHPCR, you create a new node (which is like a row in a MySQL db) and inject that into the PHPCR layer. This layer communicates with a jackalope connection, which is bounded to the DB.
If you are using the Doctrine PHPCR-ODM, there is a new layer between the Application layer and the PHPCR layer. You will not use the PHPCR directly, you'll only use it through this Doctrine layer.
The Jackalope layer can have multiple different ways for different DB layers. By now, there are 2 options for the Jackalope layer: Jackrabbit or Doctrine DBAL.
Using the Jackrabbit option, you communicate through Jackalope with a JAVA Jackrabbit DB system. This is the most powerfull, feature-rich and properbly the quickest option.
You can also choose for using Doctrine DBAL. This Jackalope adapter will use the Doctrine DBAL layer to communicate with the DB. Doctrine DBAL can work with most of the relational databases (SQLite, MySQL, Oracle, etc.).
Almost all examples from the Symfony CMF use the Doctrine DBAL version, as it's easier to set-up if you are new into the PHPCR world. Just look at the documentation, sandbox or standard edition for examples.
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
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'm supposed to make CMF feed a Redis queue which will then be polled by other servers. I'm still learning about CMF and it has become a little overwhelming to understand it. I've been using plain Symfony2 for a while, though.
I understand CMF can save the changes I made in the WYSIWYG editor as XML in the database. How much control do I have over this? Is there any project trying to interface CMF and Redis (or another non-doctrine database)?
I'm guessing I can implement a controller that would fetch these edited fragments from the database and send push them to Redis. But the fragments are in XML. Is there anything already built to fetch this data?
I appreciate any pointers. Thank you.
First lets briefly separate two things, the CMF is a set of components and Bundles that can largely be used independent of each other. All of them are storage agnostic but many currently only ship with support for PHPCR.
PHPCR in turn is a content repository interface for CMS which supports tree structures, full text search etc.
The reference implementation of that is called Jackalope. Jackalope in turn provides different so called "transports". You seem to be looking at the Doctrine DBAL transport for Jackalope which in deed stores XML fragments into an RDBMS. There is another one which uses the Jackrabbit Java server.
At any rate, writing a Redis based transport for Jackalope is probably not what you want. From what I can read is you actually just want a queue stored on Redis? In that case I would just use this Bundle here https://github.com/snc/SncRedisBundle together with standard Symfony2.
If you also want CMS editing capabilities, you can easily add CMF based editing into any Symfony2 project. Of course you would then use Redis for your queue and one of the Jackalope transport layers for storage. So you would be using more than one database. But this is a sensible architecture.
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.
I have the main website that uses a database to store and access user accounts. I'm using EF to manage the schema. I also defined site-specific POCOs and have migrated them to the database.
Now, what if I want a separate website, for example, a resource server (Web API) that would expose (with authorization) the same data set up on the main website?
Do I create the same POCOs and derived DbContext on the resource server again? That seems like duplicating work, though.
What if I wanted to create new POCOs on the resource server and reflect them onto that same database? Wouldn't that conflict with the current migration (which is saved on the database), then subsequently mess up the EF setup on the main website?
I've seen the suggestion of putting the POCOs and DbContexts in a library and have multiple projects reference that same library. This seems viable, however I'd have to hard-code the connection string, which seems dirty to me.
I'm starting to think that EF is probably not recommended for this kind of setup. It seems like a database-first approach plays better here - though I would have to manually reedit the data contexts (most likely, LINQ-SQL) for every database schema change.
Are there any lesser-known capabilities, facts, practices, etc., for/about EF that would help in this situation?
Generally, you can avoid duplication by having one API serving both sites and have resources version for each if needed. On the other hand, if you choose reuse and add approach, creating additional EF code-first entities should not interfere with other site data layer if modeled and mapped carefully. DbContext connection string does not have to be hard-coded.