Portlet Factory can bring out the best and the worst in developers. When initially presented with the tool my experience has been that most traditional developers, especially those coming from a pure Open Source based background, respond with open and voacl vehemence. The argument being that they can produce the same code using tools like spring, hibernate, JSF etc, in less time and they are not constrained by the tool. This argument initially stands, as to gain efficiency within Portlet Factory can take a bit of time and even a bit of a thought process change in the way you approach your development. And it may be this last point that is the true cause for the aversion that some developers have when told they have to start developing in the tool.
The thought change that I believe you have to make to be a successful developer within Portlet Factory is to truly understand the idea of pattern based development. Rather than coding a specific control on a page, wiring to a bean or object that represents the control, followed by coding logic for that event, Portlet Factory allows you to consider the transaction as a whole or as a common pattern. Rather than applying a UI component and a back end component, you should instead think of the behavior you are trying to accomplish and apply the right builders to accomplish the behavior. Builders by their nature manage code in the front and back ends at the same time, therefore elevating the developer from needing to describe all the finer detail that makes their communication possible. The detail will have been taken care of by the guy that wrote the builder in the first place. This means all you need to deal with are variables in XML format and how to manipulate them.
The DataPage builder is probably the most commonly used builder in the pack and demonstrates this behavior well. To have generate an input screen with multiple fields and all the back end wiring performed for you in minutes you need only create a single XSD schema. This immediately aligns you with the data you are working with, rather than the controls on the screen. The DataPage builder will interrogate the schema create input fields to match, create a variable on the back end to represent the data and wire all the form submission together without writing a single line. What this builder does is capture the pattern of data entry. This is good for about 90% of the time, as generally you will want to work in this. That being said no common pattern will ever cover 100% of application variations. This is where customization is required and is often what leads people to dismiss PortletFactory. The claim being that it requires longer to build the customizations than it would to just use traditional java libraries and open source components. Its an argument that I have been presented with many times. however the truth is that PortletFactory does not stop you from creating your customization using any library you wish as at the end of the day it is still only generating JSPs and Java. Secondly creating custom Java Objects or custom Builders is comparable to creating a JSF control or JSP tag. The benefit however lies is that you can do a lot more in a custom builder than you could when writing a tag or JSF control. A custom builder can put a control on the screen, automatically generate variables and logic, even log messages and call back in services all transparently and without developer intervention. If you can describe a pattern of behavior or standard way of interacting with the system that is common within a project or an organization, you can create a builder to generate the code for that pattern. This removes the need for developers to recreate that pattern multiple times and also the risk that the same pattern is implemented in many ways across a project by different developers.
On the many PortletFactory based projects that I have now worked on, we have always created custom builders. They may capture a common way of logging to back end servers, or ensuring that all error messages are displayed using the standard styling and logos for a company. There are always usage patterns that repeat themselves on every project. By capturing those patterns in a builder, even if they are only for a specific project, removes the need for every developer to code and wire components together in the same way each time.