- Some external agent requests a Generation of a
Model with a particular profile. Usually this is coming from a request,
because an end-user with a browser has invoked the Factory application
with his URL, or indirectly so, via the Portal framework.
- GenerationManager checks if that Model with that
profile is in the cache. If so, makes a runtime copy, puts in in the session,
and directs to the main action. If not, it starts the real generation process.
- The Model is read in and BuilderCalls are constructed
from the XML representation.
- For each BuilderCall that has any profiled values,
the BuilderInputs are cloned and updated with the correct profile values.
The BuilderCalls are put into the "Construction Phase" list.
- A GenContext is created, handed the construction
phase list, and told to get started.
- GenContext: For each phase (Construction, Post-Construction,
Modification, Validation, Process, Externalize)
- Get the BuilderCall on the top of the list for the current
- (If running inside the Designer) check that all required
BuilderInputs have values
- Invoke the doBuilderCall method of the Builder associated
with the BuilderCall, passing in
- GenContainer (the container that will hold the completed
- GenContext (i.e. itself)
- BuilderInputs (these are the potentially modified BuilderInputs)
- Note that Builders might defer themselves to a different
phase, or invoke other Builders which do.
- If the running Builder invokes another Builder (which
is does through the GenContext), the GenContext immediately creates
a new BuilderCall, puts itself into a pseudo-Generation Phase and invokes
the new BuilderCall. (Note that all Builders must run initially in a Generation
Phase, even if the only work they do there is to defer themselves to a
7. The newly constructed WebApp is saved
in the cache.
8. A runtime copy is created, put
in in the session, the main action is invoked.