The Builder is the soul of the Web Experience Factory. WEF is at heart, a code generation system, and the Builder is a discrete automation tool. A BuilderCall is a particular invocation of a builder for a particular Model.
To complete the Factory analogy, the Web Experience Factory is like a set of conveyor belts surrounded by well-programmed robots. At the start of each conveyor belt is nothing but an empty bed in which to create something (in our case, a WebApp). The conveyor belt brings the bed to each robot in turn, and each one does something to the item being constructed. At the end of the conveyor belt is a completed WebApp, with Java code, JSP code, SQL commands, connections to back ends, whatever. This is what the end-user interacts with: the finished product of the assembly line. It is not fundamentally different from any J2EE application that was hand-coded in Java and JSP, except for how it was created.
Back to the Builder: A Builder is like a type robot that could sit beside the conveyor belt and take some action. One Builder might create a JSP Page; another might put a button on a page; another might build on to a page an entire form that corresponds to a schema, while also adding some Java code that gets called when the form is submitted to the server. The point is, a builder can do anything it likes to the WebApp that is being created, including modifying things that are already there, things that were created by other Builders (robots).
The specific robot sitting next a specific assembly line with specific instructions is analogous to a BuilderCall. Here you have to imagine a grizzled old plant engineer with an unlit cigar stub in his teeth, saying to you, "Yeah, for that job, you'll want a Model XJ27, the Imported Page robot." He wheels one out and sets it beside the conveyor belt, "Here's you go, just program in right there what name you want it to use for the new page, and where it should look for the source for the original HTML and it'll do its job every time we turn on this here conveyor belt." So the concept, the design, of a Model XJ27 is the Imported Page Builder, but that particular robot sitting next to that conveyor belt with those inputs you just programmed in, that is the BuilderCall.
There are two critical pieces to a Builder, and some others that are optional but almost as important. First is the BDEF, or Builder Definition File. It is the starting point for any builder, with all the references to the other pieces of the Builder. The vast bulk of the BDEF is information that is used by the Designer, when editing a BuilderCall. (As you might guess, a BuilderCall is a call to this Builder. For example, the Page Builder is an abstract concept that embodies the idea of putting a new Page in the WebApp. The specific use of the Page Builder which creates "page1" in the WebApp this model creates is a BuilderCall, not the Builder itself.)
Inside the BDEF is the a reference to the Builder Class. This is the Java class that will be called when it is this builder's turn to operate. Every Builder must have a Builder Class. (OK, this is not strictly true, but the exception is only a distraction. Let's pretend it is.) This Builder class must implement one of a few specific interfaces -- typically WebApp Builder, WebAppControlBuilder, or PageAutomationBuilder, where each of those interfaces defines a single method called doBuilderCall. The Builder class is the programming of the robot on our assembly line.
Also inside the BDEF is a list of Builder Input Definitions. These describe for the editor how to present the inputs to this builder when the developer is editing a specific BuilderCall of this Builder. When you select a Builder from the Builder picker and you see all the inputs to fill in, that list came from the Builder Input Definitions that are part of the BDEF. (I'm not considering Builder Input Definitions to be a separate piece of a Builder because they are completely contained in the BDEF.)
While the developer is editing an instance of this Builder in the editor sometimes there are fields that need to be modified, shown, or hidden, based on values in other fields. This third part of the Builder is the Coordinator. This is another Java Class that is created whenever the developer (i.e. the person using this Builder in a Model he is working on) is editing an instance of the Builder. The Coordinator class is called when editing starts, after every change in any value, and when editing is done. It has the ability to create, delete, and modify the inputs that are visible to the developer while he is modifying the values. Almost all BDEF's declare a Coordinator, but it is not strictly required. For the analogy to the Factory, the Coordinator is the software inside the robot that runs as you enter in the values for a particular use of the robot, or for a particular BuilderCall.
The final piece of many Builders is the Base Model. This is a model which defines what other Builders will be called when this builder is invoked. All higher-level Builders, like View and Form and Data Services User Interface use this approach -- they declare an entire model that represents the functionality of that Builder. There is a process by which the Builder can specify certain values used by the base model, which is too complicated to cover here. These Builders are called Model-based Builders, and you can think of them as a huge mega-robot which contains numerous smaller robots inside it. You can program in the inputs to the mega-robot, and it will translate what you want to the inputs of all the smaller robots within it.
To recap the whole analogy:
Web Experience Factory -- A huge Factory with assembly lines beside which robots sit.
Model -- A specific assembly line, with a set of programmed robots beside it. When the assembly line is run, a complete WebApp comes out the end.
Builder -- A Model of robot, such as model XJ27, which knows how to import a page and put it in the WebApp to become a JSP page. You have an infinite number of these in the warehouse, but they don't do anything until you create a BuilderCall in a Model.
BuilderCall -- A specific robot on an assembly line, with all the inputs programmed in.
BDEF, or Builder Definition -- (leaving the analogy behind) An XML file, the core of any Builder. This is what points to all the other pieces, and also contains the Builder Input Definitions
Builder Class -- Java class that will be invoked during generation for instances of this Builder.
Builder Input Definitions -- Part of the BDEF, this describes for the editing tool (the Designer) what the developer should see when setting up the values for a BuilderCall.
Coordinator Class -- Java class that is created while a developer is editing a BuilderCall. This can show, hide, create, and destroy fields as needed.