I have looked at a good deal of other peoples source code and other open source PHP software, but it seems to me that almost nobody actually uses PEAR.
How common is PEAR usage out in real world usage?
I was thinking that maybe the current feeling on frameworks may be affecting its popularity.
PHP programmer culture seems to have a rampant infestation of "Not Invented Here" syndrome, where everyone appears to want to reinvent the wheel themselves.
Not to say this applies to all PHP Programmers, but them doing this apparently far too normal.
Much of the time I believe its due to lack of education, and that combined with difficulty of hosting providers providing decent PHP services.
This makes getting a workable PEAR installation so much more difficult, and its worsened by PHP's design structure not being favorable to a modular design.
( This may improve with the addition of namespaces, but have yet to see ).
The vast majority of PHP code I see in the wild is still classic amateur code interpolated with HTML, and the majority of cheap hosting that PHP users inevitably sign up for doesn't give you shell access.
In my (limited) experience, every PEAR project that was potentially interesting had major points against it:
Code is targetted at the widest audience possible. There are hacks in place all over the place to deal with old/unsupported PHP versions. New useful features are ignored if they can't be emulated on older versions, meaning you end up lagging behind the core language development.
Any given project tends to grow until it solves everyone's problem with a single simple include. When your PHP interpreter has to process all of that source code on every page hit (because the authors may not have designed it to be opcode-cache-friendly), there is a measurable overhead for processing thousands of unused lines of code.
Style was always inconsistent. It never felt like I was learning generalizable APIs like in other languages.
I used to use PEAR::DB at work. We discovered that most of our scripts spent their time inside PEAR code instead of our own code. Replacing that with a very simple wrapper around pgsql_* functions significantly reduced execution time and increased runtime safety, due to the use of real prepared statements. PEAR::DB used its own (incorrect at the time) prepared-statement logic for Postgres because the native pgsql_ functions were too new to be used everywhere.
Overall, I feel like PEAR is good as a "starter library" in many cases. It is likely to be higher quality code than any individual will produce in a short amount of time. But I would certainly not use it in a popular public-facing website (at least, not without a lot of tweaking by hand... maintaining my own fork).
Im my opinion PEAR is a good project but lacks people who want to work and keep working on it, most of the packages have inconsistent coding practices (I do not mean coding style) and there are lots of TODO's in the whole thing.
I find it useful sometimes for coding stuff I didn't know existed yet, like custom country validation functions and so on, otherwise I'm better served with any available framework out there (like CodeIgnite or Zend Framework).
The Pear library is the kinda stuff that just sits there, plugging away, with very little glory. If you are looking for something that it can do, and there's nothing more specifically targeted in the framework that you are using - go use it.
I've been working on a dating site for the last two years - and there's at least 65 pear-sourced files I've used, and are still live there today. Some, like the pager or html_Quickform will be overtaken by new code as it's updated, but for others there's just no need.
PEAR is not common, nor popular.
I tried to use PEAR so many times, but it lacks the umpphh to commit.
I prefer Zend Framework which takes the approach of 'loose' type, use only what you want.
PEAR is not common, nor popular — but it is good, and I'd recommend it to anyone.
(I do agree with Tom in that it doesn't feel like a single, unified, API; but then, this is PHP … one wouldn't like to see it getting above its station as an interpreted hack language now would one?!)
Related
We have a requirement to allow users to customise the CSS for a PHP app. In general, only that user will be able to view the custom CSS, but there are cases when other users in their group could also view the CSS, hence the need to ensure that its sanitized.
I am aware that HTMLPurifier and CSSTidy can be used for PHP, but CSSTidy is extremely outdated, and apparently can't handle everything that we need to throw at it.
I havent found any other PHP libs that can do this.
One alternative that I am exploring is taking a ruby library (http://apidock.com/rails/HTML/WhiteListSanitizer/sanitize_css or https://github.com/courtenay/css_file_sanitize/blob/master/lib/css_sanitize.rb) and converting it into php.
Before I go down that route, are there any alternatives to the above? And are there any pitfalls that I should be aware of before using one of the Ruby libs?
Update:
After almost eight years later, I wanted to leave a second note
because my answer start getting downvotes.
I am not dealing with JS/CSS anymore as much as my early career years. I
did mostly focus on building backend services and tools recent years. So, my knowledge on this subject may be outdated, even if I tried to keep it sharp, which requires discipline and hard work.
Neverthless, nicer tools may exist today other than HtmlPrufier and/or TidyCSS. I am not saying those tools are bad. But community support and active maintenance is important. As a thumb of rule, I am staying away from dead or unmaintained dependencies in my applications.
If PHP is a MUST here to sanitize, I would look into Wikimedia's CSS sanitizer first if it works for me. More or less, it's doing the job. Persisting a minified version of given CSS in filesystem, updating as modified on application side also would be a secondary goal for me. A pre-generated version could make my life easier when sending to browser. Any tooling would work there, PHP may just fire a dedicated event for it. Creating sanitized version of CSS may also be a background process candidate rather than generating on demand. Maybe via available tools from other platforms beyond PHP. So there are a lot more options and possibilities out there nowadays.
Hope my explanations shed some light for people trying to achieve something similar.
Original answer was:
HTMLPurifier and CSSTidy are right tools. CSSTidy still maintaining by Cedric Morin and few other developers on Github. Also default CSS level of CSSTidy is CSS3.0 since April 2012.
You may use that.
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).
I don't find the unit testing push in the PHP market like I see/read in the ruby/rails arena.
Could one just as easily NOT unit test in ruby/rails as in php, or is ruby just too bendable and breakable that it "more" recommended to test in ruby than in php?
Meaning there are large code bases like vBulletin, and from what I can tell, they don't unit test.
I hope you understand what I am asking here, not the pros/cons of testing, or whether one should test or not, but rather, does one language need to be tested more than another? maybe its easy to write buggy code, or break during refactoring etc.
tl;dr PHP/vBulletin/Mambo started before TDD went mainstream
PHP allows the same mistakes to be made as Ruby does. In Java/C# the compiler will complain sometimes if you do something odd at compile-time, PHP/Ruby will do that only on run-time. So if you were to compare Ruby with Java, I might have replied that I see a little more necessity to write unit-tests for PHP/Ruby. Still I consider unit-testing important no matter what the language you use.
On your findings: vBulletin (v3 development started in Dec 2002) and Mambo is nearly as old as jUnit (2000). Unit-testing (according what I can find) had its rise around the year 2000. SimpleTest/PHPUnit emerged in 2003/2004. So the devs of Mambo/vBulletin didn't use TDD back then. The structure of the written code won't have made it easy to add tests later on.
Not to dishonor any PHP developers, PHP was pretty overrun by script-kiddies, pseudo-programmers, and beginners (me included). Everybody started from scratch, wrote his/her own CMS. The reference app were some snippets found around the web. I assume that a large chunk of the PHP dev community will never have heard of unit-testing or have understood what it's good for.
Ruby was hyped much later (approx. 2007) than PHP (approx. 2000) was. It comes bundled with a lot of philosophy ("Whats good/readable/beautiful code?", "How should coding be done?"). Writing tests is somewhat a part of this philosophy.
Most books on Ruby contain a section on unit-testing, explaining why it's good and necessary. Also Rails generates a set of (empty) tests for you automatically. You are encouraged to write tests all the time - it's hard not to.
I think you dont see as much automated unit and functional testing in PHP because the community has not embraced it - though that is changing. Its not that any language requires more or less testing its more about development methodologies and the tools the developers using that language are familiar with as well as cost of implementing something (in this case the tests).
With Rails unit and functional tests are easy. Theres a whole framework integrated for it... with scaffolding if i recall correctly. This greatly decreases the cost and knowledge level required to test an application in this fashion. Many times in PHP if you want to do this you have integrate PHPUnit, Lime, SimpleTest, etc.. yourself. With the rise for frameworks like Symfony, Zend, CI, and Cake the barriers in PHP are being lowered too assuming the development team uses a framework such as these.
Ruby is no more bendable, or breakable, than other languages because a programmer is free to do stupid things in Ruby just as they are in PHP, Java, or C.
Some programming environments (IDEs) do precompile-runs and check for syntax errors in the code, but if the developer has cast things wrong, or turned off warnings or error notices, they'll still be in a position to shoot their foot off. It's not the language's fault they did stupid things. It was a lack of discipline, or experience or forethought on the developer's part, not the language, that led to the code that caused the problem.
When I wrote in C I enabled all errors and set warnings to their highest severity. My code compiled without errors and I had a high degree of confidence that the code was good. At the same time I checked all my memory-allocations to make sure I got a value back, checked my return codes from system calls, etc., because I cared that my code ran right and was clean. I'd receive code from people who turned off warnings because they didn't like the stream of messages and it would fail, and reviewing the code showed it was full of ignored return codes and didn't check memory allocations. Similar to what Forest Gump said, "Sloppy is as sloppy does."
I've worked closely with some very talented PHP developers, and their code was every bit as clean as mine or a good developer in any language. I've also worked with very talented and experienced developers who wrote garbage, again, because they didn't care to write code that was maintainable and safe.
So, while some might want to point a finger and say a particular language isn't as good as another because the language fails too often, it comes down to the person with their hands on the keyboard. Leave the language out of it.
Testing, whether it's unit or integration, or whatever, is just one more step in the programming process that helps ensure good quality. Testing seems to require 2x the code as you'd have if you didn't test, but the automated component of testing is an incredible safety-net that can't be appreciated until you've had it catch errors after code changes, that would have broken an app badly.
About six months ago I started working regularly with some code written by a non-programmer. He's very talented at what he does but he needed a senior developer to team-program with him and show him why things are done a certain way. One of the first things I did with him was introduce him to the testing safety-net. He had some test code for incidental things but nothing that tested the actual behavior of the program. Once he saw it in action he was a believer, and now writes his tests as he goes. It's an awesome thing to see. :-)
I don't think there is such a thing that one language requires more testing then the other ( they all require testing , writen tests or human tests or customer tests , all software get's tested at some point , tough it should get tested before hitting the market ).
It's not so much that ruby requires it so much as it supports it so much better, and is part of the general philosophy and best practices that surround ruby, whereas php quickly got overrun by a lot of, well, amateurs.
Yesterday Facebook launched HipHop, a sourcecode-converter from php to c++. The set of php functions and constructions is more limited than in standard php.
Are the current popular php frameworks (ZF, CakePHP, symfony) compatible with HipHop? If not, which parts of these frameworks are not usable?
If I'm not mistaken, HipHop has not been released yet -- even the wiki page linked from the Facebook annoucement yesterday is not up yet.
So, it's going to be a bit hard to answer, right now.
I suppose it'll all depend on :
The features used by the Frameworks -- like already said here and there, stuff like eval is not supported by HipHop
The PHP extensions used by the Frameworks : only a couple of those have been ported by Facebook to HipHop.
Depending on the Frameworks and your specific needs, maybe/probably some subsets of the Frameworks you are using will be supported, even if not every available components... I suppose time will tell which ;-)
With at least ZF and Symfony being used for Enterprise level applications, chances are pretty good they will run with HipHop. If not now, then sooner or later. However, the question is not so much if they can run with these frameworks, but how your supporting IT architecture looks like.
HipHop is for scaling large multiserver high traffic sites like Facebook. In your regular web application, you will likely get no advantage out of it. Just continue to use memcache and APC.
See these related articles:
http://www.readwriteweb.com/archives/rasmus-lerdorf-php-hiphop-facebook.php
http://ilia.ws/archives/213-My-Thoughts-on-HipHop.html
http://terrychay.com/article/hiphop-for-faster-php.shtml
http://www.brandonsavage.net/hiphop-for-php-who-benefits-who-doesnt/
While I'm sure most of us are curious about what HipHop is going to be, I know it will not be a replacement for PHP - it's very much a niche product: unless you're running a large server farm then the performance benefits vs the maintenance costs just wouldn't justify it.
Perhaps it might be an interesting alternative to use encoded PHP for some people - but again this introduces even greater maintenance overheads. The only low-volume scenario where a compiled PHP would seem to make a lot of sense is for embedded devices (where the software exists to support the hardware and not vice versa) and for very high security installations (where its not a good idea to have a interpreter available).
It's far to early to be able to say what PHP software will work with it. However even once thats established, I'd want to see a solid commitment from any supplier that they were going to explicitly support HipHop in the future before I switched.
C.
I won't repeat what has already been said, I'll just add that as soon as HipHop is released you can count on the opensource community to submit patches for your favorite framework for increased compatibility with HipHop.
Also, one good way to test whether your favorite framework is compatible or not would be to launch the test suite using HPHPi (you then know where to concentrate your patching effort ;).
Searching for 'eval' gives a lot of false positives, as you get hits for the word "evaluate" in comments, or escapeValue if the search isn't case sensitive, etc.
If you search for 'eval(' in ZF 1.11 you'll find in once in Zend/Serializer/Adapter/PhpCode.php on line 59, in a method that unserializes stored PHP code. The method isn't a part of the MVC architecture, db component, and actually isn't used anywhere else in the framework (Zend_Serializer_Adapter_PhpCode isn't instantiated anywhere else in the code base).
So if eval breaks your ZF-Hip Hop app, don't use Zend_Serializer_Adapter_PhpCode, or eval in your consumer code.
Simple answer: I don't think it would.
Just saw this on hiphop page: https://github.com/facebook/hiphop-php/wiki/
"You keep coding in simpler PHP, then HipHop executes your source code in a semantically equivalent manner and sacrifices some rarely used features – such as eval() – in exchange for improved performance."
Did a search for 'eval' on ZF 1.9 and there are over 100 occurrences.
Why is PHP the most used programming language for a web based platform?
PHP:
is easy to learn;
has been around for ~15 years;
runs fairly efficiently;
is cheap to host; and
actually scales really well (some of the largest sites on the internet use it).
PHP is basically the ultimate grass-roots success story.
PHP is:
Built for the web, that is not an extension of an existing language like Perl.
Free of any default framework; this allows it to be fairly lightweight and powerful, a good example of the KISS (Keep It Simple, Stupid) principle.
Because software that values simplicity over everything else propagates faster.
Probably because PHP is easy to learn and it was really simple at first start. With the upcoming of OOP from PHP4 we cannot really say it's simple anymore but at least it tries to keep simple.
Plus from the start the language was really Web oriented, easy access to get/post variables.
You can also note the PHP community is really wide and Zend do a great job to make it a real concurrent of Java/Dotnet/all the others.
Perl/Python/Ruby are also good scripting language but they require some libraries to develop web application
While most CGI language extensions require you to write HTML/JS/CSS within that languages syntax, PHP is able to be used within the contents of an HTML file structure. For someone who doesn't really get the concept of CGI (like I did a while back), it's really nice and offers room to grow with libraries and a universally familiar syntax.
It's also a strategic isue to
choose PHP over Java/Ruby/...
Because you will find PHP
programmers every time, but it is
really difficult to get (cheap)
Java/Ruby/... programmers.
PHP has become the third most be
liked programming language. * **
Its Open Source.
Its old and therefore very stable.
Its the best documented language in the internet.
It has the most string functions (necessary for web/HTML programming).
It has a very huge community, you will find the answer for every PHP question in the internet (or ask stackoverflow).
Its the only language which was designed for the internet.
PHP is fairly easy to install and fairly easy to understand. For that matter, you don't even have to install it. Fifteen dollars a month (or less) will get you a PHP webhost at hundreds of hosting companies.
There are no shortage of "Build a website in 5 minutes with PHP" books. Therefore, it's often the first choice to new web developers or people who want to get something done quickly.
PHP certainly has it warts, but done properly, it can be a good solution as well. Despite its warts, it runs an awful lot of successful websites.
I think it is easy to learn, it is faster, it has lots of forums, it has lots of example codes, it has ...
A lot of emerging php framework like Symfony, Zend, and Cake make rapid development, good mvc design easy. A lot of extremely popular blogging software/cms's are built using php eg. Drupal, Wordpress, and Joomla!.