How to specialize the layout of a DetailsPage

Go with your browser to the page whose layout you want to specialize. To verify that it is produced by an instance of a subclass of PntObjectDetailsPage, view the HTML source in your browser. It should contain debug information like:

If it does not contain debug information, see How to specialize a part of a page for how to switch it on. If you have debug information, look for the class name after "in". Verify that the class inherits from class PntObjectDetailsPage. If not, this howto does not apply.

Copy the file 'skinDetailsTablePart.php' from the 'includes' folder to your application folder and rename it to 'skinDetailsTable.php', where should be replaced by the type of peanuts shown by the page. For example, if your page is showing an instance of 'Employee', rename your skin file to 'skinEmployeeDetailsTable.php'.

Edit the new skin file. Look for $this->printDetailsRows calls. Change the second parameter of each call to true. Then save the skin file.

Refresh the page in your browser. Instead of the regular properties and values you should now see something like "printFormLabel(..) printDetailsLink(..) printFormWidget(..) repeated all over your page. (If nothing happens, check the skin file name).

View the new HTML source in your browser. Look for the comments from the skin you just edited. Then copy the rows that where produced by the first $this->printDetailsRows call and paste them in the skin, replacing the first $this->printDetailsRows call and the php tags that surround it. Do the same with the second call. Then save your skin.

Refresh the page in your browser. It should now look like normal. If it does you can now modify your skin to customize the layout of the page.

Tip: You do not have to stick to the formWidget as produced by the corresponding print call. Instead you can enter your own input tag and use printFormText to print the value. See example5.

One last remark on custom details skins: They offer a lot of flexibility in user interface layout, but they fix what properties are visible and if you use custom input tags, how they are edited. In other words, your details page will no longer adapt to changes in the domain model. Therefore we advise you to first develop the domain model of your application and only start to create custom details skins when your customer is quite certain that the application contains all the data he wants to be in there. (For substantial maintenance after the details skins have been made, you may temporarily rename the details skin files so that the more adaptive default interface comes back, then change the domain model, and finally rename and maintain the skins to reflect the changes in the domain model).