we have an old large application that was not built on any framework. However now we want to transfer it to a php framework. Its a new area for us so we are not sure what it takes to transfer the older application to a framework like Zend?
You have three options:
Rewrite the application from scratch using the framework.
As another poster suggested, gradually start introducing ZF components into your application, the DB and View layers in particular would be good candidates. MVC would likely be the trickiest bit if your old app is large.
Create your new ZF application, add a 'legacy' module to it and put all of your old application code into this module. Route all requests to this module and get it to setup and load up whichever part of your old application needs to serve the request. You then gradually start adding ZF modules to replace parts of your old application (adjusting your routes accordingly), until eventually there's nothing left in 'legacy' and you can remove it.
Exactly which of these is the best option for you depends completely on your application. In my experience, option 1 will take the least dev time, option 2 the most and option 3 somewhere in the middle. With options 2 and 3 you have a transitional period where you're gradually introducing the new stuff, whereas with option 1, one day you just migrate all the data across and flick the switch.
The 'use at will' architecture of ZF is what makes option 2 possible, with other PHP frameworks you probably only have options 1 and 3.
Good luck!
Go sit and write it from scratch using framework. That's all.
Totally dependent on the makeup of the old framework.
Try to find components in Zend/CodeIgniter/CakePHP that closest resemble the functionality of the components in the old framework, then choose that library.
As far as I know, Zend Framework has an advantage as it can be used as a library.
You may work iteratively, adding for instance only the Zend_Db layer, then progressively adding other layers (Auth, MVC, etc.).
The point is to be able to test and validate simple functionnalities, rather then change all at once, and fight numerous bugs.
Related
So I'm about to start a big Property Management System for the cloud. This Hotel system already exists in VB.net technologies, and now we are porting the whole system to web.
We are trying to decide between ASP.net or PHP, we are thinking on PHP because ASP.net would cost too much on licensing and servers. So there is Laravel, Symphony, CodeIgniter, Zend, etc..
The thing is, this project is suppose to live for years to come. But we feel like getting constraint ed by using a PHP framework, because every time the framework gets updated then we need to update our whole system. For example.. now Laravel got updated from version 4 to 5. And the whole folder structure changed. I can't imagine having our big system needing to be updated and keep up to every Laravel version update. How do you keep up with this ?
Also, what would happened if Laravel disappears, its the trendy fashion now. But we see PHP frameworks come and go.
Would it be wiser not to use any php framework and building everything from scratch to have more control over it ?
You should first note that using a framework is primarily meant to solve two issues;
Force coding into a certain 'format'. Collaboratively working on code can generate 'hacked' solutions, or unmaintainable code. A framework can be the force which helps keep these things in check.
A framework comes with a certain core-code which handles for example database abstraction, routing, etc. which can save you a lot of time to develop yourself.
An extra thing to mention; when implementing new features, there is the possibility someone has built it before and maybe even better than you would have anticipated.
Keeping up with the framework should not be too hard, as long as you abide by the coding guidelines of the framework. With the bigger frameworks, new releases have (or after sometime generate) tutorials on how to port your previous version into the new version format.
Choosing which framework to use, is a question which is opinion-based and not suited to discuss here, but keep in mind that you choose your framework according to your needs. Also check how big the community is and how much 3rd party plugins/code exists (the more, the longer the framework will last).
Good luck!
You could see a framework as a base to start from. Remember that you get all the code! Look at the code. Do you like it? Does it fit your requirements? Using a framework gives you a huge advantage over making everything yourself from scratch.
But do you need to update? Would you update your own code constantly? Perhaps it's not always needed. Sure, if there is a security issue you should do something about it, but seeing every update to a framework as essential is just plain nonsense.
I build projects aimed at specific versions of frameworks and libraries. I try to build in flexibility so I can swap out frameworks and libraries, and versions, but I often find that I stick with what's working.
Some people might not like this, and argue you should always be on the latest version, but I find that completely impractical.
We have pretty big application which has about 8 modules (big modules) written using Zend framework 1 and it has been developed for more than 3 years by couple of developers. Also it has a high traffic everyday. We use Amozon s3, Sphinx, Memcache, and some other third party services as well.
Is it a good idea to migrate it to Zend framework 2 ? Because as we went through the doc briefly, it seems Zend framework 2 has been re-written completely. Therefore we think we won't be able to migrate the application easily rather than re-writing the application according to ZF 2.
Valuable ideas would be highly appreciated.
You are correct that ZF2 is a completely different animal. So different, in fact, that there's no one-size-fits-all migration plan/strategy.
However, I recently did a similar migration. It's a fairly complex line-of-business application originally written over approximately 18 months, with a bunch of varied functionality. The main drivers for the decision were the improvements in the module and event systems.
In our case, it turned into a major point release for the product, which ended up including a bunch of UI changes along with all the plumbing.
Assuming you liked ZF1, the good news is that ZF2 is much better framework (as a framework). The ModuleManager, EventManager, Di, and ServiceManager components (and the general MVC-related stuff) are really great, once you grok them. The bad news is that they're a complete departure from ZF1. So you're at the very least signing up to completely overhaul your dispatch and routing, you'll be saying goodbye to Zend_Registry (ServiceManager/ServiceLocator are a huge improvement).
The other bit of good news is that you can almost certainly keep all the old ZF1-type components around for as long as you need them. So if you're relying on Zend_Cache, Zend_Log, Zend_Mail, etc, a little bit of fiddling with autoloader configs should make that possible.
What I'm suggesting is that if you do take the plunge, consider just migrating to ZF2-as-a-framework first, and worry about ZF2-as-a-component-library later.
If you've stuck with the fat-model/skinny-controller paradigm, it's probably feasible to just replace the Controllers, Front-Controller, Zend_Application stuff in a fairly straight-forward way. Once you get that into production, you can then work on removing dependencies on ZF1 components as time permits. In my case, there wasn't much of that, as things were pretty well factored and wrapped (so, for example, moving from Zend_Cache to Zend\Cache was trivial)
Finally, you should know up-front that View-layer stuff (mostly the helper-related stuff) is different too. If you have a bunch of complicated view-related stuff (partials, custom view-helpers, etc) all over the place, you need to anticipate either rewriting them, or finding a way to use the old Zend_View stuff in ZF2 so you can migrate piecemeal. I didn't really deal with this because our interfaces were fairly simple and we took it as an opportunity to overhaul the UI.
Just my $0.02, but I hope it helps.
There is no quick and easy way to migrate because ZF2 is very different from ZF1.
Related: Step by step migration from Zend Framework 1 to 2
The "Framework" question has been asked a bunch of times here but having read everything I can find, I can't find the answer to this question.
I'm creating everything from games, to CMS's, social applications, etc. I've used Zend and CodeUgnighter briefly, but when I deliver it, its going to have a bunch of unnecessary folders and it requires anyone who wants to modify my program to know the framework, and they've got a mountain to move if they want to update it to the latest version of the framework.
It just seems to me that frameworks were designed mostly for super large projects where its being designed for one customer, not a released program. It seems like all the big packaged php products out there make their own frameworks (vbulletin, etc).
its going to have a bunch of unnecessary folders
These uncessary folders are stored in one folder and are needed for the framework to work, is that the 10, 20, 200 Mb which is problem? Storage is cheap nowadays, why cares?
it requires anyone who wants to modify
my program to know the framework
You got it! It is an advantage, not an inconvenient. If it doesn't, the guy which will read your code will need to understand your habits, your convention, and they probably are not so common.
If you are able to write consistent code, following any conventions, why not.
But it can also gives your customer a real plus value since he knows that anyone could take back your work if you have to leave for any reasons.
they've got a mountain to move if they want to update it to the latest version of the framework.
In any case upgrading a framework, an application to a new version is most of the time a moutain since in a production environment, you need to test, and test again, to be sure your application is stable.
Most of the framework give releases notes which should let you know about backward compatibility.
It just seems to me that frameworks
were designed mostly for super large
projects.
Zend or Code Igniter fit well for medium sized project, with time you developed framework extensions and you'll be able to save time and bugs on smaller project.
It seems like all the big packaged php
products out there make their own
frameworks (vbulletin, etc).
PHP framework are youngs, most of them are 3/4 years old (Zend, Symfony). A lot of application like Vbulletin are older.
There a lot application based on common framework, but they don't target the same people.
Joomla, Drupal, Wordpress have their own framework (procedural, or object) but they target more the end-user.
However a solution like Magento, which uses Zend Framework, is designed to be extended and very customizable with extensions.
There are many light-weight PHP MVC frameworks, each with varying degrees of features and flexibility. The majority of these are going to be lacking advanced features, but will get the job done.
One that comes to mind is: http://www.kissmvc.com.
Hope that helps :)
You're right that most frameworks are tailored towards 'one size fits it all', meaning they have a lot of stuff that you won't necessarily need on every project. Which sometimes makes them a bit heavyweight. More 'modern' frameworks DO have a strong focus on modularization, but when it comes to the core there are often a lot of inter-dependencies.
One solution: Roll your own framework, dissect code from other frameworks and use parts you like/need. If you can, lean more towards using libraries that focus on specific tasks that you need. E.g. ORM for databases, you might as well use doctrine since it's area of expertise is very focused. Just as an example.
Either way, if you do it right it's a lot of work upfront trying to figure out what you even need. Start with the basics, how do your controllers work, do you need the full implementation of MVC with front controllers, action controllers, maybe page controllers for a CMS? Where can you cut corners, where not? It really depends a lot on what YOU need for your specific product (or product palette).
The other solution, like Serge mentioned, is getting a lightweight framework which really just focuses on the basics. And fill all the holes yourself, or by using 3rd party libraries where they are available.
I personally use a heavily modified version of FLOW3 (currently in alpha development) which uses a lot of cool stuff, but lacks a bit when it comes to using legacy databases (they have their own domain model implementation). Which is what I changed mostly for my version.
Is it possible to integrate Zend Framework with already existing legacy web application? The application is written horribly using so called spaghetti code (no separation between presentation and application logic, PHP, HTML and SQL are all together). It is a very large application with hundreds of pages and forms.
Does it make sense to introduce a framework now or should we just continue with the spaghetti code? It is not realistic to rewrite the whole application using a framework because it would be too difficult. Moreover, we need to add some new functionality to the application and we have a deadline. Should we use a framework for all the new parts of the website that we need to add or should we just go with the way it has been programmed by developers that worked on it before us?
This excellent post by Chris Abernethy shows how to route all requests through ZF and have the legacy scripts handled by a LegacyController. New pages and content that you create can use the standard ZF MVC. And you can slowly migrate the legacy scripts into standard ZF MVC.
I think you really could and should code the new bits of your application using a framework, and migrate the legacy bits to it whenever they bug. Refactoring is not difficult and can be done over a long period of time, and that could be a task when you feel bored.
I advise you to read this very interesting article about refactoring : http://www.joelonsoftware.com/articles/fog0000000348.html , by Joël Spolsky
yeah zf is a component framework so you can start buy creating new features using these new components or when you fix a bug to see if redoing it in zf will be faster.
I'm in a similar situation and what i started doing was creating a new site entirely and would embed these new features in certain pages within the old site (thru frames). This allowed me to code entirely in zf and replace the entire site piece by piece.
I keep on reading how great codeigniter is from a development standpoint. And I am sure that using the framework will make the development process quicker. But the question I ask myself is, will there be a difference to a individually made framework, which caters to your needs?
Is CI, despite the advertised small footprint, going to "bog" down the system because it is basically a framework on a framework (the later referring to PHP as framework of C)? Are there good ways to spread the load? Are there any large applications in the wild that have been made with CI?
Thanks
Casper.
I'm running a codeigniter site with about 11K files.
I've heavily modified the codeigniter's basic structure for my needs. For instance, I have 3 applications with 3 front controllers using the same system files. I'm using smarty as my templating engine. I have rich PHP web apps powered by jquery and prototype/Scriptaculous. I use form validation, authentication, active record, emailing, etc. etc.
My experience so far has been very positive.
Once you get a (real) templating engine like smarty plugged into Codeigniter you have all the power that you'll need for medium to large sites.
You have to think about organizing your site into large 'metagroups' as the 'controller' structure in Codeigniter expects such behavior. ('blogs', 'merchandise', 'forums', etc..)
CI is very easy to add plugins for.
The framework simplifies a lot of crap you would otherwise need to hand code. It's fast, simple and configurable.
My one big complaint with CI so far is that it's not very multi-application aware. The default layout assumes you're running 1 application. In my case, I have a global application with the global file that can be pulled into all running applications. However, this could be solved more elegantly. Additionally, you have to add a little extra fluff to switch between front controllers.
My favorite aspect of CI is easy of active record on a MySQL DB. It's dead simple to set up a DB connection and get active record queries running.
I would say that it's pretty easy to get started with. Just make sure you shop around and figure out how to plug smarty into your app. You CAN use the default 'view's of Codeigniter, but the minute you need if/else logic in your templates you're screwed.
I set up a 'templates' and a 'content' area in each app that I can fill with smarty templates and static content respectively. The rest I can pull from a DB connection.
This really is a question that only you can answer. When you speak of a "large system", you could mean something largely used (by pageviews / etc.), or something that encompasses a huge set of business rules but used only by a few people. Does the application need to be fast, or can you load balance it across multiple servers?
Your "PHP is a framework on C" comment is fairly out of whack, IMO. No, PHP isn't as fast as C. But it's a LOT better at handling web requests. PHP is used in some of the biggest sites in the world -- Facebook was originally written entirely in PHP. Yahoo uses PHP quite a bit. So PHP is fast enough for just about anybody, especially considering that the database will almost always be your bottleneck. If your PHP applications are slowing, you can use memcache / load balancers / put more application servers on your network. Pretty easy to scale the PHP end of stuff.
What I can tell you is a brief comparison with other frameworks. I've used CI in limited deployments, mostly helping out other people, but what I have seen, I've liked. It gives you a speed-in-runtime advantage over something like CakePHP, but it will increase your development time (as Cake's biggest strength is its ability to rapidly develop and deploy). Speed-wise it feels pretty comparable to Zend or Symfony, which is still about 5-7x slower than just writing the raw PHP yourself.
To sum the various frameworks (NB: my opinion below):
CakePHP is great for rapid development. Its performance is the worst of the major frameworks, although the 1.3 release (coming soon!) is supposed to get you a free (no changes in the API, they're just removing the PHP4 support) 25% speed boost. It's focused on ActiveRecord, and is super fast to get a full featured site up and running (seriously, seriously Rapid Development / Prototyping chops).
Zend is the most widely used. It has the most flexibility with its adding modules. It's super fast, although not particularly lightweight. For an enterprise project, I'd go with this one or symfony. Feels like using a buncha different libraries to me. And their naming conventions are a little onerous...
Symfony - see the Zend comments. Although symfony is supposed to be even more enterprisey.
CodeIgnitor is the new hot kid on the block. Its focused on staying out of your way while still being a "framework", i.e. a tool that will help you do your job faster. It's fast to run, but a little slower to develop.