Professional PHP » WACT

Delicious Outage Link Dump

Jeff — Mon, 19 Dec 2005 18:21:53 +0000

Del.icio.us has been down for a while. I use it for my public bookmarks, which are listed on the side of this blog. Here is a post with some recent random things that I would bookmark if I could.

The departure of the hyper-enthusiasts - “The Java hyper-enthusiasts have left the building” (along the lines of this.)
The New Methodology - Martin Fowler describes Agile methodologies — recently updated.
PHP on Caucho - PHP on the JVM.
XML 2.0 - some thoughts on XML 2.0.
Web Patterns - Under construction — check back later.
Web Design Patterns.
Carnival of the Agilists.

I’m currently adding UTF-8 support to and generally improving WACT’s “liberal” xml/html parser. A few sources of tests cases and information:

PHP Framework Consolidation?

Jeff — Mon, 28 Nov 2005 03:55:09 +0000

There is recent interest in consolidating Java frameworks with similar approaches. WebWork is joining Struts, which surprised me. Along the same lines, the Java Web Alignment group brings together many big players in the Java framework space:

The Java web framework landscape has become quite fragmented; the purpose of this group is to explore synergies among the existing frameworks that will make life easier for companies, organizations, and developers working using Java to build web applications.

A reaction to Rails?

As I suggested in The Value of MVC, the science of writing web applications is maturing and we are entering the age of frameworks.

Will there be a similar consolidation of PHP Frameworks? Or will Zend PHP Framework rule them all? eZ systems for one isn’t conceding just yet and continues with their eZ publish Enterprise Components. I expect other to do the same. We shall see.

Every once and a while I get an odd email from someone I have never heard of suggesting that WACT should merge with project X. The messages are usually poorly thought out and slightly insulting and never from anyone actually involved with either project X or WACT, but I certainly wouldn’t oppose such a thing if it made sense and there was some interest and synergy from the other party. Unfortunately, the fact that WACT 1.0 will support currently installed versions of PHP (meaning 4.x) is probably a deal breaker for the kinds of people who are interested in writing frameworks. After WACT 1.0 is out (Q1 2006) I would like to skip PHP 5 and target PHP 6 for WACT 2.0. (Other WACT stakeholders may have different ideas.) The framework landscape will probably be different then. And there is one other framework I’ve been keeping an eye on ….

Installing PEAR Based Applications

Jeff — Wed, 20 Apr 2005 05:05:40 +0000

Ok, Greg Beaver’s work on channels has resurrected my interest in PEAR. I am interested in providing WACT on a PEAR channel and I’d like to better integrate WACT with some PEAR packages. My primary concern is over the installation implications.

I didn’t find a “powered by PEAR” section on the PEAR website. Can anyone recommend some large, widely deployed end user oriented applications based on PEAR? I want to try going through the installation process in some challenging environments. I’m just trying to get a feel for best practices and potential problems with installing PEAR and applications that depend on PEAR.

php testing and coverage

Jeff — Fri, 08 Apr 2005 15:18:30 +0000

I ran across this O’Reily article about SpikeSource today. Very interesting.

They have released a coverage reporting tool, Spike PHP Coverage, for PHP that works with XDebug coverage data. It works with Simple Test and it seems to be able aggregate the results of remote test runs, such as for web based tests. I have wanted something exactly like this. I can’t wait to get the chance to generate a consolidated coverage report for WACT.

It seems that they have the capability for generating and aggregating code coverage reports for PHP itself. I haven’t had a chance to check this out, but its something that I have always wondered about.

Additionally, it looks like they accept contributions of Test Suites. If I understand this correctly, it means that I can upload the WACT test suite and that it can be used to test and generate coverage reports for PHP 4 and for PHP 5 as well as the framework. If this is true, this is a big deal. As there are more and more applications with automated test suites, it only makes sense to aggregate them to test PHP itself.

It also seems that they have embraced Simple Test for php testing. Congratulations, Marcus. Simple Test is a fine piece of software.

I think code coverage measurements are important for gauging the quality of a test suite on open source projects, where there can be less formal development practices and a large number of contributers of varying skill levels and motivation.

Status of WACT

Jeff — Mon, 25 Oct 2004 21:33:42 +0000

My last WACT post drew a couple questions from Marcus Baker:

Do you have a release date planned for the next version?

Ah, the release date question. We are certainly overdue. Here is where things stand.

The core framework in CVS is in very good shape. We have 3332 passing tests and 5 failing tests. The failing tests are relatively minor. I would like to fix them before release, but don’t see it as absolutely necessary.

I feel the biggest obstacle right now is that many of the example programs that we have in WACT are either obsolete, broken or unfinished. They are mostly broken due to the incompatibility of changes within the controller layer from the last version. I would like to see working (and hopefully unit tested) examples for the release. I don’t want to make a release with code that errors out.

The current controller architecture in the CVS version of WACT is very different from what is in the previously released version. After writing what is there now, i have modified my thinking on what a controller framework should look like. I’ve written up some of the theory of this on this Model View Controller page. I’ve been working on a proof of concept of this, which I think will become the final WACT controller layer.

As such, I am reluctant to go through the examples now and update them to the current controller when I know that I will have update them again. I am also reluctant to expose a brand new API in the release which I already know will go away.

I’ve decided I want to work on the controllers and not the examples right now. That of course doesn’t preclude anyone else who wants to work on the examples from doing so and getting us into releasable condition. Thats just how I want to spend my time right now. If we are going to release with what we have now, which i am not opposed to, someone else will have to step up and push that.

Its possible that my controller ideas won’t work out. I’ve just reviewed the 3.0.0dev version of Mojavi. I have to say I am impressed. I have looked at most of the controller frameworks on this page and i have to say that Mojavi is the only one that i would seriously consider using myself. It has the right combination of support, maturity, and good design. If my experiments with MVC don’t pan out, i would seriously consider ditching the current WACT controller layer in favor of Mojavi integration.

So thats where I am at. I would personally like to see more of the controller issues resolved before the release goes out the door. I would like to feel as good about the controller layer of WACT as I do about the rest of it.

I should finish up with a project soon and have more time to devote to WACT.

When will the next WACT release be? I refer you here.

Marcus also asks:

The bit that I’ve never understood is, what is a DataSpace?

The DataSpace concept has evolved over time. in WACT, DataSource is an interface that allows an object to expose properties though a generic protocol. The DataSpace class is a convenience base class that helps implement this interface. The DataSource interface could be considered equivalent to the properties portion of the Java Beans specification. You could think of any object inheriting from DataSpace or implementing DataSource as a bean in java terms. However, I would probably compare it to the more dynamic Key Value Coding from Objective-C.

Bad Code Smells in WACT, a refactoring review

Jeff — Mon, 18 Oct 2004 21:32:04 +0000

This post shows some bad design elements in WACT and discusses how to improve them. It lists some related bad code smells in the WACT template compiler. It is a non-trivial example of refactoring in an established application and an illustration of OO design issues.

The TreeBuilder and ComponentParsingState classes may need to have code re-distributed between the two.

The TreeBuilder class performs two distinct tasks: building the tree (Managing the Component and ParentComponent fields) and constructing the component. This may be an example of a Large Class code smell. It is certainly an example of poor class cohesion.

The openBranch method of TreeBuilder has the job of both constructing the component and adding it to the tree. Breaking this method into two distinct functions would clarify the code and remove a Long Parameter List smell from openBranch.

The openBranch and closeBranch methods of TreeBuilder have boolean parameters. This makes these calls to TreeBuilder from the ComponentParsingState more confusing. (more on refactoring parameters and boolean parameters).

The closeBranch method performs two tasks. setting the hasClosingTag field is in this method for convenience. It is really a part of the construction of the component and probably belongs closer to openBranch. (conveniently eliminating the need for having a boolean parameter in closeBranch).

The Component construction methods on TreeBuilder pass along a Locator object through a deep calling tree. The Locator object is a field on the ComponentParsingState class. The many methods on TreeBuilder for constructing a component that are called from ComponentParsingState may be an example of the Feature Envy code smell. There seems to be some excessive coupling between ComponentParsingState and TreeBuilder. Perhaps the construction methods really belong to ComponentParsingState, not TreeBuilder?

The startElement, endElement, and emptyElement methods of ComponentParsingState show an example of the Innappropriate Intimacy smell by manipulating the component field of the TreeBuilder class ($this->TreeBuilder->Component->). They do this as part of constructing the component. This is probably further evidence that the component should be constructed inside the ComponentParsingState class and passed as a whole unit into the openBranch method of the TreeBuilder class for addition into the tree. Another example of excessive coupling.

The isServerTagComponentTag method of the TagJudge class instantiates a dummy component to examine a local variable containing information about the component and then throws the component away. The TagInfo records in the TagDictionary are supposed contain metadata about each component. The information returned by isServerTagComponentTag on the Component class should be moved into the TagInfo meta-data. Everytime isServerTagComponentTag is called, a TagInfo object should instead be available to call, thus elminating the isServerTagComponentTag method from the TagJudge Class. Eliminating the unnecessary object instantiation will probably result in a tiny performance improvement.

The calling of the isComponent method on TagJudge from ComponentParsingState is always a two stage process. First isComponent is called on TagJudge, then getTagInfo is called on TagDictionary. That combined with the call to getTagInfo inside the implementation of isComponent and the TagDictionary field of TagJudge, used only in isComponent, suggests that perhaps the isComponent method is really a sophisticated find method for tag information and should be a combined findComponent method on the TagDictionary class that returns NULL if no appropriate TagInfo class can be found.

Right now, the two stage component finding process in ComponentParsingState means that there is a one to one relationship between HTML tags and compile time component tags. However, the Switch Statement code smell in the InputTag suggests that a one to one relationship is not correct, and that we really need a one to many relationship. The code cannot support a one to many relationship as long as the finding of a TagInfo object is broken up into two stages and not encapsulated into the same place.

The fact that both methods on TagJudge can be moved to other classes, suggests that TagJudge is an example of the Lazy Class code smell. The TagJudge class can probably be eliminated.

The InputTagInfo class shows the Data Class code smell. instead of defining a unique class for each tag to be registered, a common TagInfo class should be available. An instance of this class could then be initialized and registered. Then the common TagInfo class would be available to move behavior to in further refactoring efforts. Additionally, this would allow the information in the TagDictionary to be loaded from configuration files, instead of requiring tag files to be included, a slow and unncessary process.

These refactoring issues are related to three WACT feature requests. Each of these three requests should largely be a change to the TagDictionary class and the (nonexistent) TagInfo class. The fact that theses features require broad changes across the template compiler is an example of the Shotgun Surgery code smell and an example of poor encapsulation around the TagInfo and TagDictionary classes.

Allow multiple components per tag
Convert TagInfo to XML based format
Lazy loading for Compiler Components

Note that implementing the lazy loading will have a significant impact on compilation times, illustrating that fully refactored normalized code is easier to performance tune.

Anyone else see any additional code smells here? Anyone up for a non-trivial refactoring learning exercise? I hope to be able to eventually post the refactored versions of these files.

Rephlux and PHP memory usage with a PEAR surpise

Jeff — Fri, 28 May 2004 02:37:56 +0000

Jon Ramsey came up with a continuous integration tool called Rephlux. Rephlux periodically checks out your code from CVS and runs your unit tests on it. It produces a RSS feed of test failures and a RSS feed of CVS revisions. How cool is that?

In the future it should be possible to automatically build releases and documentation when all the tests pass. Hopefully, this will help improve our record of releasing on the WACT project. With one formal release in nearly a year of active development, our record is dismal as Harry diplomatically points out.

Jon is running Rephlux remotely for WACT right now because we are having a problem getting our full test suite to run in the 8M limit that sourceforge imposes on PHP. We have 97 test cases, 541 test functions, and 1927 assertions in our test suite. This will only grow. The full test suite includes over 350 PHP files when it runs.

Since there isn’t much we can do about unincluding files to free up memory, I decided to take a look at the data that gets stored to see if there was any low hanging fruit there. I wanted to look and see if any of the code we are using keeps any data in global variables that it might be able to release when done to allow the space to be garbage collected.

So, I added a quick and dirty little hack to get an idea of the size of the various global variables that were left over after a test run.

 
    foreach (array_keys($GLOBALS) as $key) {
        echo "$key=" . strlen(serialize($GLOBALS[$key]));
    }

Most of the globals that were left over were tiny, but there was one that stood out. That was something from PEAR:

 
_PEAR_destructor_object_list=146270

Looking in to this further I found that the PEAR base class registers a rather dubious destructor for every object that inherits from it:

 
    function _PEAR() {
        if ($this->_debug) {
            printf("PEAR destructor called, class=%sn", get_class($this));
        }
    }

To support this gem, PEAR puts a reference to every object instance ever instantiated that inherits from PEAR into the global variable _PEAR_destructor_object_list. There the object stays until the deconstruction shutdown function is called. This reference prevents garbage collection of any of objects inheriting from PEAR or the memory they reference during the lifetime of the script. And it does this for no good reason at all.

I’ve expressed my opinion of pear.php before and this only reinforces it.

The only PEAR module that WACT requires is XML_HTMLSax, a handy parser for HTML with an XML parsing interface. I’ve always been a little bit uncomfortable with its dependency on pear.php and the deployment issues that this introduces into WACT. WACT also has optional components that reference other PEAR packages, such as PEAR::DB, PEAR::MDB and PEAR::MDB2. Fortunately a more typical WACT use case only instantiates a handful of PEAR objects.