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.
I'm wondering if there are any abstraction frameworks for one of the PHP gui libraries. We have PHP-GTK, a PHP/Tk interface, and seemingly also PHP-QT. (Not tried any.)
I know that writing against the raw Gtk+ interface in Python is just bearable, and it therefore seems not very enticing for PHP. I assume it's the same for Qt, and Tk is pretty low-level too. So I'm looking for something that provides a nicer object structure atop any of the three. Primarily TreeViews are always a chore and php-gtk callbacks are weird in PHP, so I'd like a simplification for that. If it eases adding the GUI/View atop my business logic without much control code, that might already help.
And so since GUI apps are an area where MVC or MVP would actually make sense, I'd like to know if any library for that exists.
Still open for answers.
(There will probably be a second bounty round. It's an uncommon topic, so needs more research.)
[Not an answer. Just wanted to remove this from the question, as it's only related, not a solution.]
There is the PHP interface preprocessor. However it is very simple and low-level. It provides an output interface for Gtk, as well as ncurses, but also PDF or XHTML serialization. Which is interesting, as it's close to real MVC constructs in allowing to exchange the View for different backends without adapting the Controller even. But then it only provides the basic widgets, and not a whole lot of simplifications. Thus I only consider it related to my original question. So, a side note.
Have you tried WinBinder? Not exactly MVC related, but a very nice extension to create gui based programs in PHP.
Now there are a few options that work on newer versions of php. Some of these do not provide you with MVC out of the box, but you can use them to make GUI application in php.
There is the very easy to use php-gui. It does not require any special php extentions, you can just install it with composer like any other php library or framework you depend on. It is geared toward simple, standard user interfaces.
If you need to make something very custom and graphically advanced, and are willing to use an API that was designed to make games in C (or if you want to make a game in php), you could use OpenGL via SDL via FFI via ffi-sdl. It currently (as of 6/1/2020) requires php 7.4 or greater as it uses the recently added ffi feature of php. Even though this relies on the ffi extension, php-ffi is still easy to add to your project. It is still sort of extensionless (like php-gui) because there are no extensions tailor made just for this for it to work. Unlike some other extensions, there is not much chance ffi will not be maintained since it is a feature of php itself. Most people will just need to add ff-sdl to their project using composer, and possibly enable ffi in their php.ini.
I just learned you could also use PeachPie. It allows you to compile and run php code for/on .NET, so you would gain access to .NET GUI libraries, including MVC ones.
I really doubt that you'll find anything like that ready to use OotB. PHP GUI programming has totally failed few years ago.
What you can do however, is use some kind of bridge to interface decent MVC from another language. Which PHP you have following choices:
PHP/Java bridge http://php-java-bridge.sourceforge.net/pjb/
Boost.PHP (C++) https://github.com/moriyoshi/boost.php/wiki
SWIG (C, C++ via wrappers) http://www.swig.org/
http://phpketchup.isgreat.org/ PHPKetchup is a new project in planning stage. There isn't any code available for now (also seems intended commercial, not open source). It was announced as framework atop PHP-GTK. There is a conception document which explicitly lists the goal as designing a MVC framework.
However it seems like they take inspiration from CodeIgniter and mostly the common PHP framework structure. The focus seems not to lie on integrating PHP-GTK with the application logic, but mostly to provide a database interface as model and a thin Gtk interface for the View.
MVC Architecture:
We will design and implement Model-View-Controller (MVC) architecture for the PHP-GTK framework. SQLite will be used for Model. PHP-GTK functions and Glade files will be integrated in View after removal of HTML, CSS and Javascript. Controller will be modified accordingly to work with the newly created View.
So it might just be MVC in name and organization, but one of the diagrams mentions "PHP-GTK functions addition" and there are further hints of object-structured Gtk helpers.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
First, let me apologize for Yet Another Framework Question. But I think this is different enough from the usual "What framework should I choose?" to warrant it.
Here's my situation: For the past year I've been using a custom framework. It's been used on everything from small CMS's to larger sites and even a mid sized social network. It's worked great but I now see its limitations. So, I've decided to switch to a 3rd party framework. The simpler frameworks (CI, Kohana, Cake) seem too inflexible from what I've heard - so this led me towards ZF. But, I've also heard that ZF may be too flexible and thus hard to work with. What further complicates this is that I'm looking for a one-size-fits-all solution; I need a setup that works on small projects to very large projects. I am the main developer, but I need my partner to eventually be able to learn the system and help with the less complicated programming tasks.
I've researched Doctrine and I love it. So I'm leaning towards Symfony (with Doctrine) as the main framework with ZF to fill in the gaps. Plus, I need the ability to add my own pieces to this platform parallel to any 3rd party libraries. I hope this will provide me with a solid, extensible platform, as we really can't afford to be switching out frameworks every few projects.
I'm looking for advice from others who have been in the same situation as I am in now. Any advice would be greatly appreciated.
Edit: I've posted my solution below in hopes of helping other people in the same situation
After some research I've decided to go with Symfony. Here are my reasons:
Less verbose than ZF
Seems very customizable due to usage of YAML files (yet I never feel overwhelmed by them)
Autoloading of custom classes doesn't require any extra work like in ZF (albeit it's not hard to set up in ZF)
The developer toolbar is great, and they're adding some nice features to it in ver 1.3
The ability to use pieces from other frameworks (ZF, eZComponents) makes me feel confident that I won't have trouble finding what I need
Comes bundled with Doctrine and is very easy to set up (in fact Doctrine will become the default ORM in ver 1.3)
It seems like there's a much larger community for Symfony. Google "symfony tutorials" versus "zend framework tutorials" and you'll see a massive difference in the number of results
Plenty of documentation: tutorials (the Jobeet tutorial so far is very good), API references, and a more human readable description of the framework and its underlying principles
Yahoo! has used it for a few of their own projects - it's nice to see a Big Name back a framework IMHO
Edit: For the sake of hopefully helping others in the same situation, here are some things I don't like about Symfony:
Does not follow the PEAR naming scheme (ZF does)
Internal classes begin with "sf". This is contrary to the practice of capitalizing the first letter of the class name
Variables and functions are written_like_this, yet class methods are camelCased - this seems sloppy to me
These are all cosmetic issues though; things that bother me because I like to do things my way. I realize that whenever you use third party software you must be willing to make some sacrifices.
ZF is certainly a nice framework, but I feel using Symfony as the primary framework and extending it with pieces of ZF is the best choice for me and my team.
Edit
It's been 2 years since originally posting this, and since it's still getting hits I thought I'd give a quick update. I probably built about 25 - 30 projects using symfony 1.x in the last 2 years, and I'm very happy with how it performed. As a full stack MVC framework, partnered with Doctrine, it handled almost everything I threw at it. And whatever it couldn't handle, it was easy to add my own custom code. In fact, that's what I love most about symfony - how easy it is to extend. I ended up building a bunch of plugins and Doctrine behaviors that greatly reduced development time. And the admin generator tools have been a god-send. I'm still using symfony 1.4 for a few projects here and there, but have decided to mainly focus now on using Symfony2. It's a completely different beast than symfony 1, but I really appreciate its architecture. More importantly, it seems even easier to extend than symfony 1.x. I do miss some of 1.x's features, but that's the sacrafice you have to make when switching frameworks.
I like using ZF because of strong conventions. You can be sure, that everything will be as you expect it. Class names, function names, variable names, directory structure, ... all of it. It really speeds up the development if you stick to it. If you adapt it it's more like looking into your own code, when checking the ZF internals ;)
Let's be honest. ZF is not fast. Not as fast as Nette, CodeIgniter, etc. But the difference is that there is a class for everything. And if there is not, there is a class you can extend or interface you can implement.
All the other frameworks try to gain on the "wow" effect (blog in 30secs, twitter in 2 hours, etc). But when develioping a real life application, you realize, that it's the use at will, flexible and extensive architecture, that you need.
Zend Framework: Huge, Flexible, Modular.
I'd use only if am building a enterprise big ultra system.
But, I'm using Yii Framework and I like it.
Because: Very Fast, Simple, Widgets (easy to reuse component, this is very nice).
Yii it's easer to use, because is not a enterprise framework, and have all Basic features you really need in most cases.
*
EDIT: Now that I nearly understand HOW
to improve the ZendFramework using
your own code (as asked here Adding
3rd Party lib to Zend and here
Using 3rd Party lib within Zend),
I switched back to ZendFramework. I
currently design my application and
each day which I work and test
anything with ZendFramework it gets
more and more familiar and it easily
quickens my developement. My advise:
Use ZendFramework.
*
I have currently the same problem:
My story:
I was using CakePHP until I wanted to expand my project's size.
CakePHP was not as flexible as I wanted it to be.
So i tried to use ZendFramework.
The very first time I read the 'QuickStart' guide, i was a little bit afraid of having that much files for a simple guestbook application.
After a time of 'playing' with the ZendFramework I decided to use ZF as a 3rd party lib in my own custom framework.
The problem is, IF you use Zend's MVC components you might be forced to use 30% of the whole framework, because the MVC components are one of the biggest part of the ZF.
I mean if I use that much of a framework WHY shouldn't you use the rest, too?
After that, I decided to write my COMPLETE custom framework without using ZendFramework as 3rd party lib.
Now I am sitting in front of mountains of papers, full of sketches about code design.
I will keep you up to date about my further decisions.
I honestly think it really depends on your style. There's no end all be all answer to this question.
ZF relies heavily on classic and proven design principles. It's also very extensible, but requires more "configuration" than "convention". I personally do not trust 3rd party code by nature, so I'm a fan of more verbosity, for the sake of being more familiar with the technology I'm working with. But that's just me.
I've also used CakePHP successfully and two other frameworks proprietary to a company I worked for with great success. They're all trying to do similar things, just pick what feels best for you.
I've personally used CakePHP successfully for both large and small projects, however it is often difficult to make it budge the way you want. My reasons for using Cake continue to reside in the fact that the community support is top notch, the security updates are often, and they do not force meta-packages (such as unit testing) upon you (although this is bundled, you can just bin it if you're not interested in using the built in package).
Altogether, it's made a nice system for me over the past few months, however I have heard time and time again that Symphony is fantastic, so you may perhaps be on the money with your first thoughts. With NetBeans support for Symphony in the pipeline, I may too find the need to switch before long.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What is the best method of understanding how and why a framework was written the way it was?
Develop a feature for it, or fix a bug. If you use the framework for developing a real-world solution, you can make a list of shortcomings to address or features to add that would make your task easier.
Fixing a bug will really help you understand the code, because most of the time you are given a piece of example code that recreates it, which you can then trace down into the bowels of hell to find where things go wrong.
All it takes is persistence, really.
Take a very simple component and analyze the code. For example, look at some of the components of the Zend Framework (something utterly simple like Zend_Version or, to step up a bit but still keep it simple, Zend_Debug). Pick them apart and see what makes them tick. Then, try to write your own simple component.
After making many websites 'from scratch' I found myself reusing the same scripts over and over, and I found some things tremendously tedious because I never bothered to abstract them away before for re-usability. So, if you have any experience making websites, you should have a pretty good feel for what your framework should include. If not, I would probably start by thinking of an MVC file structure, get your framework to first work with views, then controllers, then models. Then make sure each of those is easily extendable because no matter how hard you try, there will always be things missing... and then just start slapping on utilities as you need them (form helpers, model helpers, etc.). In other words, come up with a project for which you would like to use the framework, and build the framework and website concurrently.
I know the world needs another like it needs a hole in the head, but writing your own framework is a great way of learning a language. I wrote a fairly complete one in PHP in under a fortnight and learned a hell of a lot about PHP and Web development in the process.
The only reason I haven't released it is because I was finally not happy with the way it managed session state, but that was a good learning experience too!
I think the way to begin framework design is to write down about 5 basic aims for it. For mine, these were:
aimed at producing simple Web apps with a dozen or so forms
aimed at people with a good knowledge of SQL
no procedural code PHP or otherwise (except for that in SQL SPs)
no HTML/javascript/CSS programming needed
application described in XML
work on a vanilla PHP/Apache stack
no state maintenance on server
That was enough to get me started.
The other suggestion I can make is to try to build an app using the framewark at the same time as you build the framework itself. This will quickly reveal problems and suggest ideas for new directions abd features.
You are on the right track. Just remember that Rome wasn't built in one day. Every house is built over a longer period, brick by brick.
By using a framework, you will discover some of it'S shortcommings and be able to find some functionality that is missing or needs improvement.
Start there, develop the improvement and submit it to the frameworks community for peer review. Even if they decide not to include your work into the framework, you will receive very valuable feedback on your work.
Don't stop there, use what you learned in your first attempt for a second one (and a third, fourth, fifth...) That way you will learn to understand what others expect from the framework (which might differ very much from your own expectation), and slowly understand the inner workings of hte framework itself.
Conclusion: Be patient and persevere. Understanding will follow. (Sounds esoteric, I know. But it may work!)
There are a number of things that most frameworks include, although the definition is fuzzy.
Provide a basic bootstrapper (manage settings, setup environment, check for compatability issues between PHP versions, etc.)
URL Routing - How to define rules for which URLs point to which pages.
Manage plug-ins, libraries, modules, etc.
Database ORM - Manipulate objects instead of writing SQL queries (simplified)
Templating - Usually involves creating a mini-language for template logic (loops, conditionals) to avoid having PHP code in the template itself.
Beyond this, most frameworks also include a slew of libraries from simple e-mailing to advanced web service API's.
I would recommend two frameworks to look at:
Codeigniter
I recommend this because it's a "batteries included" framework that works out of the box. It also has a great community, lots of 3rd party libraries. CI has a bit of trickery to get the framework to play nice with both PHP4 and PHP5, which is also good to know (because, for some reason, a lot of people still use PHP5). You should also take a look at KohanaPHP, which is a branch of CodeIgniter that has been rewritten as a strict PHP5 framework.
Zend Framework
Zend is a module-based framework. Instead of dropping everything in a directory and churning out pages, you pick the parts you need and glue them together yourself. Since Zend is made by the folks behind the engine behind PHP (confused yet?) it uses "the latest and greatest" of PHP5 - everything is Objected-Oriented and it uses type hinting. Very clean code, if a bit verbose.
I think the essential stuff is the bootstrapper (the "glue" for the framework), as well as how each framework implements a system to support user-made libraries and plug-ins. The rest you can find as stand-alone applications elsewhere.
you should really try to understand, on a high level, the life cycle of a request. here's a good example a what happens from request to response in the Zend Framework, http://framework.zend.com/manual/en/zend.controller.basics.html