PHPRPC and PHP frameworks
I started the process to submit PHPRPC to the major frameworks. I feel like I should submit it to all the major frameworks, so I can make sure people can use PHP-RPC regardless of their framework of choice.
Besides that, it might be a good way to gather feedback or critique from the pro’s.
PEAR
For PEAR I submitted it as a new PEAR2 package. PEAR2 is the upcoming next major version of PEAR, and will be PHP5-only. Much of my code (seemed) to follow PEAR2 coding standards, but the approval process will tell.
The most interesting (or weird) change I had to make the standards to include classes from within other classes. The old PEAR standards dictate:
require_once 'My/Other/Class.php'; ?> Which assumes PEAR and its packages are in the include_path. However, the standard for PEAR2 is:
if (!class_exists( 'My_Other_Class',true )) throw new Exception('Undefined class: My_Other_Class'); > ?> So, this means that the user of the package has to manually include all the dependencies. There is also an allfiles.php in every directory, which loads the entire package.
This allfiles.php is considered ‘for beginners’. The wiki states that its also for opcode cache friendliness, but this is false (I submitted a bug report). So as a consequence of this all that using PEAR2 packages becomes a bit more harder to use for the following target audience: «Advanced developer, but doesn’t want to trace each class’ dependency tree»
Solar Framework
I opened a ticket in Solar’s trac asking if its smarter to first write the Solar implementation, or first ask for approval for the contribution, because it would be good to know if Paul M. Jones hates the idea before I start.
Solar follows PEAR’s old coding standards. The only annoyance here is that I need to prepend underscores to every private and protected property. (An idea that stems from the PHP4 era, where there was no property visibility).
Zend Framework
I haven’t really started with Zend yet, the coding standards seem to be nearly the exact same as the ones I use myself (except for the change from Sabre_ to Zend_), but in order to submit code to Zend, or even propose a package you have to sign a contract first; which means I have to print, sign and scan their pdf. Sadly, the only type of paper we have in this house is rolling paper.
Looking for a CTO or senior developer for your next project? I’m looking for contracts or full-time gigs! Check out my resume or drop me a line! —>
Web mentions
Comments
Sam Hennessy • Aug 12, 2007 Did you think about submitting something to PRADO (http://pradosoft.com/).
It would be easy to adapt the SOAP implementation.
Arnaud • Aug 12, 2007 Just for the record the PEAR2 standards are not in place yet, they are just being discussed.
Tomek • Aug 12, 2007 I’m interested in that «opcode cache friendliness» problem — can you tell where can I find your bug submission or maybe point some other resources on that matter? thanks
Arnold Daniels • Aug 12, 2007 You’re not reading the code correctly. PEAR2 does not ask for the user to include all dependencies.
class_exists( ‘My_Other_Class’,true )
The true here is significant, it means that an autoloader will be called to load the class.
I’d love to see more implementations! However, doing 3 is already quite the chore. Lets first see how these turn out, then maybe I could look into others.
You are of course more than welcome to help out 😉
For sure.. I’m absolutely confident that the final code standards will work well for everybody.. I just want to jump on the bandwagon early.
If you want to get the most out of APC, you need to make all your includes non-conditional. When you include a file based on a function result, or using autoload the include is considered ‘conditional’, which is a bit slower.
I submitted my comment to the pear-dev mailing list, and the problem was acknowledged.
The posting + greg beavers’ response:
stefan • Aug 13, 2007 If you need any help in getting a symfony plugin for it, let me know, I can probably be of service there 🙂
Drop me an e-mail and we’ll see if we can write a nice plugin for it.
Thread
This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.
CI and PEAR or ZEND
luftikus143
Hi there, I am totally new to these coding environments. I normally just create the file hierarchy and the needed code of my web sites “by hand”. Now, as I want to move to another level of programming, I wonder how the different environments and add-ons play together; or what the differences are… Can anyone shed a light on that for me? CI versus ZEND environment? I have really no clue… Thanks for any hints, Stef PS: What does this “You are not interested in large-scale monolithic libraries like PEAR.” mean? Large-scale? Monolithic? I was in another thread asking actually how to integrate PEAR with CI? As I want (I explained that in the other thread) to move an exisiting project into a more modular, flexible, opensource like environment (using eventually PEAR libs) , this statement makes me thinking…. and not understanding what CI actually is…
bradym
From what I’ve seen, Zend is more like pieces you put together to build your own framework. The pieces can also be integrated into CodeIgniter or used as stand-alone libraries. With CodeIgniter, the framework is built for you. There’s no need to put the pieces together before you start writing your own code. One very significant difference is that Zend is PHP5 ONLY, where CI supports PHP4 and PHP5. The very best way to decide which framework is best for you is to spend some time building something with each one. Spend some time in the documentation, user forums, and build something simple to see which one fits your needs and coding style.
PS: What does this “You are not interested in large-scale monolithic libraries like PEAR.” mean? Large-scale? Monolithic?
Using PEAR can be very painful. There are so many dependencies, so many out-dated projects, abandoned projects, bad documentation, etc that many developers (myself included) won’t even consider using anything from PEAR. That said, there’s no reason you can’t use PEAR libraries with CI. It is very trivial to use pre-existing libraries with CodeIgniter. Brady
luftikus143
Using PEAR can be very painful. There are so many dependencies, so many out-dated projects, abandoned projects, bad documentation, etc that many developers (myself included) won’t even consider using anything from PEAR. That said, there’s no reason you can’t use PEAR libraries with CI. It is very trivial to use pre-existing libraries with CodeIgniter.
Thank you very much for the information. So, instead of using PEAR, what do you use? I do understand that certain functions/libs are coming with CI…. And I guess there is a database somewhere with additional libs coming from the community…. But if I am looking for, say Excel-export functions, or PDF creator libs, Webservice modules…. Do I find this with CI?
bradym
So, instead of using PEAR, what do you use? I do understand that certain functions/libs are coming with CI…. And I guess there is a database somewhere with additional libs coming from the community…. But if I am looking for, say Excel-export functions, or PDF creator libs, Webservice modules…. Do I find this with CI?
First of all, if you are currently using PEAR, there is no reason you should stop using it just because I don’t personally use or like PEAR. Not everything you need will be built into CI, and that’s kinda the point. It’s a lightweight framework that provides a great starting point, but it doesn’t try to include every possible function you may ever need. For exporting to Excel, I’ve always just used CSV files. I’ve never needed to do an export that was too complex for that. From what I’ve seen, the PEAR module for exporting to excel (in terms of using excel functions like formulas, etc) is about the only option out there. Creating a PDF? There’s several options. FPDF, domPDF, pdf functions that are built into PHP, and several others. Again, take your pick as to what you use. Like I said, take the time to read the user guide and build an application or two, there’s no better way to decide if you like CI or want to use something else. Just don’t let your decision be based completely around how many built in functions there are, as it is very easy to use outside code with CI. Brady
Mirage
You can view Zend as a lower level framework compared to CI. A framework is little more than a collection of re-usable classes that help you reduced the amount of code you need to write to implement a given [Web] Application. CI offers you a more complete workflow within the framework, such as URI routing and clear layout of controllers, models and views. That’s what makes it easy to get started with and makes you extremely productive right off the bat. ZF is growing nicely and very well supported. It’s much more comprehensive with it’s components than CI. But you need to ask yourself if you really need all of that (right now) at the expense of a longer learning curve. I’ve used both and in fact ported ZendAuth and ZendAcl to CI libraries because I love how they work. But I still choose CI over anything else because it allows me to get things don’t flexibly and most importantly: fast! HTH
Michael Ekoka
I use and love both. If you’re only getting your feet wet, I’d recommend to start with CI to get acquainted with the overall concepts. As you get more and more comfortable with architecture, have a look at what Zend has to offer. Both frameworks have their own interpretation of the MVC pattern. There are some similitudes and some differences. As a framework, CI can be classified as in between glue and full-stack. Meaning that some functionalities of the framework can be easily adapted to use external libraries, while others need a lot more tweaking. Also, not all native libraries can easily be pulled and used as stand alone components in non CI projects, because they assume knowledge and presence of other core functionalities. CI’s architecture is quite “liberal”. You need to only understand stuff like Routing, Controller, Models and View. That’s it. Concepts like bootstrap files and dispatch are all handled by the framework. It is a very good choice as a first framework. Zend on the other hand is a true glue framework with a minimalist core (front controller, request, router, dispatch, response). All parts of the framework are interchangeable/adaptable (even the core, provided you implement the key accessors to these classes). Think of it as a collection of libraries for people who want to build their own framework or feel the need to further customize the behavior of any given part. You’ll find that Zend is a lot stricter about architecture than CI (while remaining flexible). It shows in their implementation and in the documentation. Components tend to be described using specific pattern names (observer, registry, singleton, front controller, etc). It probably is safe to say that a certain familiarity with patterns is assumed. Nonetheless, a beginner can quickly grasp these concepts without paying too much attention to names. Both documentations are excellent. A beginner will prefer CI’s while a more seasoned developer will probably favor Zend’s. As a developer, you will pick up a lot of new concepts initially by going with CI, it will lay the ground work for more advanced topics later on. Its approach to solve certain recurrent problems encountered during development is quite clever and elegant and could be, for a programmer, lessons to be carried to future projects. As for Zend, it will bring you to yet another level. The architecture and the code is just that mature and convincing. Also, the fact that Zend was designed for PHP5 allows it to take advantage of some cool functionalities (the perks of evolution). You will discover a lot of things that you didn’t know php was capable of.