I'm stuck on a PHP 4 server, and I would like to start moving an old legacy project to modern Design Patterns, including Dependency Injection. Are there any dependency injection frameworks that will work with PHP 4?
Most dependency injection frameworks use reflection to determine dependencies. Since PHP4 doesn't have typehints, you can't really do this. Experiments have been made with using config files - Some times embedded in comments in the code (Often called annotations). While this works, I find it a bit clunky. In my opinion, you're better off using PHP's dynamic nature to your advantage, than to try and apply statically typed solutions to it. You can get a long way with hand-crafted factories. See for example this post on how.
i found this (drip), but it looks like it hasn't been updated in a few years.
I don't think a dependency injection framework will really work on PHP because of the way object-oriented programs are structured in it. First of all, it's not like C# or Java wherein the binaries are already there and you just have to find a way to instantiate this object and inject it into another. PHP has to load the class files and interpret them before it can use them. So if you have deep inheritance hierarchies with PHP I don't think that's a good idea.
Given that PHP is a scripting language, it's best to leverage it as that -- a scripting language. Which means, I would just make use of simple factory or builder methods to do something similar to dependency injection. I wouldn't burden it with a DI framework that will only add to the stuff the PHP runtime has to process for every web request (unless you do opcode caching, but there will still be overhead that's not incurred by web platforms for Java and .NET). If I have to change the objects that will be injected into objects or how they are created, it would be a simple task to just edit the script that contains the factory/builder methods. No need to recompile there anyway. So I have flexibility and I have a lightweight architecture that's suitable for the PHP way of doing things.
Related
I'm deciding on a web framework for an upcoming project, and I'd appreciate any advice. We've decided to use jQuery for the JavaScript, and are heavily leaning toward Python or PHP (more Python) for our server-side logic. I'm especially interested in web2py because of its jQuery integration.
About our project
Our project is to develop a security console for a complex
cybersecurity system operating within an organization's internal
network.
This console will be largely server-driven, as messages come in from the network and must be pushed by the server to the user.
The user will also be able to initiate security actions, the implementation for which will likely be in C++.
The interface we've planned will be relatively rich, and I want to leverage jQuery's power as much as possible.
We have some control over the browser environment we'll be running in (e.g., we don't have to worry about clients with JavaScript disabled).
Our site is likely to have only a few, long-lived client connections.
We are looking for software components with permissive licenses, though we're using some copyleft components (I see that web2py is LGPL while Django is BSD, so +1 to Django)
We have about a month to create a functional demo of our system, of which this interface is a small (but visible) part.
About us
We are two developers with about 5 years of programming experience, but little web development experience. I have several years of Python experience and a summers' worth of experience messing around with PHP. My coworker has some Python experience and has never touched PHP.
I used Django once back in 2008, and was frustrated by the file and code structure, which I found highly unintuitive. Perhaps this structure is inherent to the MVC model (I've had similar experiences with Django and CakePHP since), and I just need to bite the bullet and memorize it.
My Question
Given the information above, what are the relative advantages of the various Python/PHP web frameworks for our project? As mentioned above, I'm especially interested in web2py because of its jQuery integration, though Django's dominance is (once again) hard to ignore.
Thank you very much for your time!
Before deciding on a framework, you should first decide if you want to commit to a language you are unfamiliar with.
You said you've both got minimal PHP experience, so you have to weigh up the advantages here; Will the pros for going PHP (if any) out weigh the amount of time the developers will need to spend to retrain?
(Although depending on your background experience, PHP should be very easy to pick up.)
If you frame it like that, PHP would have to have a pretty convincing offering to give you. From what I'm seeing, specifically Django vs web2py, they both seem very close in functionality - which is good, but doesn't provide the "you must use x!" scenario you may be after.
However, If you will be bringing more people in later and feel finding people to work with web2py will be difficult, it may tip it to PHP. You said your self, Django's popularity (and BSD license) is hard to ignore, and it should make it easier to find people for later expansion.
If it were me, in your shoes, I would go with web2py. Assuming the development team will continue to be Python focused for the foreseeable future.
Python vs PHP: Python
With python, you can always write wrappers for C code so you won't have to mess with starting other processes and passing args to them. That might be useful for your security functions.
Web2py will allow you to easily write a webservice for this too, to more easily integrate the C portions with the web-site infrastructure.
If you already prefer python, I would go with that. If you need to bring on web-developers later that are trained in PHP, teach them Python. It won't take long, and I'm sure they'll appreciate it in the long run. Plus, moving from a PHP MVC framework to web2py or even django would make things easier. I've used CodeIgniter for PHP and find that web2py was so much simpler and easy to understand.
Also as for the directory structure, django is not actually true MVC -- it's MTV (model, template, view).
I find web2py's organization a little more straight-forward. But yes, either way it can seem strange at first. I would say YES, you should bite the bullet and use MVC.
In web2py, the "view" is html markup with the ability to write raw python code. The controller extracts data from the model (database), attaches any needed files (css/js etc) and the model of course simply defines the structure of the data and allows you to access it in an OO way.
Lastly, I wouldn't tip my hat in favor of web2py just because of jQuery integration. It does use it, and a some of the built-in framework stuff (like response.flash/session.flash, the LOAD function that loads a page or data from another controller) rely on jQuery, but using it in another framework only means you have to write an include statement (e.g. ).
But, the way it allows/forces you to focus on development is what takes the cake for me.
I've been using Django as part of my work for a couple years now and truly enjoy it when I can make it work. Unfortunately, and maybe it's just me, but I end up spending hours working on configuration every time I start a new server, or try to make it work in a development IDE.
It's relatively simple to start a new project and start coding. But there are all sorts of little catches that keep things from working if you deviate from the norm. Things like if you want your django project to serve from a subdirectory like example.com/django. The information is out there to make it work. But it's hard to find.
I can't tell you if web2py has those same problems or not. I only just learned about it from your question. It does look slick and simple though. I can tell you that after the hassles of getting the applications to serve properly from whatever server configuration I'm using, django is way more fun to program with than plain php. PHP frameworks may differ.
From my understanding the project not usual web application, you must need event driven program, web server in python.
Django won't help you here.You should look into Flask, Flask has inbuilt console too.http://werkzeug.pocoo.org/, you might need to use twisted, gevent,Flask jquery.
I would recommend asking about web2py on its mailing list -- you'll get lots of help and advice there. Regarding the LGPL license, note that it only applies to the framework, not your application -- you can license your application however you like, including closed source/commercial.
It sounds like you'll need some server push functionality, but if you'll really only need a few long-lived connections at a time, you might not need to bother with solutions like Twisted or gevent. If necessary, though, web2py does include this (requires Tornado, and works using WebSockets, though can be adapted to use other methods).
In Java or Ruby, there are many talks about test/TDD/BDD. and there are many tests in Java/Ruby projects.
But I notice that, there are less tests in PHP project, and It seems like PHPer does not like to write tests, I just want to know the reason. thanks
I've used several applications or libraries, in a variety of languages, that did not include unit tests. This is not something isolated to the PHP community.
In fact, PHP has several testing frameworks available. Developers may either choose not to use them for whatever reason, or may be unaware of them. After all, a lot of PHP developers are self-taught with no formal training in computer sciences.
Honestly, most PHP developers I know that do use testing frameworks and other lifecycle tools tend to have been in the field for a long time, or come from another background like Java.
IMO there are multiple contributing factors:
It's a pretty new concept for PHPers. I don't use it myself. Most applications are written without contractual API design, hence code preceedes tests (in practice).
The test frameworks (PHPUnit and SimpleTest) are not natural.
PHP runs in a different environment than Ruby/Java. Moreover application parts are split into include scripts, which have different semantics from packages; sometimes locations variate.
PHP isn't as object-oriented to the core as other languages. Most code is procedural / mixed or hybrid.
I would go so far and ask about the merits of Unit-Testing for PHPs runtime environment. Selenium might be a better choice. But personally I'm looking for a simpler approach: simple (non-unit) test framework, similar to .phpt, should evaluate output/headers/errors/results
A little while ago I read a great article which described a number of reasons against using any of the RAD frameworks available for PHP. Basically, it argued that a good framework should get you off the ground quickly, and then should get out of your way. But none of the PHP frameworks did that. It pointed out that Django was good at doing just that (but that's obviously not a PHP framework).
For the life of me, I can't find the article now.
So I'm curious. Does anyone have any solid arguments as to why applications should not be built on top of a RAD framework? And I'm not necessarily talking about generic applications (frameworks by definition try to solve a generic problem. The quesiton is does that translate well to specific problems).
And when I say built on top of, I mean from the ground up based on the framework. I don't mean referencing the framework as a series of libraries. I mean basing the entire architecture of the application off of the framework (which then ties you into the framework).
I'm also not really talking about rapid prototyping where the code will likely be re-written anyway. I'm more looking at long-term applications that have a specific business requirement to meet, and must be supported and maintained (and modified) for a relatively long period of time.
We always hear about why we should be using a framework. There are reasons galore:
Not reinventing the wheel (although I hate this reason)
Faster development time (since architecture is skipped)
Easier to bring new developers in
Common problems are already solved
etc...
But I'm looking for the antithesis...
Any thoughts?
It is implied that frameworks being written by some unknown heroes who is smarter than you by default.
But as a matter if fact it's often not true.
It has bugs, it can be messy and unnecessary overcomplicated.
Thus, having your own helper library is often more handy than using such a monster, knowing roughly 10% of it's features.
A few ideas:
The type application you are creating does not have a commercial or free framework available (custom hardware-based apps come to mind) (this is the obvious answer)
The system has extensibility requirements that are made more difficult by using a RAD framework (i.e. framework values convention over configuration, where you really need the configuration)
The project scope is small enough that it doesn't make sense to invest the learning curve into using a RAD framework (if you already are past the learning curve, this may or may not apply)
The tools/approach/back-end/platform requirements provided by the framework will introduce unnecessary complexity (YAGNI, using a framework without a business need for its features may increase support costs as you have to support the whole thing, including unused features)
My fear has always been, what happens when a framework stops being maintained/updated (for whatever reason)? Your project is locked into whatever PHP/MySQL versions the framework supported.
I'm doing a little framework research lately.
http://matrix.include-once.org/framework/
And to some extend I have to agree. The majority of frameworks don't significantly simplify development. Particularily the "MVC" frameworks are about abstraction more than utility. There are however always features which do help for everyday tasks. ActiveRecord/ORM come to mind as reducing tedious manual work. Form helpers might do, but I haven't seen a seriously helpful one yet.
Generally I believe, the more functional library code a framework provides, the higher the productivity. But in the case of Zend Framework, it's randomly dwarfed by complexity. However, check some of the smaller frameworks out. Avoid the overly abstract. Look for scaffolding tools, not libraries.
One of the main advantage to not use a framework is that you have more flexibility in what you can code. For project with a smaller scale, it is often better to have that flexibility.
Some frameworks need shell access to deploy.
Scalability, I've read that sharding is an issue
If performance is a priority, frameworks tend to slow down execution speeds
Not all developers familiar with MVC pattern so maintainability if developers rotating in/out of project could be a challenge.
I'm working on a codebase with a lot of non-OO function libraries, and personally, I don't love php's java-inspired OO model.
Unfortunately, I'm trying to solve the problem of the overhead that you get with a lot of included libraries, and see a lot of recommendation for autoloading. Which only works with classes.
Is there any way to reduce the overhead of included libraries of functions in a manner like autoload? By making use of php 5.3 namespaces, say?
I certainly don't want to move all of these (often diverse) libraries of functions to classes to get performance gain (the bugs wouldn't make it worth it), so is there a simpler way to optimize function library includes in simple ways?
Is inclusion of function libraries in php just fast enough that I shouldn't worry about it?
No, the autoloader only gets called when instantiating unloaded classes. You can't use it for functions.
Back in the scripted ASP and ColdFusion days, I used to work on projects that would build code generators for ASP or Coldfusion, typically in C++, in order to be more object oriented in application design and not have developers writing scripted code, which often was called "spaghetti code" for it's size and complexity.
Since I've been coding asp.net since 2000, I haven't really had to deal with the issue at all, since the platform is not scripted.
I may be working on PHP projects in the future, and I was wondering if any code generators for PHP exist, or if any good references for building these generators exist.
It would be for the Linux platform, not targeted to Win2008 Servers running PHP.
Why not just build a proper app in PHP instead of going through the hassle? Recent PHP is fully object-oriented and lets you do some pretty decent stuff. There are even frameworks that help you do this kind of stuff.
I'm rather sceptical on the merits of code generation in the context of a dynamic language, such as PHP. You can generally use other kinds of abstraction to get the same results. Unlike a statically typed, compiled language, it is rather easy to use dynamic hooks such as __get and __set and reflection, to make generic abstract objects.
It's better that you learned good development practices in PHP than use code-generators. PHP might be a scripting language but it is quite potent, has a nice OO model, plenty of good frameworks and other open-source packages.
It's up to the developer to create well designed and factored code base, regardless of whether it's compiled at run-time or not.