Code

After WSDLInterpreter moved out of beta just under a month ago, it's been getting a lot of use. I started this project because I wasn't pleased with the results I was getting from other wsdl2php solutions, and the native SoapClient class certainly has a lot of shortcomings that I've briefly outlined already. Some more things have come up in PHP's native SoapClient for what seems like some fairly basic usage, however.

The biggest issue so far seems to be (not) applying namespacing to deep wsdl objects. This one seems to work nearly uniformly for most of the other major languages' soap clients, but not PHP. An example of this is if I have class A with a member variable B (of type class B), with both classes defined by the wsdl, and class A is the parameter to the soap call, then class A will be properly namespaced but the member element B will not, and in the case of extended classes (for example, using class C which extends B as the value for $A->B), typing is not correct in most situations either. This causes problems on the server side, as the objects aren't marshaled in properly which then typically affects the responses returned. PHP's SoapVar can help you get around this by passing in a wrapped object instead of the native object, but this functionality should be the default rather than having to write methods to iterate through the objects being passed in to the soap call to ensure that all of the type information is properly set. With PHP being a weakly typed language, this is somewhat understandable from the native language perspective. However, when you venture in to the realm of web service calls, you are now dealing with a different language and need to respect its specifications in order to get back reliable results.

There is another problem with name spacing and with the structure of the native soap requests that seems to vary from many other languages' native soap clients, but I'm still investigating that to see what workarounds might be available.

A new release of WSDLInterpreter to address the first issue (and the second, if it ends up being worthy of addressing) is forthcoming. I plan on putting out an unstable release with these fixes and ask for support in testing it against all of the various wsdl's and web services that you all are using, as one thing remains true in the world of wsdl - standards are still 'evolving'.

Tonight marks a minor update to BaseApp, 1.0.0a5. Many users of BaseApp have requested direct support for deploying the archive into a hosting provider where they are not able to have some of the files out of the web space. While the security of this is not as good as having everything except the html directory outside of the document root, it is a common occurrence and not addressing this situation could be more hazardous for some users without proper guidance. This update provides an index.php in the root directory, and .htaccess files in subdirectories to restrict direct code access or access to other files. It is recommended that you delete the html directory if you plan on deploying in this manner, and to read the comments in the index.php bootstrap to better understand this deployment.


Download this update to BaseApp, v1.0.0a5, and get started today!

Based on the continual positive feedback I've received on the latest version of WSDLInterpreter, I've decided to release it with some minor fixes as the first stable release, v1.0.0. Download it today using the button below and get started using the only full php5, oop-oriented wsdl2php solution publicaly available, or read more about the benefits of WSDLInterpreter as your wsdl2php solution.

This entry is about the use of Zend Framework and BaseApp, an application layer built on top of the framework libraries.

One of the things I noticed as I was getting started with the Zend Framework libraries was the smell coming from all of the bootstrap files... a lot of setting of variables, adding directories to this or that, creating various objects for random tasks, and a growing urge to do more and more setup in this bootstrap. This is BAD practice for a few reasons, but here are the two big ones for me:

• Maintainability - did we not learn from php4? Non-OOP code just gets worse and worse over time. It gets unorganized, it gets unfocused, and soon the bootstrap, just like the index.php scripts of old, begin to do too much for their role.
• Reuse - which sounds like a better idea: copying the code over and modifying the section that you want to act differently? or extending a class and only writing new code where its applicable? If you found yourself nodding in approval to the first option, buy this book for good insight into why the second option will make your life much easier.

BaseApp minimizes the bootstrap to a very simple form: set the application path, instantiate the main application class, call any special configuration methods of that object, then execute the main method of the application object. In the included example index.php, this is 5 lines of code. The application object, BaseApp_Loader, handles all of the specific setup that you otherwise see in bootstrap files.

So what about BaseApp_Loader? What does it do? Why is it better than a typical bootstrap?

• XML Configuration - Uses Zend_Config_Xml to load an application level configuration file. Now if you want to launch a second copy of a site, for example, you can use the same exact code libraries and point at different configuration file to use different databases, etc. By using an xml configuration and capturing exceptions through the main application setup process, simple errors like typos won't bring your site crashing to 500 Internal Server Error.
• Method Based Configuration - Each type of configuration is split off into its own method within BaseApp_Loader, so if you want to setup logging to do something other than Zend_Log, or configure database usage differently than the default Zend_DB implementation, you can override the individual method in an extension of the BaseApp_Loader class. Each of these methods receives a Zend_Config object rather than referencing the application's config directly, allowing for easy overrides by subclasses while minimizing the impact of the underlying structure.
• Zend_View Choices - Included in the default implementation are Zend_View and BaseApp_View_Smarty (a Smarty based view). BaseApp allows you to decide what view you want to use in a way that is flexible, and you can add your own if you want (by following BaseApp_View_Smarty as an example, if you need).
• Easy Registration - For modules, views, log control, database control, helpers and more. Utilizing these powerful constructs provided by the Zend Framework libraries is extremely easy using the BaseApp_Loader's methods or overriding them with your own.

Thanks for everyone's patience last week. Some other projects took precedence and I couldn't get as much time into BaseApp as I would have liked. There were some good comments on the last release though, and I'm seeing some good download numbers. I've taken some of those comments and integrated them in; other's didn't make as much sense to carry over into the main source, but thats why this is BaseApp. It thrills me to see people taking it and using it as a quick start for their own application, modifying it to fit their needs. This week has a couple of main additions:

• In previous versions, the authentication functions were commented out as I struggled to decide on what ORM to integrate. I really like propel, but I don't want users of BaseApp to have to have command line access. There are a couple of other up-and-comers, and hopefully they'll get to a stable release point soon. In the meantime, I've implemented auth using the Zend_DB libraries, so at least you can see a sample simple integration of those for adding users.
• Speaking of the auth module, I've also used the user login form to show examples of the power of the Xend_Layout request.
• Finally, I've started an administration abstraction. The main controller for this is AdminController in the default module, and each module reports its own admin functionality. No ACL is in place for any of this yet.

Next version:

• ACL integration into the administrative functionality.
• Example administrative controls using the auth module to add/edit/delete users.

Additionally, check back often for an "Inside BaseApp" series of posts that will be aimed at describing everything from setting up BaseApp to why particular object structures were chosen.

Thanks again to everyone for their continued support. You can grab the latest version from BaseApp Downloads.

The first formal release of WSDLInterpreter is approaching as almost all of the emails I'm receiving have changed from bug reports to acclamations. Thanks for everyone's support and help along the way. If you haven't tried WSDLInterpreter out yet, and are looking for an alternative to the other wsdl2php solutions out there, you can read about the benefits of WSDLInterpreter here, or download RC2 from the google code project.

To everyone waiting on the next pass of BaseApp, check back tomorrow. Updates include administration abstraction, Zend_DB, Zend_ACL, and more, I'm just doing a final look over of the new stuff before I release it.