Posted on

Dealing with Zend Studio validations

I’ve been struggling quite a while this afternoon for making Zend Studio behave as expected, and I got it!

Zend Studio was marking many warnings in WSDL files that it wrongfully interpreted as HTML rather than XML.

I wanted to disable validation only for those files and couldn’t find out how. I had already excluded their parent folder from the Build Path, but it didn’t work for warnings of this kind.

Those files have a php extension, and HTML validation is twofold: one for HTML files and one for PHP files.

So I changed the settings for the line reading HTML Syntax Validator (for PHP Files) from

to

and after a clean build I got

Posted on

Call to undefined function ‘output_cache_disable’

This is a Zend Studio warning that has been bugging me lately.

The culprit is the file dummy.php, distributed with Zend Debugger. As per the installation instructions provided by the README file, one should “4. Copy the dummy.php file to your document root directory.” but the project I’m currently reviewing (FengOffice 1.7.3.1) has three copies of that file in three different folders. So a build in Zend Studio always gives that warning three times.

I know that in this particular case, I could simply erase all the dummy.php copies in the project, and forget the issue. And that’s exactly what I’m going to do.

But the issue is caused by a common programming idiom in PHP.

{[ .dummy | 1.hilite(=php,ln-1=) ]}

The code calls a contextual function only if it exists (@3-5). This is certainly correct, but fools up the simple Zend Studio validator.

It would be better if the code defined the expected contextual function if it didn’t exist, and called the function in any case (@3-6).

{[ .smarter_dummy | 1.hilite(=php,ln-1=) ]}

This makes Zend Studio give no more warnings.

Anyway, all in all, I think that Zend Studio could be a little smarter and don’t give warnings for function calls inside function_exists blocks.

I know that this could be quite difficult to implement, so an alternative workaround could be an option for telling Zend Studio not to show a specific warning, specific up to the file and line, i.e. up to a single issue in the problems panel.

Posted on

Understanding internal and external code in Zend Studio

A project in Zend Studio is simply a root folder.

Assuming that the boundaries of the folders subtree delimit internal code is accurate for almost any project at its beginnings, but as time goes by, limitations arise. For example, version and documentation files are not to be considered part of the code of the project.

Zend Studio overcomes those issues by means of the Build Path concept, so that only code that is reachable through the Build Path is internal code. The build Path is then used by Zend Studio for knowing what code to validate. In fact, if you want to exclude some code from the validation check, you have to exclude that code from the Build Path.

Related to the Build Path concept is the Include Path concept. The magic behind “Navigate/ Open Declaration” succeeds for any code that is reachable through the Include Path. If you exclude some code from the Build Path, sooner or later you’ll discover that “Navigate/ Open Declaration” fails for any excluded code. The solution is to add that code as an external source folder.

All of the above makes sense if you consider how Build Path and Include Path are set up. The Build Path is by default anything inside the root folder of the project, and the Include Path is always at least the Build Path. These settings make a standard / simple project work without added configuration. If a project needs fine tuning, then internal code can be defined changing the Build Path, and external code can still be referenced changing the Include Path.

Summary

  • the Build Path defines what is the internal code (by default the project subtree)
  • the Include Path defines what is the code context (always internal code + external code)
  • if you exclude something from the Build Path, chances are that you need to add that something to the Include Path as an external source folder

Example

The build process of Zend Studio finds issues in code from third parties that you host in a library folder of your project. There are so many issues that you can’t easily see your own, and you can’t solve those issues because you want to use third party code “as is”, so that when a new version of that code is available you can simply drop it in place. The solution here is to exclude the library folder from the Build Path and add it to the Include Path as an external source folder.

The above picture shows that the Build Path of a project includes all but the library folder.

The above picture shows that the Include Path of the same project lists the library folder as an external source folder.

—

Zend Studio Documentation: http://files.zend.com/help/Zend-Studio/configuring_build_paths.htm