3.5Components, templates & reuse
The essentials in 30 seconds
- Templates and internal windows remove screen duplication: a change to the template propagates to all windows that inherit from it.
- The component packages a coherent set (windows, procedures, classes, reports) to reuse it in other projects, with centralised correction.
- Version, document and keep a stable interface: a component that changes constantly weakens all the user projects.
Running mini-case — Yacine mutualises the screens of his management app
Yacine must deliver a second application to the group: user and rights management. He starts with his trading screens: five forms share the same banner, the same logo and the same buttons. He creates a window template FEN_FicheModele and makes the five forms inherit from it: a change to the banner propagates everywhere. The address input block, repeated in the order and the invoice, becomes an internal window FI_AdresseLivraison. For user management, he packages a component COMP_Utilisateurs with a stable, documented and versioned interface. He notes the reflex: template for appearance, internal window for a block, component for a shared module.
Self-contained case for this section: it returns in the course, diagram, script and 48h challenge of section 3.5.
1. Templates, internal windows, supercontrols
Reuse is the mark of the experienced developer: not rewriting what already exists. The window (or report) template defines a common presentation — banner, logo, standard buttons. Windows that inherit from it take on these elements, and a change to the template propagates to all of them. The internal window is a reusable block inserted into other windows: a customer selector or an address input written once, used everywhere. The supercontrol groups controls with their behaviour and is dropped as a single control.
2. The component, the most powerful mechanism
The component packages a set of elements — windows, procedures, classes, reports — to reuse it in other projects. Yacine develops once a module for user management or connection to a service, then integrates it into several applications. The component exposes an interface visible from the outside and hides its internal workings. The benefits are the capitalisation of know-how, centralised correction and homogeneity between applications.
3. Versions and a stable interface
A shared component requires discipline: manage versions to know which project uses which version, document its use and design a stable interface. If the interface changes constantly, all the user projects must be reworked. Before developing a building block, Yacine also checks whether it already exists in the PC SOFT library or the community. The right reflex: reuse, but without breaking the projects that depend on the module.
🔎 Concrete example — 🔎 Concrete example — From template to component
Yacine reuses at three levels in his electrical equipment management:
// Template FEN_FicheModele: banner, logo, Valider/Annuler buttons
// The windows FEN_Produit, FEN_Client, FEN_Fournisseur inherit from it.
// Internal window FI_AdresseLivraison inserted into FEN_Commande
// and FEN_Facture: a single behaviour, no copy-paste.
// Component COMP_Utilisateurs, shared with another application
COMP_Utilisateurs.OuvreFiche(UtilisateurConnecte)
SI COMP_Utilisateurs.EstAutorise("FACTURATION") ALORS
Ouvre(FEN_Facture)
FINReading: the template handles appearance, the internal window the block, the component the complete module.
Lesson: the component's interface stays stable so as not to break the user projects.
Section vocabulary
- Window template
- Model window defining a common presentation from which the application's windows inherit.
Simple example: FEN_FicheModele carries the banner and buttons of Yacine's five forms.
What it is not: a window recreated by hand for each screen.
Reflex: common appearance → a template.
- Internal window
- Reusable window inserted into other windows, with its behaviour.
Simple example: FI_AdresseLivraison is inserted into the order and the invoice.
What it is not: a block copied into each screen with its processing.
Reflex: repeated block → internal window.
- Supercontrol
- Set of grouped and reusable controls with their behaviour, droppable as a single control.
Simple example: Yacine groups the customer search controls into a supercontrol.
What it is not: separate controls dropped again in each screen.
Reflex: grouped reusable controls → supercontrol.
- Component
- Set of elements packaged to be reused in other projects, with an interface.
Simple example: COMP_Utilisateurs manages the rights in several applications of the group.
What it is not: a procedure collection limited to a single project.
Reflex: share between projects → a component.
- Stable interface
- Visible part of a component, which must remain predictable for the user projects.
Simple example: Yacine documents and versions the public methods of COMP_Utilisateurs.
What it is not: an interface modified at every delivery without notice.
Reflex: protect the user projects → stable interface.
In practice — In practice — Reuse rather than duplicate
- Create a window template with the common presentation and make your screens inherit from it, like Yacine.
- Turn a repeated block (address input, customer search) into a reusable internal window.
- For a module intended for several projects, create a component with a clear and documented interface.
- Version and document the component; check whether the building block already exists in the PC SOFT library.
Step-by-step script — mutualise like Yacine (4 min)
1) Spot the common presentation of several screens and create a window template. 2) Make the existing screens inherit from it and check that the change propagates. 3) Isolate a repeated block into an internal window with its behaviour. 4) For a module shared between projects, define a stable and documented interface. 5) Version the component and note which project uses which version.
Keep this reflex: reuse without breaking — a component's interface is changed with care.
Copy-paste template — Yacine's reuse sheet
Template : inherited common presentation (banner, buttons)
Internal window: inserted reusable block (address, search)
Supercontrol : grouped controls + behaviour
Component : module packaged for OTHER projects
Vigilance : stable interface, documentation, versionsFive identical forms
Yacine creates a template and makes the forms inherit from it: the banner is modified only once.
A repeated address
Yacine isolates the address input into an internal window used in the order and the invoice.
A multi-project module
Yacine packages the user management into a versioned component.
An interface that changes
Yacine documents and stabilises the component's interface so as not to break the other applications.
✓ Best practices
- Template for appearance, internal window for a block.
- Component for a module shared between several projects.
- Always version and document.
✗ Common pitfalls
- Recreating the same banner in each window.
- Copying a block instead of an internal window.
- Changing a component's interface without care.
Key takeaways
- Templates spread a common inherited presentation.
- Internal windows and supercontrols reuse blocks with their behaviour.
- The component packages a module for other projects.
- Version, document and keep a stable interface.
48h challenge — apply it tomorrow
Like Yacine, spot the common presentation of several windows and create a template they inherit from. Turn a repeated block (address, customer search) into an internal window. Finally, identify a module intended for several projects and describe in one sentence its stable interface, its documentation and its version policy.
- I know when to use a template, an internal window or a supercontrol.
- I distinguish a component from a procedure collection.
- I understand the importance of versions and a stable interface.
Frequently asked questions
When should you create a component rather than a simple procedure collection?
Create a component when the module must be shared between several projects and forms a coherent set with windows, reports or classes. A procedure collection is enough to organise code inside a single project. The component brings centralised correction and encapsulation, but requires designing an interface, documenting, versioning and testing.
How do you guarantee visual consistency without redoing everything by hand?
By combining three levels: the graphic charter for global styles, window templates for the common structure — banner, logo, standard buttons — and internal windows for repeated blocks. A change to the template propagates to all the windows that inherit from it. The rule is to centralise appearance rather than style each control individually.
When is a component more relevant than a procedure collection?