<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Tue, 21 May 2013 19:59:08 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Eirik Hoem's Blog: Setting xsi:type for objects sent over SOAP (inheritance)]]></title>
      <guid>http://www.phpdeveloper.org/news/9822</guid>
      <link>http://www.phpdeveloper.org/news/9822</link>
      <description><![CDATA[<p>
<i>Eirik Hoem</i> has <a href="http://blog.eirikhoem.net/index.php/2008/03/17/setting-xsitype-for-objects-sent-over-soap-inheritance/">posted a tip</a> for all of the PHP SOAP developers out there - a method for setting the xsi:type correctly for objects sent in the message.
</p>
<blockquote>
I spent quite some time looking for info on how to specify the xsi:type for the objects, and I finally came across <a href="http://no.php.net/manual/en/function.soap-soapvar-construct.php">SoapVar</a>. I created a base class which the SOAP classes extended. A method called pack is responsible for setting xsi:type.
</blockquote>
<p>
In <a href="http://blog.eirikhoem.net/index.php/2008/03/17/setting-xsitype-for-objects-sent-over-soap-inheritance/">his example</a>, he creates a BaseClass to work from and builds a createCustomer class on top of it, defining a setCustomer function inside. When the new Person is created, a new Customer is too complete with the correctly formatted type on the object.
</p>]]></description>
      <pubDate>Wed, 19 Mar 2008 10:26:27 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Marco Tabini's Blog: Now showing: PHP's true colours]]></title>
      <guid>http://www.phpdeveloper.org/news/8561</guid>
      <link>http://www.phpdeveloper.org/news/8561</link>
      <description><![CDATA[<p>
<i>Marco Tabini</i> (of <a href="http://www.phparch.com">php|architect</a>) has <a href="http://mtabini.blogspot.com/2007/08/now-showing-phps-true-colours.html">posted some thoughts</a> to his blog about the PHP4 end-of-life announcement and its relations to the current push to <a href="http://www.gophp5.org/">go PHP5</a> - mainly how it relates to hosting providers.
</p>
<blockquote>
I'm sure that a large number are owners of small hosting firms - which, by far, provide the vast majority of PHP-powered websites that Netcraft carefully tracks for us - that sell cheap shared hosting. [...] If you provide shared-hosting plans, it's likely that your servers are still running PHP 4. Upgrading to PHP 5 is a logistical nightmare for two reasons: first, you don't necessarily know that you'll be able to properly set up and secure your systems; second, you don't know that your customers' applications will keep on running.
</blockquote>
<p>
Both reasons can cause very different kinds of hassles for the hoster, especially when it comes to their customers. As <i>Marco</i> puts it "hell hath no fury like a customer scorned". When things are going smoothly, everything's good, but the second that you try to explain that the update is what's good for them, all they see are things breaking and freak out.
</p>
<p>
He <a href="http://mtabini.blogspot.com/2007/08/now-showing-phps-true-colours.html">suggests only one real solution</a> - make the move and tell the customers now that things are changing. Help them all you can (with information about updated software and resources) but ultimately it's up to them to make the change.
</p>]]></description>
      <pubDate>Thu, 30 Aug 2007 12:27:00 -0500</pubDate>
    </item>
  </channel>
</rss>
