Aside from the PEAR repository, which I find often has quite messy code with a lot of it using old or deprecated methods and techniques, I was wondering if there was a great place to find simple (and not so simple) PHP examples of some generic functions and good pieces that people have written.
A good example would be the PEAR spreadsheet module I used a while back. The thing worked but it was written quite messily and if I remember correctly, in PHP 4.
I'd like to find something with well written and well documented code that I can refer to and see exactly how people are doing things and why they are doing things that way.
The PHP manual's as good a place to start as any, I've particularly found some of the comments on there helpful.
There's also The PHP Resource Index, which is mostly a jumping off point to other projects' websites.
Don't forget to look at questions tagged PHP on stackoverflow.
Have a look at PHP Classes. They have a large selection of classes, all with user ratings.
There's also Zend Framework spesific ZF Snippets site
Github is another good resource, more often than not it is polished code that is updated frequently.
Getting classes from other people is all well and good but keep upgrade-ability in mind, if i'm using someone else's class and need to tweek it i always extend from it.
Related
Okay, I'm fed up with phpDocumentator. It consumes way much more memory (1.4 GB) and time (5 minutes on 2.6GHz Core 2 Duo) than I'm willing to give it. Does there exist some really compatible program to generate documentation for PHP code?
I've tried PHPDoctor, which looks nice, but it has some missing features. However it is probably closest to be replacement from all solutions I've tried so far.
I've also tried PhpDocGen, but it just bails out with some Perl errors, which I'm too lazy to study.
Doxygen also does not seem to play well with our sources.
PS: The documentation would be for phpMyAdmin, a little bit outdated documentation is here.
Update: The code contains lot of functions and not only objects, what is the biggest problem with Doxygen, because it fails to organize them.
We switched from phpDocumentor to Doxygen because the former did not support PHP 5.3 features like namespaces and closures. phpDocumentor's last update was in 2008.
The major #-attributes are the same in Doxygen, because they both do JavaDoc-style comments. It is quite configurable, too.
You can also try DocBlox; it is a new kid on the block (pun intended) but already supports many of the features that phpDocumentor provides and many of the newer things (like namespaces).
Please try it out at https://www.github.com/mvriel/Docblox
Doxygen is pretty complex, and it's supposed to support PHP 5.3 features. However, it didn't work exactly how I wanted it and I realized it's a big program, but not designed for PHP; so I needed something lighter, simpler and preferably PHP exclusive, because let's face it, PHP does not have quite the common programming language syntax and look.
I know you mentioned it, but I chose PHPDoctor in the end. It does indeed lack some features, but it's simple and fast, exactly what I was looking for.
Let us know what you chose and what were the reasons.
Also something to mention is that I found the PHPDoctor interface to be quite simple and easy to style (with few CSS changes). I was able to create quite a clean page for my docs.
I've been using Natural Docs, works well for me
I've been playing around with two nice php based ORMs. OutletORM and phpDataMapper.
Does anyone have experience with them? Any advantages of one over the other. It's also a good question to ask which one has a bigger user-base.
The are both implementations of the Data Mapper pattern.
Whereas phpDataMapper is a more loyal approach to the pattern, I've found it to be a bit too idealistic and strict at times.
OutletORM, on the other hand, is a lot more pragmatic and flexible (doesn't require you to extend any base classes for instance). It is also a more mature project.
Doctrine is a great project but is huge and bloated for most simple uses.
I'd go with Outlet!
I'm working with phpDataMapper right now. Two issues I have run into so far are:
The "documentation", which is nothing but a bunch of examples that only covers part of the functionality. No reference...! You have to go through source files and experiment if you want to use anything that is not in there (like delete()!)
No "binary" (blob/mediumblob/binary/etc...) type. I had to add it myself!
Other things I have noticed:
Their "entity" model is kinda useless, I mean I am just adding functions to the mapping class itself... what was that for?
There is a "pagination" php file which looks interesting, but of course no documentation anywhere to be seen.
the source is surprisingly small and neat, which is really good since (sorry for repeating myself) there is no doc!
All in all a rather nice experience, but not exactly a magic time saving piece of code... if you want to use it be ready to do some code reading and modification on their source.
I have found this tutorial online
http://net.tutsplus.com/tutorials/php/creating-a-php5-framework-part-1/
I have created myself a simple sort of framework, but I have not been too knowledgeable whether I have followed best practices and the like... which I really would like to do.
I am looking at making my framework more unified by the MVC pattern. It seems I have sort of followed the principles, but I won't be happy until I can say my framework follows the design verbatim (and can, when it needs to be, easily picked up by another developer).
My question is, is this tutorial online a good place to start? I am using PHP5 with Apache.
Please note, I am not looking for the 'Why reinvent the wheel' type of answers, I'm doing this for fun and as a learning experience.
Alex, I must say I haven't read the article and please don't take this the wrong way, but I think the best way to learn about shortcomings of your own framework or to find out if it meets certain standards is to open it up - make it open source - and let other developers take part in it. They will be pretty quick to complain or point out flaws.
Even if your only goal in creating this framework is to learn, I think you can benefit from a code review. And what better way to get a code review than by inviting other people to join you in your "quest".
This way you should also have the chance to challenge the others code and maybe ask questions to find out why they write code a certain way.
I hope you'll find this at least a little bit helpful ;)
P.s. I'm going to take a look at that link now..
I haven't read the article you referenced, but one way to find out if your framework is useful is to try using it in a different way than we did before.
You may want to experiment with when to use classes in PHP and when not to, as it isn't one size fits all.
You may want to try to not have your business logic tied up in the same php file as your html, but keep them separate if you want to follow good MVC practices.
Good luck. :)
Why are so many people still writing crappy versions of things in standard libraries? Not to go after PHP developers, but guys go read the PHP SPL
Peer review can help catch that kind of thing. If you have another developer looking at the code, and they continually find implementations of standard library methods, it should fail the review unless there's a good reason for reinventing the wheel.
Young, ambitious programmers like to solve every problem on their own. They don't need no stinkin' libraries. Older, lazy programmers would rather search for existing solutions to the problem at hand.
So my advice: the next time you hire a programmer, choose the old guy who falls asleep in the reception area.
Just kidding, mostly. Peer review and education is the answer.
Better search techniques. and Domain Specific Familiarity
How does a developer check for a function they dont know the name of? Or perhaps there isnt an EXACT built in function to do what they want, but something they can use to save a lot of code. You need to be able to find the right terminology for the problem at hand, and from there you know what to search for. This is best achived by reading topics specific to your problem domain. Get away from coding specific resources and spend sometime in the field which you are coding for... wether it be retail, medical, insurance, etc.
Summary: Assumption is the mother of all FUBARs
I see this a lot from colleagues who are unfamiliar with the concept of frameworks (god how they complain about "two languages in one"), to wit: old C++ guys suddenly confronted with C# diving in head first to recreate hashtables from scratch...
Clearly a big part of this phenomenon from that angle is not stepping out of old mindsets and habits. If you're in a new environment you need to learn the new rules. The only way to deal with that from the outside looking in is to provide training, whether that's pair-programming for a while or something more formal.
Lack of familiarity with your tools breeds the contempt of others.
A simple coding style document might help by reminding the devs that there are libraries available (maybe list some preferred) and that they should be familiar with them.
Sometimes, you just have to remind people.
A peer review would help.
PHP is well documented if and only if, you know exactly what you're looking for. For example, you'd open Arrays and Array functions sections to see what you can do with arrays. And guess what, there is not even mention of SPL.
You should also encourage research before actually setting out on writing code. I usually approach problems by thinking about a way to do it, then I try to find anything in the standard library or any other libraries that will help me out. I'd say that an hour of research in some cases can be worth days of coding.
If people aren't doing this, it may be a good idea to have someone ask them questions about their general approach to the problem and what library functions/classes they are thinking about using. If they're missing something obvious, suggest it to them.
Two reasons pop to mind quickly. First, the Standard PHP Library isn't WELL known, and suffers from poor documentation. The php.net website is widely considered the language's best asset, but a lot of the newer built in classes (such as the SPL, reflection API, DomDocument, etc.) are little more than a list of methods without a lot of context.
More importantly though, it looks like the full SPL never shipped by default with any version of PHP prior to the (unreleased) 5.3. This is a killer as far as adoption goes. Usually people writing PHP code don't have control over what gets complied into their PHP binary. That's handled by their web-host and/or operations team, and web hosts and/or operations teams have different goals than a developer and aren't going to install every optional extension that comes along. This also means projects like Drupal, Joomla, Wordpress, etc. can't rely on the SPL being installed everywhere, so they don't use it.
Part of the reason PHP "won out" over perl was a single install had everything you ever needed. Optional extensions have never become widely adopted until they became part of the base install.
Very hard question to answer. Obviously peer review helps, but also proper documentation. Do your projects have technical specs, where you map out the classes and intefaces to be created?
If so, someone else on the team should review the specs and point out where existing code could be used...
Agree with training and peer review, but also enforcing unit testing and code documentation should help with the NIH syndrome :)
I'm in the process of trying to move our company from SalesForce to SugarCRM, but I've run in to a nasty bug (the moment I add a custom field to Accounts, all accounts stop showing up). We've paid for support from the SugarCRM people, but they only have take-forever-then-get-a-worthless-response-level tech support for the open-source version (and we avoid proprietary software like the plague). Oh, and did I mention our Salesforce contract expires at the end of the week?
So, long story short, I'm stuck debugging the SugarCRM app myself. I'm an decently experienced programmer, and I have baseline PHP competency, but I don't even know where to being trying to solve this issue. Can any Sugar developers out there recommend any kind of process for debugging Sugar? Are there any resources out there that would help me to understand what the different PHP files do, or how the Sugar system works overall?
Just as an example of the sort of thing I'm talking about: I figured out how to get sugar to print stack traces, and by following several I noticed a pattern with all the problem lines involving $this->_tpl_vars
I'd love to try and figure out why that method call isn't working, but I don't know:
A) what _tpl_vars is supposed to do
B) where _tpl_vars is defined
C) what $this is supposed to be
D) where in the framework $this gets set
etc.
So if anyone can help explain how/where I would start finding answers to these questions, I'd be incredibly grateful.
I worked with SugarCRM a couple years ago, and although I loved what I saw on the surface, I ended up rejecting it for our project because of what you are experiencing now. The internals of the product are woefully underdocumented. I had envisioned writing a bunch of slick modules for the product, but the resources just don't exist. You'll spend all your time digging through code, pouring over forum posts, and trying to find examples of what you're trying to accomplish. Doesn't sound like things have gotten much better.
Given that your PHP experience is less-than-guru level, and you're undoubtedly busy with a lot of other tasks and deadlines, I think you should maybe reconsider this transition if it's not too late, at least until you get a better comfort level with Sugar. If you're forced to move to Sugar because of an expiring contract with Salesforce, I think you might be in for some serious heartburn!
Use the Krumo library to help. It's super easy and way better than var_dump or print_r.
Simply download the source code and add it somewhere in your custom folder. I use the custom/include folder.
Then override a View or whatever you need to look at. Include the path to file class.krumo.php file, and krumo whatever object you want to take a look at:
Quick example -
<?php
require_once('include/MVC/View/views/view.detail.php');
require_once('custom/include/krumo/class.krumo.php');
class AccountsViewDetail extends ViewDetail {
function AccountsViewDetail() {
parent::ViewDetail();
}
// Override the parent function "preDisplay" to add our own template
function preDisplay(){
krumo($this->bean);
$metadataFile = $this->getMetaDataFile();
$this->dv = new DetailView2();
$this->dv->ss =& $this->ss;
$this->dv->setup($this->module, $this->bean, $metadataFile, 'custom/modules/Accounts/tpls/AccountsDetailView.tpl');
}
}
?>
You'll get a nice object on the page that you can drill into.
Although it's not a perfect answer to my question, this article:
http://developers.sugarcrm.com/wordpress/2008/09/26/where-is-the-code-for-x/
did help a bit. Also when I looked further through the official Sugar docs I found that the Developer Guide does contain some explanation of how Sugar works (although obviously it's not as focused on how Sugar works so much as it's focused on how to make Sugar do new things).
Hope that helps any other burgeoning Sugar devs out there.
These code are coming from Smarty lib, not coming from SugarCRM directly.
Maybe this chm doc will be a little helpful, http://code.google.com/p/sugardoc/downloads/list.
You can also try installing xdebug (PHP extension) and stepping through the code with a compatible IDE such as eclipse or Komodo.
The URL tells you which module directory is being accessed and which action/view. There's a "views" folder under most modules. If it's not there, it's either using the default MVC view in the include folder in conjunction with the metadata layout, or it's using the classic view architecture: index.php (listview), DetailView.php, and EditView.php and templates.
A lot has changed for the better in the last couple years, so I'm not sure the first answer (Nack) is still relevant. It's still pretty rough around the edges, but the new Sugar framework is a PHP hacker's best friend (really easy to override stuff in an upgrade-friendly manner). It's great for companies who happen to already have PHP hackers and only need a few enhancements. And finding affordable PHP contractors to help out isn't that hard (disclaimer: I am one). I think it's a great tool if you're into open source, just need basic CRM and have fewer than 100 users.
tpl is smarty template files. They are used when displaying data on screen. How i do my debuging proces is create a lot of var dumps to error lof or just print them on screen.
Also get xdebug on the server, this will help you a lot. Sugar is mvc platform so get knowing how that works, and will be much easier then.
take a look at some snippets i post at www.eontek.rs
If I encountered the same problem, when the detail page of the account wasn't displayed and gave 500 internal error. I checked that it was not generated by the TPL. At first I checked the permissions on that folder, in my case they were all set. So I took the backup of cache\modules\accounts\DetailView.tpl and manually added the field, after that everything worked. Every time in the developer mode there's a need to manually copy this file. It's a pain, but there's still no answer. I have asked this in forums, Bug, Twitter, no help. By the way, we are using Sugar Professional.
I'd suggest making sure that it really is a code bug and not just a miss config. Are you adding the field through Admin > Studio > Contacts > Fields or through the SOAP API ?
Are you using the latest version of Sugar?
I really agree that the project it horribly under-documented and lacking in tutorials and examples.
I myself am experiencing the pains of outdated / missing documentation.
Good luck!
$this is a reference to the current object.
class Test {
var $tmp;
function __construct() {
$this->tmp = 42;
}
}