I would like to create a bundle with some entities inside but how is the user of my bundle supposed to add a field to my entities if he wants to?
There is some case where the user may want to add fields to the entities of my bundle but he cannot modify the source files of my bundle in the vendor.
Should I abandon the idea to let a user add fields to my bundle's entities? Or what is the correct way to let him do that.
All you need to do is to suggest to the user in your documenation that they extend your base entity class.
FOS userbundle suggests this, and can be seen here in this tutorial document
It really should be as simple as that.
You could also create a mapped superclass (probably abstract) so the user can extend those if needed. This approach is useful if you have multiple child entity classes from some kind of 'core' parent class which provides standard state or functionality.
Related
I'm new to Symfony2 and would like to know the proper place to put my universal helper class. The helper class contains things like removeCurseWords, uplodFile, resizeImage, watermarkImage, convertDateToServerTime, doStuffHere and other things used by many but belong to none. I want this class to be accessible to all the bundles in my app so where do I place it to make it available to all.
Group those methods and put them in services (see http://symfony.com/doc/current/book/service_container.html). That way you can use them cross-bundle via the service container. You could have one service for all image operations and one for the rest which doesn't fit elsewhere.
If you have your php Library i suggest you to write a bundle that wrap it for symfony2 usage for, as example, expose the functionality as services container, manage the initialization, implement for type and so on for enable your library in yhe symfony2 way, then you can share via composer in other projects.
See this for further details.
Hope this help
I always create a folder called "Utils" at the same level as Controllers, Repositories, etc Found several people doing it that way too.
How I can inject an array of services from config.yml giving class names (with namespaces) to a controller? I need to run a function from each of this services in the controller. At the moment I use $this->get('service'); in the controller, but I need to make controller independent from services. Is there a way to do this?
Edit
I don't know names and how many services will be injected, though all of them implement an Interface.
Edit2
Well, probably I did not express correctly my thoughts. I have a bundle named Widgets. It has an array of widget names, display widget holders for each widget and with AJAX I get the content and display it. At the moment I have in the Widget controller hardcoded some widget deffinitions (title and id for Ajax) and some are retrieved by calling getWidgetList from some controllers from another bundle. Well I need that the list of the widgets wont be hardcoded itself in the widget bundle. I need a way to pass this list from the config.yml. Any ideas?
Injecting an array of services is, generally speaking, not the right approach (even if there was a way to do it, which I don't think there is)
The whole reason you don't want to write container-dependent code is to keep your codebase flexible, lithe, and testable. A variable array of services is, in practice, just a mini container, so if you implemented that you'd just be shrinking the scope of the problem, not eliminating it. You'd still be making your code dependent on an arbitrary bucket of services.
I strongly recommend explicitly defining each service your controllers need (as outlined by the links in the comments from Rufinus and Cerad) or look into using something like the jms/di-extra-bundle.
Update
Maybe you need to do more research on the configuration options available?
How to Create Friendly Configuration for a Bundle
The Config Component
http://symfony.com/doc/current/cookbook/bundles/configuration.html
I am developing a quit simple website, with just some text. The text need to be editable by the user, so I am storing the text in a database. Because of that, i need to access to my Doctrine entity from every bundle, so where do I need to write that entity ?
Thank you
All your entities are accesible across your app if you you use namespaces.
Just create it, for example, at Your\WhateverBundle\Entity\Myentity and in every controller you must add: use Your\WhateverBundle\Entity\Myentity;
I think that's you are looking for, isn't it?
I'm creating a menu system using the Tree Doctrine extenion and I want to create a Twig extension to display the menu based on the requested parent node e.g. {% display_menu(side_menu) %}. This function will be in the base twig template (i.e. the menu is on every page of the website).
As I'll be storing the Menu structure with Doctrine, I thought I'd need to access the MenuRepository within the Twig extension so the first problem I came across was getting an Entity Manager into it. When looking for a solution, a few people have said that this is bad practice, which makes sense as a Twig extension is part of the View.
So although there is a solution (linked in similar questions) to my problem, my question is, is there a way I can accomplish it using good practice? Or is there a better way of doing it in the first place?
Making entities aware of any services — including entity managers — is a bad practice. There's nothing wrong about injecting an EM into a Twig extension. Although, I'd rather inject a model manager to a Twig extension, so that the extension is not aware of the persistence layer — it's the job of the manager layer.
So, I'd have MenuManager that's aware of repositores/entity managers and inject it to an extension.
I'm looking for some guidance on best practice around how to structure my Symfony 2.0 application. If I have a few bundles (Cart Bundle, Product Bundle, CMS Bundle) and I wish to use aspects of all of these bundles when composing my page how should I best do this?
I can imagine two ways to do this, but am looking for guidance on which (if either) is correct.
1) Expose all of the functionality of my bundles through services, and have these services available to use directly from within twig. This way I can pass my routing request to the most appropriate bundle (so http://myclient.org/User/Account) is passed to the ClientUser bundle to handle, but the base template which has a mini shopping cart in the navigation is able to access the information it needs directly from within twig (I don't need to pass this in)
2) Create a bundle that accesses all the other bundles in order to build up the page (like VendorFrontend or VendorBackend). This would mean that ALL routing requests would be passed to this bundle and this bundle would access the required information for every part of the page before passing off to the template.
The first option feels wrong because I'm not sure if it's even possible to allow Twig to consume services directly (though the service container)?
Second option feels wrong because It's like using a second router, the routes would be being passed into a bundle, which only exists to compose the other bundles (it's a given here that this bundle is tightly coupled to the bundles that it uses). Surely this goes against the concept of a 'bundle' that the code is reuseable.
In this example I'm trying to build a very simple e-com site for demonstration purposes only. I have a base template which will have a primary navigation, mini shopping cart, 'body' and footer. I'm storing this in the /app/Resources directory. I was planning on having all other templates inherit this one and overriding the 'body' area.
Not looking to be spoonfed, just a nudge in the right direction. Thanks.
I think that it's important to get away from the idea that, in order to generate a "page", one has to corral together all the variables that the templating involved might need in order to render, and then pass these into a template. A controller should be doing only the specific thing for the request it's serving, and no more. So if there's a specific product referenced in a URL, fetch the product and pass it into the template. If there's a specific product referenced but it doesn't exist, or shouldn't be shown, you respond with a 404/ 410/ whatever is appropriate. If there's a specific collection, fetch the collection and pass it in. The routing/ controller should be decoding the request - the URL itself, the HTTP method, etc - and translating that into something specific. Anything general and not specific to a particular request doesn't belong there.
It's also important, I would say, to abstract as best you can the bundles you use from Twig templates. I am advocating more that templates "pull" what it needs into them, rather than being pushed in, but this is achieved by the definition of Twig functions within bundles that can themselves, via the DI container, hook into data that may or may not be in the current request, etc. So you make a Twig function that can take as a parameter anything that might change - if it has to do with product categories, let it take a product category object as a parameter.
Essentially the answer is more 1) than 2), but you shouldn't be accessing services directly through Twig - you should be proxying via functions that make semantic sense within the template, that themselves are defined to have services injected into them at runtime, services that you are at liberty to define differently in any new bundles you include or write.