Package Breakdown

The Compiled_Resource package allows one or more source code files to be compiled into executable PHP code. This package establishes a standard API for retrieving compiled resources and provides tools for managing the relationship between the source code and the compiled objects.

Add the ability for the CodeWriter to create classes, properties and methods. Need the ability to switch between scopes: global, function, class, and method so that the entire file need not be generated linearly.

The phpmodule name is confusing in context and a very artifical example. The same examples can be done using bookmarks as the domain.

FormTransition is a pre-requisite for forms support in the new controller architecture.

A bit of an MVC separation issue in the current implementation. This can be re-worked once the pager components are converted to the newer view architecture (composable templates).

View Composition is the preferred way to do page layout (versus the wrap tag) in the new controller architecture along with composable templates.

Form controls in a list. How to Validate and associate errors with the correct control?

By my estimation, the new controller architecture will make short work of wizards.

There are composition issues to work out when composition involves multiple independent modules, not strict wrapping.

The Crud Controller is a parameterizable controller component capable of easily dropping CRUD support for a Database table into an application. Uses meta data.

Data_Cache stores and retrieves a php value to various backends. It includes the capability to determine when cached data might be expired.

The current WactFileCache implementation is optimized for the unix file system. A version optimized for the windows file system should be created.

A generic WactFileCache implementation should be created that is capable of operating under either windows or unix, although possibly sub-optimally on both. This implementation should Probably be called WactFileCache and the current WactFileCache might be renamed to WactUnixFileCache.

Create a WactCacheExpirationPolicy implementation that can compare the date an item was added to the cache with the dates that its sources were last modified in order to expire changed cache items.

DB is a data base abstraction layer built in line with WACT principles.

The following test cases succeed in MySQL < 4.0. They fail in 4.1 or better.

Fail: /Library/WebServer/Documents/wact/tests/cases/db/drivers/mysql.test.php -> MySQLStatementTestCase -> testSetDecimal -> Equal expectation fails at character 15 with [1234567890123457024.00] and [1234567890123456789.01] at line [319]
Fail: /Library/WebServer/Documents/wact/tests/cases/db/drivers/mysql.test.php -> MySQLStatementTestCase -> testSetDecimal -> Equal expectation fails at character 15 with [1234567890123457024.00] and [1234567890123456789.01] at line [322]
Fail: /Library/WebServer/Documents/wact/tests/cases/db/drivers/mysql.test.php -> MySQLStatementTestCase -> testSetDecimal -> Equal expectation fails at character 15 with [1234567890123457024.00] and [1234567890123456789.01] at line [323]

Needed to support tools.

The current version of WACT will support unicode in the form of the UTF-8 character set. There are no plans to support character sets incompatible with UTF-8, or multi-lingual applications until the release of PHP 6.

What should this package look like?

The current design for FileScheme sucks. The runtime and compile time halves of this construct should be combined into a single object. An instance of that object should be used, not static calls.

Instantiating a templates directly currently represents an obstacle for supporting the composition of templates. Additionally, the FileScheme mechanism is poorly designed and poorly understood. The solution is to make the filescheme into a TemplateFactory object and use the TemplateFactory to instantiate Template objects. The following code:

$tmpl =& new Template('example.html');

Would become:

$tmpl =& $templateFactory->newTemplate('example.html');

Note that any code that instantiates a template is responsible for requiring an appropriate factory. The Template Factory instance performs the current duties of the filescheme, mapping compiled template files to source template files.

This paves the way for supporting the composition of templates and views and also for the use of the dependency injection pattern.

Add the ability for the CodeWriter to create classes, properties and methods.

Need the ability to switch between scopes: global, function, class, and method so that the entire file need not be generated linearly.

Currently, generated template code conforms to the following structure.

<?php function tpl8dee52a87b31cfcdbc54dbd2090f910e1(&$root) {
}
function tpl8dee52a87b31cfcdbc54dbd2090f910e2(&$root) {
}
$GLOBALS['TemplateRender'][$this->codefile] = 'tpl8dee52a87b31cfcdbc54dbd2090f910e1';
$GLOBALS['TemplateConstruct'][$this->codefile] = 'tpl8dee52a87b31cfcdbc54dbd2090f910e2'; ?>

To better enable template composition, This structure should be encapsulated into an object:

class tpl8dee52a87b31cfcdbc54dbd2090f910e1 extends Template {
function construct(&$root) {
}
function render(&$root) {
}
}

Before making this change, all template instantiation must be done through a factory, rather than using a constructor. (because the actually class instantiated will now be something like tpl8dee52a87b31cfcdbc54dbd2090f910e1.)

Some sort of mapping between template names and class names with probably be adopted. for example ‘test/index.html’ might become class test_index_template {}.

Currently components are accessed in the compiled templates starting at a root object.

<?php $root->children['TextConverter']->children['lower']->renderAttributes(); ?>

Once the template structure is changed from procedural to object oriented, the components should be accessed relative to the context ($this) instead of an arbitrary root. This is the change that will finally allow composable templates and template components. Generated code would then look like:

<?php $this->renderAttributes(); ?>

Any tag that does not use the getComponentRefCode() method or the getDataSourceRefCode methods will break and need to be fixed. data:table tags are known to directly reference $root and will have this problem.

<core:template> would work like <core:include>, but instead of the contents being inlined into the parent tag, the contents would be included and added to the component tree at runtime.

When templates are composable, it doesn’t make sense for the View class to be separate.

NativeView (ala TemplateView) uses the native language for templating. It supports the “PHP is the template” school of thought. NativeTemplate and TemplateView will be on equal footing and freely mixable on the same page at the conclusion of the Composable Templates project.

Widgets are WACT’s current anemic support for the NativeView style. Most current runtime components will become available for use in a NativeView.

The compiler will still use these components as base classes. (see Convert Template Structure from procedural to object oriented)

Currently global variables are used.

Currently, the template compiler requires XML style balanced tags. Support for unbalanced HTML tags should be re-introduced. Both Elements with optional closing tags and empty elements should be properly supported.

The DataSourceComponent class in template.inc.php has three deprecated methods which must be removed: set, get, and prepare. These methods are used in the test suite and some of the example code. Usually with code like this:

$tmpl =& new Template('xxx');
$tmpl->set('variable', 'yyyy');

This should be replaced by something like:

$tmpl =& new Template('xxx');
$data =& new ArrayDataSource();
$data->set('variable', 'yyyy');
$data->registerDataSource($data);

or alternatively:

$tmpl =& new Template('xxx');
$tmpl->registerDataSource(new ArrayDataSource(array('variable' => 'yyyy')));

Currently, the MISSINGENCLOSURE error is tested for on a tag by tag basis. The correct enclosure for a tag should be part of the meta data (TagInfo) for that tag. Instead of calling the CheckNestingLevel method, the compiler should check the TagInfo meta-data and perform the tests itself. This will make it easier to create tags.

Tags that require enclosure include: core:separator, page:prev, page:next, page:number, page:elipses, page:first, page:last, list:item, errorsummary, textarea, input, select

Right now, each tag checks individually for its required attributes with code such as :

$binding = $this->getAttribute('for'); 
if (empty($binding)) {
    $this->raiseCompilerError('MISSINGREQUIREATTRIBUTE', array('attribute' => 'for'));
}

The list of which attributes are required for a tag should be specified in the TagInfo for that tag and the compiler should automatically make these checks before the component is even added to the tree.

Currently, the runtime components pass all attribute values through htmlspecialchars. (see TagComponent::renderAttributes) This is not desirable in all cases, especially when attempting to use javascript in attributes. A mechanism should be added to be able to turn off the escaping for specific attributes.

Note that many times the attribute value is the same after passing through htmlspecialchars. As well, attributes of components are seldom manipulated at runtime by the user. Thus, it may be possible to optimize the output of attributes by determining at compile time which attributes would not be changed by htmlspecialchars and avoiding calling the function for those attributes as well.

There is currently a failing test case to illustrate this problem:

Fail: ./cases/template/template_attributes.test.php -> tagattributestestcase -> testjavascriptwactattribute -> Equal expectation fails at character 40 with [<P id="test" onmouseover="window.status=&#039;Test&#039;; return true">contents</P>] and [<P id="test" onmouseover="window.status='Test'; return true">contents</P>] at line [319]

This test case illustrates a problem with how CompilerProperties declare scoped variables inside the templates. This should be much easier to fix after the Template Composition tasks are completed.

Fail: ./cases/examples/tags/list/listroweven.test.php -> examplestagslistroweventestcase -> testexists -> Pattern [/<TABLE.*>\s*<TR.*bgcolor="yellow".*>\s*<TD>1<\/TD>\s*<TD.*>George<\/TD>\s*<TD.*>Washington<\/TD>\s*<\/TR>\s*<TR.*bgcolor="green".*>\s*<TD>2<\/TD>\s*<TD.*>Alexander<\/TD>\s*<TD.*>Hamilton<\/TD>\s*<\/TR>\s*<TR.*bgcolor="yellow".*>\s*<TD>3<\/TD>\s*<TD.*>Benjamin<\/TD>\s*<TD.*>Franklin<\/TD>\s*<\/TR>\s*<\/TABLE>/i] not detected in [String: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Li...] at line [30]

data:form uses DataSource meta data to automatically generate a form for a DataSource.

If required bugs aren’t fixed soon in the official release, we can fix them and release a patched version on our channel. Such is the beauty of an open source license. :)

Various cleanup is required to release the Wact Test runner as a package. Design smells caused by limitations in the PHPCoverage tool should be fixed. Any depedencies on WACT should be eliminated. Changes will be required to run in include_path. Html output could use some CSS.

The cobblers children has no shoes and the Test Runner is the largest part of WACT with no test cases.

The View package should be fully available without the rest of the framework. Currently forms rely on controllers to build their action through a transition. This needs to be extracted out somehow so that forms can still be used as runtime components but don’t depend on an underlying controller structure.

The w3c xml conformance test suite has thousands of XML test cases.

There is some Sax API organization required, as informed by failing XML conformance testings.

The current Sax parser chokes on DTDs. Code should be added to at least recognize the DTD and ignore it (rather than treat it as character data, which is current behavior.)

There will be hundreds of esoteric failing tests. Each should be either fixed or silenced as unfixable.

Create a component that listens to Sax DTD events and is able to validation the Sax Event stream based on this information.