5.1WebDev: websites & web applications
The essentials in 30 seconds
- WEBDEV shares WLangage, the analysis and the editors with WinDev: Yacine reuses his customers/items/orders model for a web portal, without starting from scratch.
- The browser displays, the server processes: server code accesses HFSQL and carries security; browser code is visible and modifiable, therefore never a protection.
- The web adds its own notions: sessions, responsive design, HTTPS hosting and public exposure — familiar syntax does not exempt you from learning the web model.
Running mini-case — Yacine opens a web portal for the SME's customers
Yacine develops the management application for an electrical equipment trading SME in Oran: customers, items, orders, invoices and stock. The sales reps want to check stock and enter an order from a browser, including at the customer's premises. Yacine opens a WEBDEV project and shares the existing analysis: the Customer, Item and Order files are the same as in WinDev. He places the checks on stock, price and rights on the server side, because the browser must never decide a price. He adds a responsive page for phone and tablet, a session to identify the sales rep, and plans hosting with an HTTPS certificate. He then verifies that a hand-crafted request can neither change a price nor order an out-of-stock item.
Standalone case for this section: it returns in the course, the diagram, the code and the 48h challenge of section 5.1.
1. Capitalize without copying
WEBDEV is the member of the PC SOFT range dedicated to the web: websites, intranets and web applications. Its main interest is capitalization: same WLangage, same analysis, same editors and same project logic. Yacine shares the analysis of his management application with the web portal: the Customer, Item, Order and Stock files are not copied, they are shared. Business procedures and some components are also reused. A WinDev developer is therefore not a beginner on the web: they discover a platform while keeping their data model and their language.
2. Server and browser
The web works client/server by nature: the browser displays, the server processes. WEBDEV distinguishes code executed on the server side (secure, with access to HFSQL data) from code executed on the browser side (fast, but visible and modifiable by the user). Absolute consequence: a price, stock or rights check placed only in the browser can be bypassed. The user can even send a request directly to the server, without going through Yacine's pages. Every validation that matters is redone on the server side. Browser code is for convenience, never for security.
3. Sessions, responsive design and hosting
The web is stateless: you must manage a session to recognize the sales rep from one page to the next. Responsive design is anticipated from the design stage (layouts, zoning) to adapt to computer, tablet and phone. Hosting requires a WEBDEV application server, a domain name and an HTTPS certificate. Finally, a public site is exposed: injections, session hijacking and automated attacks make security more critical than internally. Yacine therefore tests the portal on several screens and checks rights on the server side before any go-live.
🔎 Concrete example — 🔎 Concrete example — Validating an order on the server
Yacine rejects an order line forged from the browser:
// Code SERVEUR — contrôle d'une ligne de commande WebDev
PROCEDURE ValiderLigneCommande(Ligne est une LigneCommande) : booléen
SI Ligne.Quantite <= 0 ALORS
Erreur("Quantité invalide")
RENVOYER Faux
FIN
SI Ligne.PrixUnitaireHT < PrixCatalogue(Ligne.CodeArticle) ALORS
Erreur("Prix inférieur au catalogue")
RENVOYER Faux
FIN
SI StockDisponible(Ligne.CodeArticle) < Ligne.Quantite ALORS
Erreur("Stock insuffisant")
RENVOYER Faux
FIN
RENVOYER VraiResult: a hand-crafted request is rejected by the server, even if the page has been modified.
Reflex: every check that matters is redone on the server side, never only in the browser.
Section vocabulary
- WEBDEV
- Member of the PC SOFT range dedicated to the web (websites, intranets, web applications), sharing WLangage and the analysis with WinDev.
Simple example: Yacine opens a WEBDEV project for his SME's customer portal.
What it is not: believing you have to learn another language.
Reflex: WEBDEV = same WLangage, another platform.
- Capitalization
- Reuse of WinDev assets (analysis, WLangage, procedures, components) in a WEBDEV project.
Simple example: Yacine shares the Customer/Item/Order analysis with the portal.
What it is not: recreating a second database for the web.
Reflex: capitalize = a single data model.
- Server code
- Code executed on the web server, secure, with access to data and business checks.
Simple example: Yacine checks the catalogue price and available stock there.
What it is not: entrusting validation to the displayed page.
Reflex: server = decision and security.
- Browser code
- Code executed in the user's browser: visible, modifiable, useful for convenience only.
Simple example: Yacine displays an invalid-entry message there.
What it is not: placing a price or rights check there.
Reflex: browser = display, never protection.
- Web session
- Context kept on the server side to recognize a user from one page to the next.
Simple example: Yacine remembers the logged-in sales rep throughout their order.
What it is not: believing the web keeps context by itself.
Reflex: session = controlled identity and context.
In practice — In practice — Opening a web portal with WEBDEV
- Identify what you capitalize on (analysis, WLangage, procedures, components) and what is new (web model, sessions, responsive design).
- Create the WEBDEV project by sharing the WinDev analysis, then design the stock consultation and order entry pages.
- Systematically place price, stock and rights validations in server code; keep the browser for display and convenience.
- Plan responsive design, HTTPS hosting and a sales session, then test a hand-crafted request.
Step-by-step script — securing the customer login (10 min)
Yacine sets up the sales rep's session before displaying the dashboard.
The session is created on the server side; the browser only receives a session identifier, never the password.
Copy-paste template — my WEBDEV portal
// Projet WEBDEV — portail de gestion Yacine
// Analyse partagée : Client, Article, Commande, Facture, Stock
// Pages : PAGE_Connexion, PAGE_Stock, PAGE_Commande
// Contrôles SERVEUR : prix catalogue, stock, droits du commercial
// Session : gsCommercialConnecte (côté serveur)
// Responsive : dispositions téléphone / tablette
// Hébergement : serveur WEBDEV + domaine + HTTPSCustomer portal
Yacine lets his customers check stock and the status of their orders from a browser.
Sales intranet
Yacine reserves order entry for sales reps identified by a session.
Ordering on mobile web
Yacine makes the pages responsive so orders can be placed from a phone at the customer's premises.
Shared analysis
Yacine keeps a single analysis between the WinDev application and the WEBDEV portal.
✓ Best practices
- Capitalize on the analysis and WLangage rather than copying.
- Put every critical validation on the server side.
- Think about sessions, responsive design and HTTPS from the design stage.
✗ Common pitfalls
- Placing a price or rights check in the browser.
- Believing the web keeps context without a session.
- Handling hosting and security after go-live.
Key takeaways
- WEBDEV shares WLangage, the analysis and the editors with WinDev.
- The browser displays and the server processes: security is on the server side.
- The web imposes sessions, responsive design and HTTPS hosting.
- A public site is exposed: familiar syntax does not exempt you from the web model.
48h challenge — apply it tomorrow
Like Yacine, open a small WEBDEV project sharing an existing analysis (customers, items, orders). Create a consultation page and an entry page, then place a price and stock check on the server side. Test a hand-crafted request and verify that it is refused. Note what you reused and what was genuinely new.
- I can explain what WEBDEV reuses from WinDev.
- I can distinguish server code from browser code.
- I know why and how to validate an order on the server side.
Frequently asked questions
Can a WinDev developer move to WEBDEV easily?
The transition is made easier by the same WLangage, the same analysis and the same editors, but it is not immediate: you have to learn the web model. What transfers directly: the language, the data model, HFSQL and SQL functions, procedures, components and concepts. What must be learned: server/browser architecture, server-side security, sessions, responsive design, hosting (server, domain, HTTPS), performance and search engine optimization. Yacine reuses his management analysis but rethinks the way pages load and the way rights are checked.
Why should you never do a security check in the browser?
Because everything that runs in the browser is under the user's control: they can read the code, modify it, disable it or send a request directly to the server without going through the pages. A browser-side check is therefore a usability convenience, never a protection. If Yacine checks a price only in the page, a user can send a price below the catalogue. The absolute rule: every validation that matters (price, stock, rights, amounts, identifiers) is redone on the server side, without exception.
Where should stock be checked before saving a WEBDEV order?