The technique for getting your custom layout into the model is out of date. There is now (as of Portlet Factory 6.1.5) a new builder that implements this functionality: HTML Data Layout Builder. You can just right click the element for which you want to hand-edit the HTML, choose Export HTML for Data Layout, and the Designer will create an HTML Data Layout builder for you and set it up with a new file that contains the contents of the current layout.
The IBM® WebSphere® Portlet Factory's PageAutomation system does a reasonably good job of laying out most data. This is because the best layout for data is usually a straightforward, familiar table or detail views. However, sometimes you want to have a custom layout for an entire page of data, or for part of a page.
Custom Layout for an entire page.
This example is not the best technique for providing a custom layout for an entire page. When you want to control the entire page, the best approach is to export the page (in the Data Page Builder or the View and Form Builder), edit the page, and then change your Imported Page Builder to import your new hand-edited one.
Custom Layout for a portion of the page.
One problem with exporting and importing the entire page is that you are now locked into hand-editing the entire page. Even if fields change that have nothing to do with the portion you wanted to manage, you still have to support those changes by hand. What is wanted is a way to hand-edit just a portion of the page, such that the rest of the page continues to be controlled by PageAutomation. (In this sample we do not include any additional data outside of that which is customized, just to keep it simpler.)
Below are the two pages that you will see when you run the sample. The first is using the HTML Template gridtable.html. The second is using the HTML template custom1.html. This started as a copy of gridtable but it has a section added to customize the look of the "Row" element on this page.
How it Works
This uses a feature in the PageAutomation system and HTML Templates in which you can specify a specific layout for an element, referring to it by name. An HTML Template is just a set of snippets of HTML which define for the PageAutomation System the right HTML to use for different arrangements of data. The PageAutomation System will work through all the types of data that it expects to see (as defined by the schema) and will snap together these different snippets of HTML, just like LegoTM blocks.
In all HTML Templates, the individual snippets (or "constructs" that are defined can be overridden in a variety of different ways. The most specialized way to override a construct is to append the construct name with "ByName_" and the name of the element for which you want to use it.
There is a special feature when a Group (either a Data Entry Group or a Display Group) is overridden "ByName:" The children of that group will get matched up with the new contents by name, if possible. This allows you to make a custom layout for an entire group, just by defining the layout for the head of the group. If the fields you want to manage by hand are only part of a group, you can use a Data Hierarchy Modifier to make a sub-group that contains only those fields.
In this case, I knew that the data I wanted to hand-code the look for was all the children of the "Row" element. They are Make, Model, Year, Color, and Mileage. So I created a new construct "DisplayGroupByName_Row," which is a specialization of the "DisplayGroup" construct. Since it is a "ByName" specialization, I know that it will first try to match all the children by name before it builds new constructs for them. (It would otherwise build DisplayField constructs for each of them.)
If the fields you want to manage by hand are only part of a group, you can use a Data Hierarchy Modifier to make a sub-group that contains only those fields.
By looking at the existing DisplayGroup constructs, I knew that I would have to start my DisplayGroup with a TR tag. (No doubt the PageAutomation system will be putting DisplayGroups inside of a TABLE tag.) So it is important for my DisplayGroup construct also to start that way. I also know that the standard layout includes two columns, but I want my new layout just to span the table, so I will add a colspan=2 to the TD tag. Finally within a space I can call my own, I add the HTML for the layout of these fields, as I want them.
Just because the PageAutomation system will insist on looking for it, I have added an element with the name "DataContainer," which is where the system would put the DisplayField constructs for any fields I haven't accounted for. However, since I have accounted for them all, I know that nothing will end up here.
Finally, I changed my Data Page Builder to use my new template.
Notes on running the sample and prerequisites
Import the attached zip file into your project using the Import WebSphere Portlet Factory Archive command.
The next step after this is to use this custom layout as a thumbnail view of a row of data, and to present these thumbnails in three columns. See the sample IBM - Columns of Thumbnails which does exactly this.
To learn more about HTML Templates, see Introducing WebSphere Portlet Factory HTML Templates