Why are there two different, yet extremely similar classes in Symfony to represent a browser Cookie?
Symfony\Component\HttpFoundation\Cookie and Symfony\Component\BrowserKit\Cookie
First you need to understand what Symfony components are.
Symfony Components implement common features needed to develop websites. They are the foundation of the Symfony full-stack framework, but they can also be used standalone even if you don't use the framework as they don't have any mandatory dependencies.
They don't have any external dependencies, meaning that any dependency will be bundled with the component.
HttpFoundation\Cookie is a Cookie class used by the HttpFoundation component. And BrowserKit\Cookie is a class used by the BrowserKit component. They are small bundled dependencies of each of the components. You should use the component, not an individual class inside it.
The purpose of these two components are
BrowserKit Simulates the behavior of a web browser.
HttpFoundation Defines an object-oriented layer for the HTTP specification.
Decide which components to use according to your scenario.
Related
I wonder if there is an interface that diverse ORM should implement for Symfony or not.
The question came up when I was building a service that accepts an ORM (Doctrine right now), and wanted to declare type.
I guess different ORM have different behaviour and classes... in those cases, how can build entities that do not depend on specific ORM in case one wants to switch later?
Generally, Symfony is agnostic in regard to your choice of ORM.
The standard edition comes bundled with Doctrine and also contains some “bridge” code to ease the integration.
However, you can use any ORM you’d like to. For example, Propel is known to work well with Symfony, too. The Propel team also maintains an integration bundle.
There is no “interface” in the sense of a formal description an ORM has to comply with. There is no such thing as interface SymfonyOrmInterface {}.
Think about it, how and why should Symfony demand this? Symfony is a HTTP framework built on a set of loosely coupled components. Most of these components don’t even know what an ORM is or if one is currently available in the application.
You will usually install your ORM through composer, and it will be available in your business code (assuming that it supports autoloading with PSR-0/-4).
Of course, for a proper integration of an ORM into Symfony, there are some conventions and features, such as:
CLI commands, e.g. for schema updates,
Managing configuration values through the global config.yml and parameters.yml files,
Providing services and dependencies through Dependency Injection.
These are implemented in integration bundles, usually provided by the respective ORM vendor.
For your business code, this means that you can’t just replace one ORM with another one. There are significant differences accross ORMs in regard to storage abstraction, caching, querying, hydration, etc. Replacing an ORM will always require you to adapt your business logic to some exent, and not only in a Symfony project.
Problem:
I’m unsure how to set up multi client application for Symfony so that we would not violate Symfony's best practices and work against the framework.
I would like to have one main Core namespace which would contain all the base model classes. Right next to the core I would like to set up client specific namespaces which would be used, based on client regional setting. For example LocalUS for US market, LocalUK, for UK market etc.
The Local* namespaces should take first priority for including twig templates, and as a fallback use core common shared views (as I understand, this is solvable via twig namespaces). Same goes for controllers and models - these are probably solvable via extending the Core namespaced classes? Is this all solvable via routing and providing paths for these Local* controllers?
I was looking up on github to see if there are any project that have similar setup but I couldn’t find anything.
A little background:
We have an older legacy PHP Application which was built in-house from ground up using plain PHP. As the application has grown over time, it has become hard to maintain good code quality and standards. It’s also very time consuming to teach new developers our application logic, since the application basically follows no standard design patterns and just does it’s own thing. A lot of the underlying code which handles routes, controllers etc seems to work like “magic” that nobody really dares to touch.
It is because of that we would like to migrate our application to Symfony3 framework. I’ve read some articles about the overall process of migrating legacy applications to symfony, and managed to do it with silex pretty well. Silex, however is a bit too lightweight, I found that the assetic service provider had a lot of functionality missing (twig namespacing etc), and decided it would be best if we could move to a full stack symfony framework instead.
Look into Symfony bundles - they do exactly what you need. You create a "base" bundle, than extend it with other bundles. That's how FOSUserBundle works - it provides everything you need, than you extend it and overwrite it.
I'm trying to add Symfony 2.0 ACL to my frameworkless PHP application. Because of the lack of documentation on how to use Security component as standalone I've got totally confused and I've got stucked with questions: What class to include first? Which object to instance? Is it possible to be used without models and controllers?
Any suggestion on how to start or any good link?
Thanks
The SecurityServiceProvider for Silex might be a good place to start, as it integrates all of the essential component services in a single file. Although large, you'll probably find it much easier to digest than Symfony2's SecurityBundle.
In the interest of maintaining your sanity, you should consider using a service container to organize all of these objects. In the aforementioned provider class, the Silex Application class is a Pimple instance, so you should be able to port it stand-alone Pimple with modest effort. I saw this because integrating a Pimple service container into your application should be less invasive than adopting the Silex framework.
Once you have the essential security component classes working, you should be able to following along with the ACL documentation and add additional services to your container as needed. At that point, the ACL-specific sections of the SecurityBundle might prove helpful, as you can focus in on the relevant bits. Keep in mind that there are multiple cookbook entries for ACL in the documentation.
What class to include first?
You will most likely need to include at least parts if not all of the security core, then which ever ACL implementation that you are wanting to use. You can look at the dependencies that are listed in the beginning of the ACL implementation and see what they extend. For instance, the ACL/DBAL has the following dependencies called in the header:
namespace Symfony\Component\Security\Acl\Dbal;
use Doctrine\DBAL\Driver\Connection;
use Doctrine\DBAL\Driver\Statement;
use Symfony\Component\Security\Acl\Model\AclInterface;
use Symfony\Component\Security\Acl\Domain\Acl;
use Symfony\Component\Security\Acl\Domain\Entry;
use Symfony\Component\Security\Acl\Domain\FieldEntry;
use Symfony\Component\Security\Acl\Domain\ObjectIdentity;
use Symfony\Component\Security\Acl\Domain\RoleSecurityIdentity;
use Symfony\Component\Security\Acl\Domain\UserSecurityIdentity;
use Symfony\Component\Security\Acl\Exception\AclNotFoundException;
use Symfony\Component\Security\Acl\Exception\NotAllAclsFoundException;
use Symfony\Component\Security\Acl\Model\AclCacheInterface;
use Symfony\Component\Security\Acl\Model\AclProviderInterface;
use Symfony\Component\Security\Acl\Model\ObjectIdentityInterface;
use Symfony\Component\Security\Acl\Model\PermissionGrantingStrategyInterface;
But you would probably need to check each of those listed for their dependencies, and load those as well.
I would back-track through the dependencies, and keep track of what needs what. Cull those classes out into a separate location so that you have only what you need, and use some error trapping to determine that you have it all.
Which object to instance?
Your ACL. If the dependencies are all determined, and loaded, then you should be able to instantiate the ACL class object.
Is it possible to be used without models and controllers?
To be honest, I am not sure that using ACL outside of S2 is possible without a WHOLE lot of work, but if you can get it instantiated with everything it needs, then you should be able to use the object without an MVC model.
Unfortunately, from what I understand of S2, it is a full stack framework, and meant to be an all or nothing kind of thing. but if I were going to try and make it work, this would be the way I would go about it.
If u want to understand how to use use symfony2 component and how to integrate that within your project then read Fabien Potencier blog 'create your own framework'
post that will definitely help u to understand core of framework from and how to bootstrap symfony2 component in your project
there is also good document for ACL on symfony website
I have an application written in symfony 1.4, and I'd like to use the Symfony2 Serializer component. Is it possible to begin with ? And what should I do to be able to do this ?
Symfony2 is composed of two main features: component and bundle. You are mixing this two concept in your question. Components are stand-alone and thus independent of each others, but can optionally make use of other components to enhance their possibilities. On the opposite, bundles usually use components to achieve their tasks. They can be dependent of each others and they all depend on the FrameworkBundle. The FrameworkBundle ties together multiple components, it's a kind of glue between components. The FrameworkBundle with other bundles like DoctrineBundle and the components form Symfony2.
Since Symfony2 components are stand-alone they can be used with any projects. There is no reason why it would not be possible to use the Serializer component within symfony 1.4.
There is not much documentation on using components of Symfony2 independently. I know they have a PEAR channel so it is simply a matter of getting the library via PEAR and add entry to the autoloader and use classes defined in the component.
I didn't see any README for the serializer component, you may need to look at the code to check how you can use it. Here some links to documentation related to the subject, not specially on serializer.
Symfony2 components page: here
Symfony2 PEAR channels: here
Serializer component github: here
Fabien Potencier's blog on what is Symfony2: here
I was wondering if anyone knew how to use some components of the Zend Framework without having to actually use the framework. For example, I would like to use their Zend_Validate components, but don't want the overhead of the framework as it's a small one-page script.
Can this be easily done, and if so, are there guides/tutorials on how to accomplish it?
Zend framework components are intentionally designed to be loosely couple from the framework itself.
The component structure of Zend
Framework is somewhat unique; each
component is designed with few
dependencies on other components. This
loosely coupled architecture allows
developers to use components
individually. We often call this a
"use-at-will" design. [from here]
Here's a tool for pulling out specific components and their dependencies to use in your application.
I've just grabbed the whole Zend package, and used pieces of it. It always seems I end up using more of it as time goes on, so I keep it up to date even if I'm not using some of the MVC stuff in one project or another. Holding on to the whole thing makes you not have to worry about the dependencies (and how they might change down the road).
Zend framework components while being loosely couple are still coupled. If you would to use Zend_Mail component for example - that would actually also require:
Zend_Mime
Zend_Exception
Zend_Validation
Zend_Validation will be loaded for the mere reason of validating email address domain.
So - best bet would be to include entire Zend library. By pulling only several components - you'll soon end up in "dependency hell" especially as API changes (though that doesn't happen too often).
Also - starting from version 2.0 you must use some auto-loader to load Zend components as all require calls will be removed from PHP classes.