SitePoint Sponsor

User Tag List

Results 1 to 17 of 17
  1. #1
    Umm. PHP Guru....Naaaah jaswinder_rana's Avatar
    Join Date
    Jul 2004
    Location
    canada
    Posts
    3,193
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Looking for Advanced PHP Demos

    Hi,

    For an internal presentation at our company, we are trying to compile list of advanced a.k.a. cool things which can be done with PHP. We are calling this "Next Web Presentation" so something which can show power of PHP along with a "cool" way of doing it.

    I searched around and also walked through http://www.sitepoint.com/forums/show...-PHP-Resources but couldn't find much.

    Can you please list some which we can include in our presentation?

    Thanks
    ---------------------------
    Errors = Improved Programming.
    My Site

  2. #2
    SitePoint Evangelist
    Join Date
    May 2006
    Location
    Austin
    Posts
    401
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    There's some interesting stuff here: http://www.tuxradar.com/practicalphp
    Merchant Equipment Store - Merchant Services, POS, Equipment, and supplies.
    Merchant Account Blog | Ecommerce Blog

  3. #3
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,149
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    Design patterns and software architecture are what I would consider "advanced" for a PHP programmer, but neither of those will give you something flashy for a presentation. Even the best architected programs will still only spit back boring looking HTML. Otherwise, you could talk about some prepackaged libraries that do cool things. The Zend and Symfony frameworks have a nice set of libraries. Zend Lucence, for example, probably ranks up there on the coolness meter.
    "First make it work. Then make it better."

  4. #4
    Umm. PHP Guru....Naaaah jaswinder_rana's Avatar
    Join Date
    Jul 2004
    Location
    canada
    Posts
    3,193
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You are right. Anything I do will be just backend and HTML will still be front end. I guess I could show them some CMS systems (Drupal etc) on how we can get up a basic site up and ready and then talk about Zend framework to create large enterprise applications.

    Maybe I could also show them LDAP integration for internal applications; this is just for PMs to show what we could achieve with PHP.

    Thanks
    ---------------------------
    Errors = Improved Programming.
    My Site

  5. #5
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Maybe something in here http://tutorialzine.com/2013/02/24-c...ld-know-about/, also , search sourceforge.net and constrain it to language: PHP

  6. #6
    Umm. PHP Guru....Naaaah jaswinder_rana's Avatar
    Join Date
    Jul 2004
    Location
    canada
    Posts
    3,193
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks. I'll go through that list and see what I can add to presentation
    ---------------------------
    Errors = Improved Programming.
    My Site

  7. #7
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,149
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    Maybe something in here http://tutorialzine.com/2013/02/24-c...ld-know-about/, also , search sourceforge.net and constrain it to language: PHP
    From that list, I especially like Assetic. It can combine and minify CSS and JS on the fly. It can parse SASS or LESS on the fly. Along with many other possible filters.

    Goutte is also a fun one. Effectively a browser in PHP, complete with cookie sessions, response caching, and the ability to crawl the responses using CSS selector syntax.
    "First make it work. Then make it better."

  8. #8
    Umm. PHP Guru....Naaaah jaswinder_rana's Avatar
    Join Date
    Jul 2004
    Location
    canada
    Posts
    3,193
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I liked snappy one. We were looking for one for our next project and this will make it easier.
    ---------------------------
    Errors = Improved Programming.
    My Site

  9. #9
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Cups View Post
    Maybe something in here http://tutorialzine.com/2013/02/24-c...ld-know-about/, also , search sourceforge.net and constrain it to language: PHP
    Yeah, its a good list, 24 cool PHP libraries you should know about - this time I formatted the link so the full title is readable because the list deserves to be investigated.

  10. #10
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I suppose it depends what you mean by "Cool things". From going to intermediate to advanced, really you're looking at design patterns, best practices and advanced OOP theory. None of which are really PHP Specific.

    Rather than repeat myself, I'll repost my thoughts on the subject from here: http://www.sitepoint.com/forums/show...t=#post5304801

    Quote Originally Posted by TomB View Post
    It's a long process that only comes with practice. Once you move beyond asking "How can I solve this?" to "How should I solve this?".

    In general, I'd say applying a couple of principles to your code will demonstrate to you how to code is better. It's not immediately obvious what advantages they give until you've used them in real projects. The benefits come to you when you try to use your code and realise how flexible and easy to maintain it is.

    1) Favour composition over inheritance. I actually removed 99% of "Extends" keywords from my codebase and it became a hundred times better. It wasn't until I did it that I realised quite how much I was coding to work around inheritance and using it where I really shouldn't be.

    2) Make all class variables private and avoid getters/setters unless they are absolutely needed. This goes hand in hand with 1) but it will help you achieve better encapsulation, which is a fundamental principle in OOP.

    3) Dependency inejection. Once I started using a dependency injection container, I realised that most of the code I had was messy. Creating objects arbitrarily is messy! Try IoC (inversion of control) and you'll quickly see the benefits.

    4) Law of demeter: http://en.wikipedia.org/wiki/Law_of_Demeter Apply this and your code will become better. It's not immediately obvious if you don't understand it, but it forces you to think about the dependencies your classes have.

    5) Unit testing. Once you start writing code that's easy to test, you have code that's easy to isolate and therefore, reuse.

    That's my top 5 tips for going from "advanced" to "pro".

  11. #11
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jaswinder_rana View Post
    You are right. Anything I do will be just backend and HTML will still be front end. I guess I could show them some CMS systems (Drupal etc) on how we can get up a basic site up and ready and then talk about Zend framework to create large enterprise applications.

    Maybe I could also show them LDAP integration for internal applications; this is just for PMs to show what we could achieve with PHP.

    Thanks
    The problem with showing them Drupal is that then you might end up having to use it *shudders*.

  12. #12
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Hey Tom - some good advice there.

    Regarding 3) - Dependency Injection - I currently do stuff like having a setMethod for objects I want to use with other objects. I find I can do mocking in unit testing etc this way. What advantage does the Depedency Injection Container have over this method?

    Cheers!

    Quote Originally Posted by TomB View Post
    I suppose it depends what you mean by "Cool things". From going to intermediate to advanced, really you're looking at design patterns, best practices and advanced OOP theory. None of which are really PHP Specific.

    Rather than repeat myself, I'll repost my thoughts on the subject from here: http://www.sitepoint.com/forums/show...t=#post5304801

  13. #13
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    Hey Tom - some good advice there.

    Regarding 3) - Dependency Injection - I currently do stuff like having a setMethod for objects I want to use with other objects. I find I can do mocking in unit testing etc this way. What advantage does the Depedency Injection Container have over this method?

    Cheers!

    Generally I would advise against ->setDependency($foo) because it indirectly breaks encapsulation. It exposes the internal state externally. If $foo is a true dependency and some/all methods will not work correctly without it then you can end up with a seemingly fully constructed object in the application which doesn't work as documented because it's state is incomplete.

    Setters for optional collaborators such as $router->addRoute(); are useful, but these should be reserved for cases where the object will work as advertised even if the method isn't called. Anything which is a true dependency (Required for the object to work as intended) should always be passed in to the constructor for this reason.

    On the topic of containers, from a practical perspective, the first thing you'll notice is that they remove a lot of the programming overhead. For instance:

    PHP Code:
    $a = new A(new B, new C(new D, new E(new F))); 
    Can be abstracted to:

    PHP Code:
    $a $dic->create('A'); 
    The second big advantage comes with maintainability. Imagine F in the example above has a dependency of G introduced. This can be configured in the container and every time an instance of F is created it can be passed its new dependency, rather than having to go through all your code locating "new F" and then working out where to get its dependency from.

  14. #14
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Generally I would advise against ->setDependency($foo) because it indirectly breaks encapsulation. It exposes the internal state externally. If $foo is a true dependency and some/all methods will not work correctly without it then you can end up with a seemingly fully constructed object in the application which doesn't work as documented because it's state is incomplete.

    Setters for optional collaborators such as $router->addRoute(); are useful, but these should be reserved for cases where the object will work as advertised even if the method isn't called. Anything which is a true dependency (Required for the object to work as intended) should always be passed in to the constructor for this reason.

    On the topic of containers, from a practical perspective, the first thing you'll notice is that they remove a lot of the programming overhead. For instance:

    PHP Code:
    $a = new A(new B, new C(new D, new E(new F))); 
    Can be abstracted to:

    PHP Code:
    $a $dic->create('A'); 
    The second big advantage comes with maintainability. Imagine F in the example above has a dependency of G introduced. This can be configured in the container and every time an instance of F is created it can be passed its new dependency, rather than having to go through all your code locating "new F" and then working out where to get its dependency from.
    I think I get you there - so basically it's like a way of reliably setting up your dependencies - like a central repository just for dependencies, so if you need to change the way a dependency is set up you just do it once in the container, rather than scanning your code? Makes sense.

    In terms of what you said about the setDependency() method then - how would you deal with this? I have occasions where I'll have a dependency that I don't want to test in a unit test, so I use the setDependency() method to use a stub or mock for unit testing. I take it you'd use the dependency container in both cases, or would you use some other method like reflection in the unit test or something like that?

  15. #15
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    During the test you'd pass in a mock. As you're already familiar with them, I'm not sure I understand your question. In terms of testing, I can't see why:

    PHP Code:
    public function testMyObj() {
         
    $myObj = new MyObj($this->getMock('SomeDependency'));

    is any different from:

    PHP Code:
    public function testMyObj() {
         
    $myObj = new MyObj;
         
    $myObj->setDependency($this->getMock('SomeDependency'));

    I wouldn't use a dependency injection container for testing because, firstly, you don't want to be testing the container, and secondly, tests shouldn't ever be complex enough to warrant object graph creation or you're testing too much at once.


    I think I get you there - so basically it's like a way of reliably setting up your dependencies - like a central repository just for dependencies, so if you need to change the way a dependency is set up you just do it once in the container, rather than scanning your code? Makes sense.
    Exactly, it means you can arbitrarily add dependencies to any class in the system at any time without breaking anything. Without using the container, imagine adding a dependency to an integral part of the system, you'd have several things to worry about: 1) In how many places is that class initialised. 2) How can the code which is calling the updated constructor access the new dependency? Without a container, you need to use a factory or pass the dependency all the way down the object graph.

  16. #16
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Think I see what you mean - you're saying you'd use the constructor to pass in dependencies required by the class as opposed to using a setmethod that could leave the class not fully ready for action... Yeah, nevermind, I get what you're saying now.

    Quote Originally Posted by TomB View Post
    During the test you'd pass in a mock. As you're already familiar with them, I'm not sure I understand your question. In terms of testing, I can't see why:

    PHP Code:
    public function testMyObj() {
         
    $myObj = new MyObj($this->getMock('SomeDependency'));

    is any different from:

    PHP Code:
    public function testMyObj() {
         
    $myObj = new MyObj;
         
    $myObj->setDependency($this->getMock('SomeDependency'));

    I wouldn't use a dependency injection container for testing because, firstly, you don't want to be testing the container, and secondly, tests shouldn't ever be complex enough to warrant object graph creation or you're testing too much at once.

  17. #17
    SitePoint Member imsas's Avatar
    Join Date
    Feb 2011
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you're interested in presenting the "web services" aspect of PHP this company has some cool PHP integrations so some of their data:

    http://www.imsasllc.com/docs/

    Hope this helps!
    ___________________________________________________________________
    IMSAS Background Check - Background Check API
    PeopleSearchWorld.com - People Search
    CabinPay - Credit Card Processing


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •