I am trying to upgrade the Doctrine library in my Zend application from version 2.0.6 to 2.3. I assumed this would just involve copying the over the newer library files over the existing library - provided there are no major changes which would require me to change my application code.
However, I downloaded a zip from their GitHub page and found that the directories in the 2.3 differ greatly to the Doctrine version I currently have installed (consists of Common, DBAL, ORM and Symfony folders whereas 2.3 is completely different). I can't find anything on the difference in these folders, maybe I'm just really slow.
In my existing set up, I am not using any third party libraries to integrate Doctrine, most of it is done through autoloading in Bootstrap.php.
After several unsuccessful attempts to upgrade the Doctrine library, I decided to follow this tutorial based on the assumption that it will handle the unfamiliar directory structure of the Doctrine I downloaded. However further down the page this tutorial also refers to the Doctrine library as having the four folders that I have in my existing set up, which doesn't match the newer version of Doctrine.
Would sincerely appreciate it if someone could point me in the right direction or tell me where I am going wrong.
ps I am using Zend 1.11
I see three ways:
Use composer.
You can use Doctrine as Git Submodule. You'll get only Doctrine\ORM. Other libraries you get through its Submodules.
Download all the libraries separately: Doctrine\ORM, Doctrine\Common, Doctrine\DBAL, Symfony\Component\Console, Symfony\Component\Yaml
Related
The question:
Is a Symfony 3.4 project created with the Flex installer really Symfony 3.4? Or more a "Symfony 4 project with 3.4 core files?
The complete story:
I am working on migrating an existing Symfony 2.8 project to Symfony 3.4. At first I created a new Symfony 3.4 project using the Symfony installer:
symfony new MyProject 3.4
The file and folder structure is a bit different to Symfony 2.8 but overall everything is quite similar. It was not too difficult to migrate the config, files, etc. from the existing 2.8 project.
However, after some more research I thought it might be a good idea to start the new 3.4 project using the recommended Flex installer instead. This would give me the new folder structure which is also used in Symfony 4, which might make a future migration to this version easier.
composer create-project symfony/skeleton:3.4.* MyProject
Of course the directory structure is different in this project. But not only the folders are different but almost everything. The way the complete config is organized, how the routes are defined and managed, how bundles are organized (none at all), how parameters are defined and used, etc.
There is almost nothing left that looks like Symfony 3.4. This seems to be a Symfony 4 setup where only the files in vendor/symfony/... are from version 3.4
Migrating the 2.8 project to this setup would be way more complex.
Of course I know that a lot has changed in Symfony 4 while Symfony 3.4 is still quite similar to Symfony 2.8. But how is it possible that two Symfony 3.4 installations are so dramatically different?
I understood that Flex is a new workflow to manage projects but shouldn't be the end result - a new Symfony 3.4 project - be more or less the same no matter which workflow / install was used to create it?
Flex is more powerful when setting up and managing different project. However I want to setup the project once and run it for several years. Is there any advantage (in the near future) in proceeding with the Flex approach?
To answer your first question: Yes, a Symfony 3.4 project created using Flex is indeed a 3.4 project. "bin/console --version" will verify this.
As far as the directory structure goes, Symfony tries to strike a balance between maintaining backwards compatibility but at the same time keep moving forward and refining their design. For information on why things were done, it is useful to keep an eye in the Symfony blog and perhaps visit the slack channel. Especially the posts when Flex was introduced as well as the new directory structure.
One goal for Symfony is to make it as easy as possible to migrate from a long term support version to a newer version. Hence 2.8 is pretty much identical to 3.0 except that a bunch of depreciated functionality was removed. If you were following things at the time you would have noticed that there was quite a big jump between 2.7 and 2.8.
Same for 3.4 to 4.0 being easy but a few possible bumps going from 3.0 to 3.4.
Kind of meandered a bit. Sorry.
To address your second question of the value of using Flex, like all opinion based questions the only correct answer is: it depends.
In my case the choice to use the new directory structure was easy. I have a number of apps and use Symfony on a daily basis. Keeping up with the latest and greatest makes sense for me. Spending the time to port apps (some of them dating back to 2.3) to 4.0 makes my overall maintenance burden easier. The time spent experimenting how to port helped me understand the new functionality. Once I got comfortable with the process it was really just copy/paste/rename exercise for the most part. The hardest was making sure some of the 3rd party dependencies were properly updated.
In your case, it seem like you only have one app and you just want to get it updated and then forget about it for a few years. In that case, keep the old structure and move on. At some point you might need to move to the new structure but waiting a few years won't hurt anything. And hey, I suspect 5.0 will introduce more changes.
The choice is yours.
Symfony Flex is the new way to install and manage Symfony applications. Flex is not a new Symfony version, but a tool that replaces and improves the Symfony Installer and the Symfony Standard Edition.
Symfony Flex automates the most common tasks of Symfony applications, like installing and removing bundles and other Composer dependencies. Symfony Flex works for Symfony 3.3 and higher. Starting from Symfony 4.0, Flex should be used by default, but it is still optional.
Source : https://symfony.com/doc/3.4/setup/flex.html
I'm new to Symfony and I'm looking at integrating a few bundles into my application, but all the bundles I find are for Symfony 2. How different are 2/3 and what sort of issues might I find myself in when I integrate them?
for example, i am looking at using this one: http://knpbundles.com/sonata-project/SonataAdminBundle
but it's only valid for Symfony 2 and I won't want to spend an age trying to integrate it and coming across incompatibility issues.
I will try to provide an answer although the question is very poor because it's much too broad.
Of course there is no general rule which Symfony based bundle will work in which Symfony version unless it's clearly stated in the available official documentation of the bundle.
A couple of indications:
Check the CHANGELOG, README etc files of your bundles. E.g. in the CHANGELOG of SonataAdminBundle you will find a lot of changes and bug fixes regarding Symfony > 3.0 - so this is a strong indication that Symfony > 3.0 is supported.
Check the composer.json of the bundle, if there's any. It might be the case that Symfony is required and you can find a semver version. E.g. for the Sonata Admin bundle there a lots of Symfony components required in composer.json. All of them state something like: "symfony/class-loader": "^2.3 || ^3.0" which means that it requires at least Symfony 2.3 or 3.0 - again a strong indication it'll work with Symfony > 3.0.
But in the end: dependency management is an all-timer issue and you'll have to check.
Most of Symfony 2.8+ bundles work out of the box with Symfony 3. Symfony 3 is not so different from the previous version.
You can easily check if a Bundle is not compatible with Symfony3 enabling it on version 2 and then looking for deprecations using the profiler.
[...] you can easily use a bundle from sf2 to sf3, but in deal with functionality of this bundle perhaps migration don't run correctly without upgrade of this bundle. The modification in bundle for run correctly in sf3 is not very important. But yes the migration is easy but not automatic. Warning at this point and read about which bundle for knowing is this bundle work with technical layer of sf3 and if little change code done for running into sf3.
The previous quote is taken from this SO answer about the same question
this is not a code question about laravel 5.*, it's more like to know if you guys develop your applications using packages ("package driven development" ? Not sure if this is the right definition).
What I mean is: Instead of building an application and create controllers in app/Http/Controllers/, you wrap everything in a package and then 'require' that package using composer (like a wordpress plugin).
I'm trying to think in a way to isolate the core Laravel from my specific application and save time later when it's time to upgrade when a new Laravel version is available.
In my case I'm having some issues moving from version 5.2 to 5.3 because I have some customization in the registration and login process - It might be because I'm not using the right approach to write the code (patterns), so I'd like to hear from more experienced Laravel developers.
Thanks!
The great thing about Laravel, there's almost always a package for what you want to do. You can either create your packages as packages on composer, or you can install a module package and create them as modules.
For my projects I tend to use caffeinated/modules. I've tried a few and IMO it's the easiest to use.
First of all, I'm a complete newbie to Composer. I've been trying it out since it's a sounds awesome and mainly because Zend Framework 2 uses it.
Zend Framework 2 is actually also the reason for this thread.
It get the basics of Composer. But with my current server setup I have a request, which I can't seem to figure out if possible.
Let me explain.
I have multiple Zend Framework 2 projects:
/home/morten/sites/Project-1/
/home/morten/sites/Project-2/
/home/morten/sites/Project-3/
All of these projects should be running ZF2. When running composer in each project - each of them get their own separate download of the ZF2 Library files. Which is a bit redundant with my setup.
I have a complete and up-to-date download of ZF2 Library located at:
/var/www/shared/Zend/
And my php.ini has that path added to PHP's include_path, so the whole ZF2 library is available for all the three projects.
IS IT POSSIBLE to make Composer use in it's setup. Because if I try to change stuff and try things out in the composer files, then it just re-downloads Zend because it's a required component for other modules.
Can this be done? And if yes, how can I do it?
Hope I have explained myself good enough for you guys to understand what I'm trying to do and want :)
Thanks a lot in advance!
Regards,
Morten
You might be able to have one composer.json file stored in /var/www/shared/Zend, where you would put your dependencies and use Composer do manage them. Then all projects could include the same autoloader.
However, I wouldn't recommend that approach:
Your project's dependencies (composer.json) should be stored with your project. If you want to install your project somewhere else (for instance if you want to move one project to another server), you are missing the composer.json to install the required dependencies.
It will not be possible to update the dependencies of one project, without updating the dependencies of all other projects. If you want to introduce a new feature in Project 1, which requires a new version of a certain dependency, all other projects will get this new version as well - which might introduce backward compatibility breaks if an older feature that Project 2 relies on, is no longer supported. Since you can only have one version of each dependency, it is not possible for two projects to have different versions of the same dependency.
This approach might be useful if all projects will have the exact same functionality and code, but in that case you should probably merge them into one project.
In all other cases, I would suggest to use Composer the way it's supposed to be used: give all projects their own composer.json file and let Composer download the dependencies per project, in each project's vendor directory. The downside is that it'll cost you a little more disk space, but you'll get a lot of flexibility for it in return.
This may look like a trivial question, but it isn't.
Being new to composer, I find myself wondering about how to pick a decent package for a common feature on its main repo packagist.
Say I am using Laravel 4 for a recent project and would like to add mongodb support for document storages and indexing. A simple search for mongodb on packagist will yield 8 pages of results, searching for mongodb laravel yield 24 pages.
But here comes my question: most packages have their target framework, should I pick the ones that are less popular but designed for Laravel, or should I go with the popular package in hope of future maintenance?
My assumption is that: composer, along with PHP-FIG standards, are attempting to reduce repeat development of common features across frameworks. So eventually there maybe only a handful of popular package left active for a certain common tasks.
But for now, how to choose the right package on packagist for framework X? Should we just search on github instead?
(I should note that Laravel already use a handful of Symfony/doctrine packages in core, but there are no guarantee that doctrine/mongodb will also work in Laravel without modification right?)
When I'm searching on Packagist, I try to avoid packages that depend on frameworks that are not Laravel or sometimes Symphony. Of course, no framework dependencies is okay.
When L4 was still in alpha, I wanted to play around with image manipulation. After some investigation, I chose sybio/image-workshop. At the time, there were no packages that interfaced with Laravel perfectly. After created a service provider and facade, all was good.
On packagist.org, try the search terms "mongodb AND laravel" without quotes. This narrows the search to one page, in this case.
Chris Fidao (#fideloper) tweeted on May 2nd about the following MongoDB package for Laravel. It looks interesting as it uses Eloquent.
https://github.com/jenssegers/Laravel-MongoDB
For package specific for laravel framework, please check packalyst. Packalyst is a directory of Packages for Laravel projects, It pulls package names from Packagist that have a "laravel" tag (composer package that have 'laravel' in the keyword array in composer.json).