I have a problem. My client wants to have a website in one symfony framework package and the CMS integrated in the other Symfony framework (Service Panel of the company).
So, we have Symfony A and B.
Now that there is a blog on the website (Symfony A) among a few other dynamic pages. All the Delete, add and update stuff needs to go into the service panel (Symfony B) with forms and such.
I know I can use multiple Entity Managers, but that'll only work if the website bundle is placed in the service panel framework (Symfony B), because of the mappings. I think it isn't possible, but they really want to have the CMS in their Service panel and the website in another symfony framework instance.
Is there a 'remote' solution, so that Symfony B (service panel) can change and manage the database of the website (Symfony A) without migrating the website bundle (Symfony A) into Symfony B? The website will run on the same machine as the service panel will. Only difference is they are completely separated of each other.
If I'm not clear enough, please tell me. I'm trying to be as clear as possible.
Hope somebody is able to help me with the issue.
So let's say we want to update a blog.
Symfony A would process these requests:
GET /blog/42 - Returns json rep of blog 42
PUT /blog/42 - Accepts and updates blog 42
Easy enough. FOSRestBundle and JMSSerializerBundle can help with some of the plumbing.
So Symfony B uses curl (probably) to GET /blog/42 and converts the json data to a php array.
At this point you have a major decision. If the entities are simple and stable the Symfony B could just use the array representation. Symfony forms accept arrays no problem. So this maybe all you need.
If however you want to convert the array data into a real Blog object that matches Symfony A then you need to make some more decisions. The Symfony A entities are really just plain objects. You could tweak Symfony B's autoload so it can see the Symfony A entities. So B can get the entities from A (and then map the array data to the entities) without having any direct links. Autoload just needs to know where the Symfony A entities live.
Or you could go one step further and make a BlogModelBundle in which the blog entities (without any doctrine stuff) are defined. You would then have both applications load this bundle. The A app would then extend the model and add the doctrine 2 stuff. The B app would just hydrate the models using json. This is probably the best approach for the long term.
Related
We are migrating our project from custom CMS to Symfony 5.1. Instead of Database, we are using REST API. Currently we are using Entities without connecting them to any database (with no #ORM annotation or configuration file), and we put all REST logic inside a Repository folder
Currently, if we save our entity in SESSION
$example = new Example();
$request->getSession()->set('example', $example);
On every next request, we will get error:
Class "App\Entity\Example" is not a valid entity or mapped super class.
Of course, this could be fixed if we put correct #ORM annotations, but then it requires a database.
Can this be fixed, and if it's not possible, what would be proper architecture for this scenario?
Let doctrine be the tool to manage the data. In fact that there is no database, you will need something similar to let doctrine manage the data of the REST API.
Take a look at this bundle:
https://github.com/CircleOfNice/DoctrineRestDriver
Edit:
In addition to one of the comments, the DoctrineRestDriver is not maintained anymore. In fact, the bundle does not support Symfony 5.x.
To use the functionality of DoctrineRestDriver you could downgrade your symfony to the supported 4.x.
Your architectur to use doctrine to manage your rest-api can be solved by using the DoctrineRestDriver package.
If you don’t want to downgrade your symfony, you will have to implement your own „data-manager-solution“, to use the api as your database.
But I think the architectural problem with the rest api doesn’t relate directly to your current error. We need more code to understand, where your specific mapped super class error is from (repository, entity).
I recently started learning PHP and Symfony 4 and I developed an app. Now my next task is to change the architecture of the project, from MVC to client-server. More exactly, I need to have my templates and controllers in an application and the business logic in another application. Any ideas how I can do this? I can't even figure out how to run 2 different symfony projects simultaneously.
A client-server application is an application base on a communication model call client-server: wiki
MVC is a way to develop and structure application: wiki
But i understand your needs. You want to keep a symfony app but you also want to put all the logic view and front end features into a separate app (like React or Vue)
Your Symfony App will still use MVC pattern, just you'll replace what the controller give to the view.
The best way is to turn the Symfony App into API with normalize view data like JSON or XML. Those data will feed your front app.
To achieve this you can use this bundle, which turn your model layers into API: API Platform
I have an application which is developed in Symfony2. Now the structure for it is as follows:
FrontBundle - includes everything related to the application's view and UI.
PersistanceBundle - includes everything related to the persistence layer of the application.
DomainBundle - includes everything related to the entities of the application and the services.
Is this structure ok? Or bundles are used like forum feature - ForumBundle - which includes every layer (controllers, services, domain logic and persistence) related to the forum.
There are no hard and fast rules on how to structure your app using bundles, but here's what I came to after developing on Symfony2 for close to a year.
Use one app specific bundle. At first, I started with multiple bundles like CommonBundle, UserBundle, MainBundle, BlogBundle, ContactBundle, etc. That proved to be not so convenient in the end, so I switched to just one app specific bundle — AppBundle.
You can organize your code neatly using subnamespaces. For example, the backend controllers would go to the AppBundle\Controller\Backend subnamespace.
Note that I'm talking about one app specific bundle — that stuff that's unique to the concrete app and won't make sense to reuse elsewhere. You can still develop separate bundles for reusable stuff and put them into the vendors infrastructure.
Keep non Symfony specific stuff out of bundles. There is no need to have a bundle for the model and the Service Layer classes in a bundle if they are not Symfony2 specific. See this question and my answer for further details.
Like Elnur said, use one AppBundle is a good practice.
A single bundle implements the MVC pattern himself so i think it's not a good idea to use bundles to separate your layers.
I think the best way to use bundles is to think "open source". If the feature you are developping is enough generic to be released for everyone, or to be reused in a future project, place this feature in a bundle.
This way will force you to build the feature without any business rule which belong in your AppBundle.
Bundles are bricks
There are different ways to organise application structure for your projects. But if you want to distribute your bundles and follow symfony best practices, then bundles are more features than separation of UI. More about bundles read in documentation.
I have two projects with the following structures, both valid I think:
making a bundle for each feature: BlogBundle, StoreBundle and so on,
and AppBundle that contains general stuff. No Backend/Frontend
separation. It's SaaS where backend is frontend in most cases.
One bundle for frontend, one for backend. They share only entities
and domain specific stuff. The application has two different ends.
I have a web application which has been developed with symfony 1.4. I have a pretty large code base (and growing). Circa 80,000 lines of code (actions, forms, models, templates etc.)
I'm using the default doctrine version which ships with symfony 1.4.
I've just started developing a mobile version using Sencha touch. I don't wish to use symfony for the REST web services because:
REST services in Symfony 1.4 is not great. For example, If i want a PUT request I have to pass a 'sf_method' parameter specifiying that the request method is PUT. This isn't true REST and it's not ideal for Sencha touch.
I don't need all of the unnecessary symfony functionality(for example the plugins that are autoloaded in the ProjectConfiguration file, the form framework etc.) that you'd use to develop a standard web app. All I need is to define my REST routes and return the specified JSON (as everything that needs to be returned for Sencha touch will be JSON)
I want to keep my mobile app as bloated-free, efficient and quick as possible. And unfortunately for this task, Symfony 1.4 would not be the best choice for using as the backend architecture for my mobile app. If I had chosen symfony2 (it was in it's beta phase, alas) it would be a different story as symfony2 supports true REST functionality. What I do need, however, is the ability to use my current doctrine models (I have circa 90 models) in a chosen REST framework.
Basically, in a nutshell what I need is as simple as this:
Call a rest route->Query my doctrine models->return the JSON without using symfony.
So my question, what would be your advice? I don't want this to be a question of which is the best PHP rest framework, however, what I would like to know is what would be a good REST framework which i can develop efficiently and quickly REST service, make use of my doctrine models and is easily extendable.
Here at my employer, I've created a rather big application with a ExtJS frontend, and Symfony 1.4 backend. And two be honest, I don't feel limited by Symfony 1.4 in any way?
First of: I created my own base controller class (which extends sfActions). This controller can handle (render) different types of data. It has generic handling for Doctrine_Query, Doctrine_Collection, Doctrine_Model and array types.
Also the plugins make me help organize the code, and in some cases plugins are shared between differend projects, so that's also a big plus.
And the extra functionality like forms: it's only prepared for you in the autoloader, you don't have to use it. And I don't think it causes any real performance issues (at least not for me). But I like to use the extra sfValidator framework, to make sure data are correct.
The only real "problem" is indeed the HTTP REST-ful commands, especially PUT and DELETE. I just worked around this problem by generating a controller for each 'manageable' model, and implement specific get, list, create, update and delete actions. So when I would like to manage an Object, I call the objects controller, which has executeCreate, executeUpdate and executeDelete actions.
The reason I read, was that Symfony didn't and couldn't implement this feature because PHP has really bad support this. I don't know if this is true, but if this is your only 'real' issue, you could try to fix this in the Symfony core.
So my advice:
If the raw performance is your problem: try profiling your code, install a opcode (APC) cache, and profile your code (yes, that's double).
If the HTTP PUT command is your problem: I would either work around this (that's the way I solved it), or try to fix it in the core.
I'm just working through the Symfony2 Bible and I'm a little stuck on the bundle system. It is a great feature but I'm not quite sure how to split my flat PHP application into bundles. It's my first time splitting my PHP code into a full featured MVC framework.
I'm working on a few online games (based on PHP) but how would I define the bundles ? Is it like one single onlinegame1 bundle with all the controllers and functions - Or like a login bundle, a register bundle, a war bundle - summarized one bundle for every single PHP file I got ?
I want to start clean and correct but I'm not quite sure if I understand that feature.
You could think of bundle as an independent reusable component - in most of the cases at least.
Let's imagine a personal blog website. I'd split it into ArticleBundle, UserBundle, CommentBundle and finally MainBundle which would stick all these other bundles together, creating your website. The main point is that you can take for example ArticleBundle and reuse it easily on other project without it being tied to any other bundle.
From Symfony2 book:
A bundle is similar to a plugin in other software, but even better.
The key difference is that everything is a bundle in Symfony2,
including both the core framework functionality and the code written
for your application. Bundles are first-class citizens in Symfony2.
This gives you the flexibility to use pre-built features packaged in
third-party bundles or to distribute your own bundles. It makes it
easy to pick and choose which features to enable in your application
and to optimize them the way you want.