Release notes

Version 1.2.0a

This version does not include the examples. It is meant to run on both php4 and php5.

What's new

Since phpPeanuts 1.3.beta1

• pntUnit/Inspect.php include exploit fixed

Since phpPeanuts 1.2 beta 1:

• bug fixed: incorrect conversion to html if SaveAction validation fails. If your existing application works with objects from pnt.web.dom you may need to adapt it.
• some refactoring and small changes, see changes.txt.

Since phpPeanuts 1.2 alpha 2:

• addDbFieldProps adds field properties from database column specs
• some refactoring and small changes, see changes.txt.

Since phpPeanuts 1.2 alpha 1:

• EditDetailsPage shows * for cumpulsory fields instead of links to twin propertyPages
• in pnt/unit E_STRICT notifications can be selected to be shown or hidden
• readOnly persistent fieldProperties support (usefull with calculated columns and updatable views)
• examples updated and debugged for 1.2
• many more smaller improvements, see changes.txt.

Since phpPeanuts 1.1:

• this version is meant to run on both php4 and php5, see below under "Portability".
• problems of the default design with unnecessary scroll bars in FireFox are mostly solved
• nested context tracking (scouting) trough session not only allows return to the context of the context - as many levels deep as you like -, but also makes it possible to return to the exact context, with the proper search criteria and paging. The result is a big improvement in user-friendlyness of the user interface. For more information see class pnt.web.helpers.PntSessionBasedScout
• PntErrorHandler now prints backtrace in application pages on development server. It is now activated by default.
• After saving from editing an object, for example with an EditDetailsPage, PntObjectSaveAction now by default returns to the context on success.
• support for N to M relations in the user interface, see example13 (included in this release)
• delete and onUnload confirmation in EditDetailsPage,
• properties can be set invisible, so that they will not show up in EditDetailsPage or no multi value property buttons will show up for them
• SelectionReportPage supports printing all rows; paged search results can be reported on all at once by pressing 'report' button if no rows selected.
• advanced search in SearchPage and Dialog supports combining search criteria through AND and OR.
• multi value property values caching (can substantially improve performance).
• many more smaller improvements, see changes.txt

Some of these changes will require some work on existing application code to work correctly with version 1.2:

• Context Scouting: you have to adapt existing application code to include certain parameters in url's and forms to make it work correctly
• Site::setErrorHandler sets developmentHost: You need to set this to your own development host name otherwise you get an uninformative error page meant for end users. If you do set it right, you will get a walkback printed if an error occurs on your development host
• multi value property caching may cause your existing application code to 'miss' values due to not resetting the arrays retrieved from multi value properties. Allways reset an array before using functions that use the internal array pointer (while, foreach, array_walk) on it, unless you are absolutely sure where the array's internal poiter is pointing to!
• Making EditDetailsPage ready for the use of Tabs with NtoMPropertyParts made some skin refactoring necessary. You may have to do the same with your own layout if you want to use NtoMPropertyParts.
• Improving the default layout for FireFox has caused changes in the skins that you may need to incorporate in your own skins manually.
• if you want the old behavior from ObjectSaveAction, uncomment its method finishSuccess
• please read changes.txt carefully looking for more possible upgrade issues.

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 portable, 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 where phpPeanuts does not make use of. 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, many people are still using php4 as their deployment platform because many website hosting accounts do not yet support php5. Therefore phpPeanuts will remain 'portable' as long as there is no insight into when common website hosting accounts will support php5.

Known bugs and limitations

1. 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).
2. 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 never happend again, so we recon this issue closed. However, it is impossible to guarantee that the problem has been eliminated once and for all. Do not use phpPeanuts for mission critical applications.
3. Though the framework has a class that is pointed to become the database abstraction layer, there is still quite some code that does not delegate to this layer, but will clearly have to delegate if phpPeanuts has to work on Oracle.
4. Testing with php 4.4 shows phpPeanuts triggers many notifications. PhpPeanuts intensively uses variable references. Some form of reference usage triggers notifications in php 4.4 where it did not in 4.3 and 5.0. With respect to references it is like php has broken with the principle of automatic type conversion: whenever a value has to be converted to a reference automatically, notifications are triggered. As a result all conversions have to be made explicit in all phpPeanuts code. Becuase we do currently not have the time to do all the work and testing to get rid of the notifications, phpPeanuts 1.2.0 is released without further testing on php 4.4. We plan to make phpPeanuts 1.2.1 php 4.4 compliant.