I'm building an app in Symfony2 that receives a HTML string via an API, does some work on it (think of something like the Tidy library, only with a different purpose) and then returns the fixed HTML.
The stuff that does all the work is mostly written in services, because they don't need to return a Response object.
Where do I store those services? I'm putting them in bundles, but there's no obvious place to store them. I understand that they can be stored anywhere, but I'm wondering what the default convention is.
If that code doesn't have to be re-usable outside of Symfony2 projects, you can just put it into your bundle.
I'd go for something like:
Acme\HtmlCleanerBundle\Cleaner\SimpleCleaner.php
Since it is a bundle, you can extract it to a separate package and re-use it for other Symfony2 projects.
If you want the code to be completely re-usable and standalone, I'd suggest you extract it to a separate library. You can still have dependencies on individual components (shameless plug: you could manage those dependencies through composer, which will be used by Symfony 2.1).
If you decide to go down that path, the bundle simply integrates the library into Symfony2 by providing DI container configuration for it.
Related
I'm planning to write an AJAX extension for the forms in Symfony3. I want to be able to use ajax requests in many forms instead of submissions.
Now I don't understand the exact relation between Bundles and Services.
As I understand it to write a service is the right way to do so. At the same time I want to make my code reusable, so I can use it in further projects.
My extension needs to have some JS and TWIGs I guess.
So, is the right way for deploying my service to encapsulate in a bundle? Or are they bundles theirself? Or can they be deployed without encapsulating?
If you want to make your code reusable, you need to make your bundle configurable, basic steps to achieve it:
Create a bundle:
http://symfony.com/doc/current/bundles/SensioGeneratorBundle/commands/generate_bundle.html
Making it configurable:
http://symfony.com/doc/current/cookbook/bundles/configuration.html
You need to put it in another repository and read it later using git submodule or packagist, depending on your strategy or if its private or not.
This steps will means your bundle cannot depend of any class internally created in your project, I would recommend to you to check some other bundles around.
A good example can be the Tactitian bundle, which integrates the League Pipeline library into SF https://github.com/thephpleague/tactician-bundle
In this code you can see how they configure the library and create the services around it!
I hope this helps you!
Background
We are planning to migrate our current code to a Symfony2 project.
In our case, each application is considered to be a country where we operate. As such:
Each application has a unique top-level domain.
Each application will have the same subdomains.
Each application has its own database. The database structure for each application is the same.
Applications will share the same business logic. Any differences in business logic will be abstracted into a configuration file. There should be a base configuration file that applications can override with application-specific configurations.
Applications will share most of the templates, but there may be application-specific templates too.
Possible approaches
Multiple repos
Each application would be a Symfony2 project by itself.
All development would take place in bundles, each application loading the same bundles thru composer.
This approach would make development quite cumbersome. Ideally I would like to test any changes in all countries without running composer etc.
Multiple apps within a single repo with multiple Kernels
Each application would have its own app in the app/ folder as suggested in here.
Duplicating the whole app folder seems a bit hackish. Not sure if this is a recommended practice?
Modify Symfony2 to support multiple applications
Modify the Symfony2 Kernel/Console/Whatever to support multiple applications.
Are there any existing bundles/examples already doing this?
[Your idea here]
Are there any other possible approaches?
Question
What would be the best approach to add support for multiple applications in Symfony2?
This is a fine approach but if you find you are sharing a lot of code...
The creator of Symfony2 does not recommend this practice. If you need multiple kernels, you most likely need multiple projects. https://groups.google.com/d/msg/symfony-devs/yneojUuFiqw/sZ8BZrzFLbwJ
IDK
For a project I have built the changes come from a $_GET parameter. What I do is, I have a primary project bundle that handles the common functionality and references the app/view for basic layout. Inside the "core" functionality, I created a controller and use it as a service so that all my application-specific bundles can use it at any point. Then I create a Symfony2 extension for each of my application-specific config definitions so that each application can have yml configs while keeping high-level config in app/config/config.yml. An advantage of this is that in the CoreBundle's controller I can create generic page routes and render like:
$this->render('Name'.$project.'Bundle:index.html.twig', array('params' => $params));
I'm new to version 2 of the Symfony framework. I made some projects with v1 but now trying to get my head around the new version and it's features.
I read over the concept of Bundles but it's purpose is not yet very clear to me.
Say you have a big web application, a CRM for example. How would the bundles look like?
Would it be NewsletterBundle (for sending newsletters), ContactManagementBundle (for managing contacts), UserBundle (for editing users and their permissions).
Or would it be less cut-up like, EmailBundle (for handling the entire email traffic), CRMBundle (for putting in all your CRM code), PermissionsBundle, ApiBundle.
I like to think of it like this: a bundle should represent a specific feature or set of like features for a project.
Your first example is a better use of bundles than your second example, because the purpose of each bundle is more defined. While it's possible to use one CRMBundle for everything, you wouldn't really be taking advantage of Symfony's ability to organize your code. Additionally, if you wanted to port over your Newsletter code to a new project, but not all of the CRM code, you'd have an easier time copying over a NewsletterBundle versus copying over the CRMBundle, and then pruning it.
When thinking about a Symfony2 project, sometimes you want to forget everything you know about symfony 1.x, since they take wildly different approaches to solving many problems. For example, in symfony 1 it was common to build a 'frontend' and 'backend' app for a project, and each app would obviously contain logic specific to those parts of the project. So you might have a Newsletter controller in both the frontend and backend apps. In Symfony2, you're better off using only one Newsletter bundle, but with two controllers (perhaps named 'frontend' and 'backend'). Again, an immediate benefit to this is how reusable your code becomes.
I have a flex application which contains different feature that includes google maps, twitter, facebook etc.
Currently I have hardcoded api keys in the code it self but I want to use a properties file/config file where I can put such things and use anywhere I want in the application.
Is it possible to achieve this in flex?
I am using swiz framework. Is it possible to achieve this using this framework?
Thanks
Priyank
We use an external xml config file chock full of config settings for dev, staging, and production environments. Load it into your app at application complete and parse the xml nodes into a value object and store it in your model.
Jeff
ReUrgency.com
if you require LOCAL CONFIGURATION (the configuration specific for each client) then the easiest way to do in flex/air application is using sharedobject because filereference has been limited only for air application. ticlib has an easy and natural way to do local configuration, you only need to add [Config] annotation on your variable or getter then you event don't need to care about how to create and manage shared object. you can take a look at this blog post for real time use.
The Swiz Example Applications have many good examples of this. Look for anywhere they are loading a service config. I believe SwizDemoApp has an example of this, or it could be SwizPresentationModelExample (those were the two I looked at, and one of them had the method I use in my Swiz apps now). :)
I'm working on an ASP.Net website along with a supporting Class Library for my Business Logic, Data Access code, etc.
I'm EXTREMELY new and unfamiliar with the Unity Framework and Dependency Injection as a whole. However, I've managed to get it working by following the source code for the ASP.NET 3.5 Portal Starter Kit on codeplex. But herein lies the problem:
The Class Library is setup with Unity and several of my classes have [Dependency] attributes on their properties (I'm exclusively using property setter injections for this). However, the Global.asax is telling Unity how to handle the injections....in the Class Library.
Is this best practice or should the Class Library be handle it's own injections so that I can re-use the library with other websites, webapps or applications? If that is indeed the case, where would the injection code go in this instance?
I'm not sure how clear the question is. Please let me know if I need to explain more.
Though not familiar with Unity (StructureMap user) The final mappings should live in the consuming application. You can have the dll you are using define those mappings, but you also want to be able to override them when needed. Like say you need an instance of IFoo, and you have one mapped in your Class Library, but you've added a new one to use that just lives in the website. Having the mappings defined in the site allows you to keep things loosely coupled, or else why are you using a DI container?
Personally I try and code things to facilitate an IOC container but never will try and force an IOC container into a project.
My solution breakdown goes roughly:
(Each one of these are projects).
Project.Domain
Project.Persistence.Implementation
Project.Services.Implementation
Project.DIInjectionRegistration
Project.ASPNetMVCFrontEnd (I use MVC, but it doesn't matter).
I try to maintain strict boundaries about projects references. The actual frontend project cannot contain any *.Implementation projects directly. (The *.implementation projects contain the actual implementations of the interfaces in domain in this case). So the ASPNetMVCFrontEnd has references to the Domain and the DIInjectionWhatever and to my DI container.
In the Project.DIInjectionWhatever I tie all the pieces together. So this project has all the references to the implementations and to the DI framework. It contains the code that does the registering of components. Autofac lets me breakdown component registration easily, so that's why I took this approach.
In the example here I don't have any references to the container in my implementation projects. There's nothing wrong with it, and if your implementation requires it, then go ahead.