I'm working on a project using Zend Framework, which I initially chose since I had a bit more experience in it. At this point in time, I'm thinking of moving to Django, though, as our current team will be more productive in it.
I'm trying to figure out the best way to (potentially) go about this, as we evaluate it. A lot of our code is still fairly fluid, and being re-written fairly often. The way I had considered is that as something ends up being re-done, redo it in Django, and change my PHP model to simply be a call to the Django underbelly and translation to PHP. Over time, we should have all of the models, at least, in Django.
Are there better ways? Particularly, is there any way to easily manage having two codebases at once?
There is no generic answer to cross-language migration projects.
If you can wrap your php code and hide it behind web services, you will be on a good path because you will be able to migrate those web services later without changing the API.
Make a list of the main components of your architecture and try to see which ones could be hidden behind such a web service API.
I would recommend that if your web app is db driven, move your business logic to your db and have your data mappers call db stored procedures. I'm developing using ZF myself, which is a very strong tool, but the immense 'abstracticity' it offers can deviate you from your goals... Then you can mess as much as you like with your controllers and views...
Related
I've recently started work at a new company, and was initially assigned to help the web development team.
To my horror, their template application they use to set up every single one of the projects they do, is completely procedural.
I am very eager to swap it over to OOP, but before I do that I need to actually understand how to create a project.
The initial work is there - there's an index.php that swallows all calls made to the site/web application.
What I need is a tutorial on how to set up proper routing so that I can look at a URL and go "call this function in this controller" instead of including a bunch of PHP files to get the job done.
Could someone please point me in the right direction?
I was in the same situation and this course helps me a lot to learn more about MVC and Routing in PHP. As #Armin said you can use Slim Framework or phroute .In the other hand, you can use Laravel framework to take care not only routing but also all the other challenges as a PHP developer you might have in the future
It sounds like they don't use any well known framework. They probably also don't want to use one. I think the best solution in this case would be some routing library. You could use the Slim Framework. You will understand everything you need to understand in about 30 minutes. It's very easy to setup and easy to extend.
You should not try to write your own routing library, it'll become quickly a quite complex thing. You will just reinvent the wheel and loose time.
I also would recommend the Slim Framework. I've spent way too much time trying to roll my own framework with routing but the maintenance and updating on my own framework got it the way of actual projects.
Slim is extremely easy to understand and offers a lot of flexibility to mold your own type of application. Between the routing, middleware, containers, and using the Eloquent DB ORM it has plenty to offer.
As others mentioned before, don't reinvent the wheel. There are plenty of tools out there you can lean on that allows you to focus on the actual project.
I think that Create your own PHP Framework from Symfony documentation is the thing you are looking for. You shouldn't be worried about the title, it's not only about creating frameworks. It shows you how to start using Symfony components in plain PHP application and eventually create your own framework.
But creating framework part is not the most important one. Understanding how to use object-oriented components in your code is the key part.
Of course, one of the components is routing. It's use is described in first chapters: Introduction, The HttpFoundation Component, The Front Controller, The Routing Component, Templating (don't skip this one!). But I recommend continuing to the end, it's easy to read and very interesting article. Even if you don't want to use Symfony (or it's components) this article will help you understand how to use any modern PHP components.
Here's the thing. I love Ruby and I've been using it for the past couple of years. I love everything about the language and the community.
But I have this soon-to-be-large WordPress site, where I have to implement a lot of additional functinality. The problem is, I really hate customizing WordPress beyond simple theme design.
Examples of things I need to do:
add some additional information to profiles, like karma/points/reputation system
offer users to create their own page after they're allowed to do it
pulling data from some external API and displaying it on the user's profile
I got really used to the whole agile BDD workflow, where I go from Cucumber features to RSpec to implementing the stuff, and the whole WordPress architecture looks to me like ok I'm just gonna have to pray this works.
I'm not sure if it's even wise to try to write some part of the app in Ruby and try to make it work together with WordPress, or if I should just take WordPress as the only thing I've got and make the most of it's strenghts and weaknesses.
The main issue for me is that everything I'm going to write in PHP will take about 5 times as long than if I do it in Ruby, and it will probably also be more secure and robust, since I don't have as much experience with complex PHP stuff. I mean I've done a lot of PHP in the past, but I always felt like the whole thing is going to fall apart at one point.
I know there is probably no definite answer on how to approach this, but any suggestions are welcome.
We've integrated a Rails app into a TYPO3 installation. It worked out pretty well. The key point is to use Rails' support for adapting models to tables of a legacy app. An important point is to handle authentication which we handle by passing the TYPO3 session key to the Rails app in a hidden way (using PHP as the web-client and passing appropriate headers) and looking it up in the session table (respecting the session timeouts). The Rails app itself is mapped into a sub directory using passenger. Performance is very good, it's even amazing compared to our previous implementation trying to use Extbase.
So, in conclusion: If you do it right and the interfaces between the two apps are well planned such an approach can offer great benefits and the best of two worlds. If not done right or you don't understand some implications of Wordpress (like security) you will create a big mess prone to security breaches.
BTW: We reached feature parity with the Extbase (MVC framework in TYPO3) solution after 4 days of using Rails. The Extbase solution took 6 weeeks and caused a lot of headache and trouble. So your time factor may be even better than 5:1.
Why not learn how to to Behavior Driven Development in PHP for WordPress? In fact, this is one of the great opportunities for developers in 2017. We now how full blown BDD frameworks in WP-Codeception, so that you can even automate Gherkin feature files, just like in Cucumber. Check out WordPress-BDD.com for some usefull info.
I have a simple site to develop and would like to learn PHP as I go. I want the site to be secure, scalable, and easy to maintain. Should I learn a framework and PHP simultaneously? If I build off of a framework there will be lots of unfamiliar code in play. Would you say this increases security risks?
There's nothing about using a framework that will impede you learning PHP, and using an established framework will reduce the security risk, as you'll be dealing with well tested code for handling common tasks.
At the core of most of the PHP frameworks in play these days is this simple three step workflow
The URL is requested and routed through a central bootstrap index.php file
The URL name is used to derive a classname and a method name (and action method). This is your main entry point and where you start writing PHP to handle the request
At the end of this method, control is handed over to a view template, which has access to certain values you set in step two.
Pick a framework, learn how it does the above, and then write any kind of PHP you want in the action method and the view template.
Yes, there will be a lot of other PHP framework code in play, but you never have to look at it.
Yes, the framework will have a multitude of features and/or a "preferred" way for handling things, but you only need to use those you instantly understand.
When you start noticing patterns of ugly, boring, or insecure code, take a look at the framework features again. More often than not after "doing it wrong" you'll get insights as to why the framework code did something in a particular way and you'll be happy to hand off the responsibility (I'd say ActiveRecord style models vs. SQL code is a big one here)
As you start using the objet oriented systems the framework provides you'll start to get interested in how they're doing certain things, and then you can start poking at the core framework code.
Absolutely. Frameworks will do all the boilerplate code for you, providing you a higher level of abstraction. It will probably be easier for you to code without dealing with some of PHP's idiosyncrasies.
Any half decent framework will also address security issues, so if you are new to the language, chances are your app written on the framework will be safer than the one you write from scratch.
I wouldn't recommend starting with a framework to beginning developers. If you've got a lot of experience with other OOP languages, there shouldn't be a problem. But you should at least know the basics (syntax e.g.) before even thinking about using frameworks.
I would say it depends on your prior experience. It's not so much PHP itself, but the web server environment it lives in that can be distracting. If you're already familiar with the HTTP request lifecycle and have written web applications in a similar stateless fashion as you do with PHP, you shouldn't have a big problem jumping right into using a framework.
If you come from a "stateful" background or no background at all though, the abstractions a framework offers can become a problem. You should at least know how to handle sessions, cookies, headers, $_POST and the like in plain PHP before having the details abstracted away from you by a framework. Also see this previous answer of mine.
I think minimising the amount of custom code you are writing is probably a good thing if you are not confident in your ability to create secure systems (particularly for things like authentication). As a result, I think using a web framework in this way would be to your advantage. It will also allow you to familiarise yourself with the core of the langauge without worrying about peripheral concerns.
I have seen a few people (with a big previous OOP knowledge) to learn PHP and symfony simultaneously without difficulties.
In fact, moving from PHP from an object oriented language is just learn a few conceptual things and the syntax and API of PHP itself.
In my opinion, there's nothing wrong with learning a framework at the same time as you are learning a language. There are already a fair amount of situations where this is the case by necessity. For example, most people learning Objective-C learn the Cocoa frameworks at the same time, most C# programmers will learn .Net along with it, even the JDK should be considered a framework which you learn along with the Java language. And for what it's worth, I learned the Symfony framework with very little PHP experience beforehand.
I would advice you to start with PHP turorial on w3schools.com. It is short and clear. You can learn all the necessary basics in one-two hours. In order to understand any framework you will need that. Then study the first and the second chapter from CakePHP cookbook and create your first CakePHP applications using their tutorials. On the rest I agree with Alan Storm.
Getting started with a framework in PHP, also depends on the fact whether you have some prior programming experience and if yes, what kind of.
If you have muddled in some other programming languages like java, c, learning a php framework simultaneously while creating your website might not be too difficult.
Almost all of the PHP frameworks you will encounter use the MVC design pattern - if you understand the basics of MVC, if you have implemented or have gist of design patterns in other programming languages, then it will be quite easy starting with PHP frameworks.
Also your choice of PHP framework will be the deciding factor. If you employ PHP frameworks like Codeigniter, Yii, maybe even CakePHP which have comparatively smaller learning curves, you will find your path wellpaved for you in PHP. Although if choose some framework like Symfony, Zend - you might get frustrated in taking too much time in doing simple things, in turn blowing up your project.
As for the part about security risk, all of the frameworks I mentioned above and some others I have not mentioned, have spent enough time on the stage to have squashed the security risks.
Hope this helps in deciding.
Although I'm a fan of frameworks, I agree with some of the other comments above. Starting with a framework can be pretty confusing, especially if you're not experienced in the theory of Model View Controller (MVC) object oriented programming (OOP).
Truth be told, I've seen a lot more unfinished framework projects in my day than apps built without a framework. If your application is written with some clunky PHP and the application takes off, then you can hire the necessary resources to move to a framework and get it developed to withstand a lot of usage and utilize resources effectively.
My advice would be to master PHP first, then move to frameworks. My last note on this, many frameworks have flaws as well - so depending on your application needs, applying the wrong framework could drive it into the ground.
Just my 2 cents as a guy that has released a couple of enterprise apps successfully - without using a PHP framework.
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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am a long time PHP user when it comes to web applications and am mostlz comfortable with it. However, I have a one semi-large project whose maintenance / extensibility has reached its end of a life cycle. I was weighing on different PHP frameworks (there were no when the project originated), since it is the way to go for this project, and I came to conclusion the ebst option would be to do it with Zend Framework.
Symfony seemed to complicated (I don't like setting up database model as that
CakePHP seemed murky
Igniter I liked at first, but then it seemed to me it is more like Zend with less features and no Zend behind it
Zend I like the system of that I can use only what I like and not being tied into a specific directory structure, and of course there is Zend behind it. Performance is what potentially bothers me
Now, after this little rationale behind choosing Zend, there are several things I see as a deal breaker when choosing a framework.
I haven't used ORM in the past because I am more than comfortable writing SQL directly, so I still need to be convinced to use ORM
Not too much abstraction going on from the guts
Flexible directory structure
As long as this project is going to be written anew, I just as might write it in Python/Django, since I am quite familiar with Python, but not with Django. So, I would like to know if there is someone that worked with both Zend Framework and Django frameworks and if can outline a few key point differences?
I must also say that this project is made as a standard site/admin dual project. That is, it is basically two sites in one. One is for frontend and users, other is for data administration in the backend. I must and will build backend on my own, some scaffolding methods would be cool, but full automatic scaffolding is as good as nothing in this case.
I am still quite not sure how one approaches building basically two applications within a directory structure of, what is supposed to be, one application. Do you just make two separate applications and rely on URL scheme from there on to separate them? www.example.com and all of the /* being one application and www.example.com/admin/* being a second application.
Sorry for the long question(s), but as you can see - everything is pretty much related to one problem - I need to start a project anew, it has already established database+data which I can remodel, but would like to keep that kind of work at minimum.
Ok, thank you everybody - looks like I'll try and implement this stuff with Zend, gives me most flexibility out of the package (I did tests with both), and we'll see how it goes.
Well Django is more fullstack framework than Zend. It's more similar to symfony than Zend.
Django can reverse engineer your database into ORM classes. and has a cli tool that help you do stuff ( admin and model generators, project skeleton generation etc.)
Zend is more of a component framework. it has its own MVC and ORM implementation but you need to write that stuff alone. Its approach is to use only stuff that you need without imposing some directory structure.
In your case Django will have some advantages because of its great admin generator module, and Django itself is pretty fast (faster than most PHP frameworks).
I'm personally using symfony with Zend framework for some stuff I need (Mail, OpenID, Lucene search), but have played a bit with Django and I like it.
Zend doesn't include a real ORM. It provides some helper classes but you are mostly on your own in modelling your database and writing your own SQL queries. So you would have full freedom there. As Deresh says, Zend is modularized so you can pick and choose the parts you want.
Personally I use Zend together with DB_DataObjects from PEAR as by ORM. It can auto-generate your skeleton code. It is a very simple solution for handling simple queries but I can always write custom SQL where necessary.
Regarding separation of the two admin and frontend I would suggest putting them on different domains, e.g.: admin.yoursite.com (backend) and www.yoursite.com (frontend). You can probably work it with having them both on the same URL but it is not really a use-case that is supported by Django or Zend.
I'm not so experienced with Django, but from what I've read about it, it doesn't seem to be what you're looking for (too much "abstraction from the guts").
Zend framework does not provide you with an ORM. It provides you with some tools that might aid in maintainability of your code (for example its much easier to do $user->save() on a Zend_Db_Table_Row object then to manually type in the equivalent SQL string).
If you're more comfortable doing SQL, that's totally cool and Zend digs that...just beware that there might run into some more maintenance issues down the rode. I would suggest going with a "named query" approach where you store you queries in an external resource and load them "on demand".
Zend has a very flexible directory structure...the recommended one only facilitates in making things a little easier.
You can easily pull of your admin section urls using modules and routing....its a very common use case in Zend.
Bottom line is, Zend is a "presentation framework" mostly. That's what it excels at. It gives you a clean way of organizing the presentation (the screens) that are shown to your users and aids in maintenance.
It doesn't do much for you from a data perspective. This is up to you, and is probably 90% of the work that needs to be done to become "maintainable".
The goal is that your business logic stuff and data access stuff should function within any "framework", and even without a web server! Otherwise you'll just move you unmaintainable mess from whatever you have to Zend.
Also, I wouldn't concern myself with performance...mosy things can fixed with a good caching strategy.
I can't compare between Zend and Django, but I can tell you it's entirely possible to have the Django "admin" application run on a different domain (virtual named server), and you don't need to duplicate any code. You just build your Django app as normal but put the admin app and url in a different virtual server that shares a common database server/cluster.
The Django admin app does have limitations, but it's very powerful for something that comes almost free.
Finally, when I first started Django I had a lot of disdain for ORM's in general but I accept them now as a useful tool in the toolbox.