Release notes

Version 1.4.beta2

This version does not include the examples. It is meant to run on both php4 and php5. Click here to try it out.

This version does not include pntUnit. For security reasons the framework will no longer be shipped together with development tools like pnt/unit. Please visit the Forum if you want pntUnit to be made available as a seperate download.

What's new

Since 1.4.beta1

• Support for AJAX. This updates DOM elements in pages without refreshing the rest of the page. For this clientside javascript functions are added that can be used by the application developer. Serverside default Page classes now do special handling of AJAX requests to send updates of user interface Parts as XML. Several elements can be updated in a single request.

Since 1.3.0

• Support of User authorization on application and type level
• User administration and authentication plugin avaliable (separate download)
• Cross site scripting and request forgery prevention
• Support for SqlLite database
• DAO class that can be subclassed to support other databases
• Support for other databases through PDO interface
• Uses Database transactions
• Cascaded delete and protection against delete if dependents exist
• better defaults for label and labelSort
• no longer shows both MtoNDialogWidget and button for same multi value propery
• some refactoring and small changes, see changes.txt.

Remarks for upgrading existing applications

• To prevent cross site scripting, all request parameters are now sanitized, i.e. stripped from HTML tags. This includes data processed by PntObjectSaveAction to be stored into the database. If you do not like this, you can override PntSite::sanitize on Site called for all request parameters, override PntRequestHandler::getReqParam on SaveAction for specific parameters, or override PntRequestHandler::getFormTexts on SaveAction for all data processed by PntObjectSaveAction to be stored into the database.
• For the same reason PntFilterFormPart now only includes extra form parameters in the form if explicitly included in the result of getExtraFormParameterKeys
• To prevent cross site scripting you are advised to check your applications on the output of data that may come from the request and encode it before/when it is printed (For convenience PntRequestHandler::htOut was added, it encodes (htm_enities) and prints).
• Because of the use of database transactions handleRequest on PntAction subclasses has been refactored. If you have overridden this method you will probably have to upgrade your overrides.
• Some class includes have been moved from PntSite::createObjects to PntSite::importLibraries. If you have overridden these methods you may have to adapt your overrides.
• To avoid any more changes made to the database after a database transaction rollback, PntAction subclasses now dies on any error events that are reported (i.e. bring forward the ErrorPage in production). These normally include Warnings.
• If you want to use authentication you are advised to check all your application code that sends data to the browser to properly encode (html_entities) any data that at some point may have originated from request data. This includes but is not limited to data that was saved into the database.
• If you want to use authorization and have overridden ::handleRequest you may have to add calls to ::checkAccess. See the implementations of ::handleRequest on pnt subclasses of PntRequestHandler.
• If you want to use cascaded deletes and protection against delete if dependents exist, you not only need to add ::setOnDelete calls to ::initPropertyDescriptors but also remove your ::getDeleteErrorMessages methods or adapt them to call parent::getDeleteErrorMessages. If you have overridden PntDbObject::delete you may have to adapt your overrides, see how it works in PntDbObject::delete and the implementation of the methods it calls.

Portablility

This version is meant to run on both php4 and php5, the last with zend.ze1_compatibility_mode = On as well as Off. On php5 the code will not be free of E_STRICT notifications.

If you want your application code to be portable too it has to follow certain rules:

• only use php4 syntax, keywords and functions,
• allways assign or pass objects by explicit variable reference (&),
• use the functions from classes/pnt/php4Functions.php and php5Functions.php where applicable,
• don't change the zend.ze1 compatibilty mode after php5Functions.php has been included, it will not dynamically adapt to such a change.

Like phpPeanuts, code that follows these rules should be able to run with equal behavior without modification on both platforms, and on php5 with both zend.ze1 compatibility settings. However, there may still be differences in areas of php that phpPeanuts does not use. This may require some further wrapper functions to be added.

For object oriented application frameworks like phpPeanuts php5 is a much better platform than php4. However, some people are still using php4 as their deployment platform because some website hosting accounts do not yet support php5. PhpPeanuts versions 1.x will be compatible with php4. Next major version of phpPeanuts will be for php5 only.

Known bugs and limitations

1. With php 4.4 and 5.2.0 (documentation suggests the same will happen with 5.1) phpPeanuts still triggers some notifications "Only variable references should be returned by reference": When a function that returns a PntError it is not first put into a variable. As this kind of error handling is not perfornance-critical we do not consider these notifications enough of a problem to delay this release.
2. Column mappings may not be consequently applied. If you need to set a columnName different to the propertyName on an PropertyDescriptor, test your applications database persistence functionality thouroughly. (we don't use this feature ourselves. If someone is using it, please report on how it works and on bugs, otherwise this may never be resolved).
3. Reference Anomalies: Before the generic workaround was applied (introduced in 1.1 beta 1, released dd 16-11-2004), use of references by phpPeanuts occasionally made uninitialized php variables or associations arbitrarily hold values that seemed to come from another variable. This rarily happened and since the generic workaround it did not happen again until the changes where made to get rid of reference notifications. Do not use phpPeanuts for mission critical applications.
4. Though the framework has DAO classes that are successfully used as the database abstraction layer with MySQL and SqLite, the use with other databases may require some additional refactoring. Please inform us about eventual problems and solutions with the use of other databases. (Known: Oracle versions below 9 do not support standard explicit JOIN syntax, but producing JOIN instuctions is not delegated to DAO objects and can not be easily refactored to do so.)
5. produces E_STRICT notifications on php5 (see under portability).