You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
Version 1
Current »
<ac:layout><ac:layout-section ac:type="single"><ac:layout-cell><p>Per-flavor execution contract for the four predefined script tasks.</p><p><strong><ac:link><ri:page ri:content-title="Technical Reference" /><ac:plain-text-link-body><![CDATA[Reference]]></ac:plain-text-link-body></ac:link></strong> → <strong><ac:link><ri:page ri:content-title="Platform Modules Reference" /><ac:plain-text-link-body><![CDATA[Modules]]></ac:plain-text-link-body></ac:link></strong> → <strong><ac:link><ri:page ri:content-title="Scripts Module Reference" /><ac:plain-text-link-body><![CDATA[Scripts]]></ac:plain-text-link-body></ac:link></strong> → <strong><ac:link><ri:page ri:content-title="Scripts Tasks Reference" /><ac:plain-text-link-body><![CDATA[Tasks]]></ac:plain-text-link-body></ac:link></strong> → Client Lifecycle Matrix</p><hr /><ac:structured-macro ac:name="info" ac:schema-version="1"><ac:rich-text-body><p><strong>10.1.5 DRAFT.</strong> Preview content for the FrameworX 10.1.5 release. The parent page will be updated to incorporate this matrix at release time. See TDEV-1325.</p></ac:rich-text-body></ac:structured-macro><h2>Lifecycle Matrix</h2><p>FrameworX has four predefined script tasks that fire on platform lifecycle events. Each task has a fixed execution surface depending on which client flavor is connecting:</p><table class="wrapped"><tbody><tr><th><p>Predefined Task</p></th><th><p>WPF rich client</p></th><th><p>HTML5 / web client</p></th><th><p>Notes</p></th></tr><tr><td><p><strong>ServerStartup</strong></p></td><td><p>n/a</p></td><td><p>n/a</p></td><td><p>Runs on the server (TServer.exe) at solution start, before any client connects.</p></td></tr><tr><td><p><strong>ServerShutdown</strong></p></td><td><p>n/a</p></td><td><p>n/a</p></td><td><p>Runs on the server at solution stop. Reliable — server shutdown is graceful.</p></td></tr><tr><td><p><strong>ClientStartup</strong></p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Runs once per client at session connect, on the client process. New in 10.1.5: the HTML5 / WebAssembly client now executes this task too. WPF behavior unchanged.</p></td></tr><tr><td><p><strong>ClientShutdown</strong></p></td><td><p>Yes</p></td><td><p>No (by design)</p></td><td><p>Runs at client close. Browser tab close gives the HTML5 client no reliable shutdown window — tab kill, browser kill, navigation away, OS eviction on mobile, and device sleep all skip the unload phase. Wiring an unreliable hook would lie to script authors about determinism, so the platform deliberately does not invoke ClientShutdown on the web client.</p></td></tr></tbody></table><h2>Designing for Web Compatibility</h2><h3>If you need teardown logic to fire reliably on web</h3><p>Use the <strong>ServerShutdown</strong> task or a Server-domain script class instead. The server detects client disconnects and can perform any must-finish work centrally — saving state, releasing resources, persisting a session record.</p><h3>If a ClientShutdown task body is non-empty in a web-targeted solution</h3><p>The Designer's Build & Publish dialog emits a one-line info note in the build log (10.1.5 and later) so authors who copy a WPF solution to web don't silently lose teardown logic. Read it before you ship the web build.</p><h3>API surface for ClientStartup on web</h3><p>Client-domain task code is compiled twice — once for the rich-client target (.NET Framework 4.8) and once for the web target (WebAssembly-safe surface). WPF-only APIs (<code>System.Windows.MessageBox.Show</code>, <code>System.Diagnostics.Process.Start</code>, file-system access, registry, etc.) fail at <em>publish</em> time, not at runtime. A clean web publish is the contract that the script will run.</p><h2>Background</h2><p>The decision to make ClientShutdown rich-client-only on the web reflects a deliberate platform stance: contracts that can fire unreliably are worse than contracts that don't fire at all. A "best-effort" ClientShutdown would silently skip in the most common shutdown paths a real user creates (closing the browser, switching tabs aggressively, OS evicting a backgrounded tab on mobile), and any code written under the assumption that it runs would be subtly incorrect.</p><p>By contrast, the WPF rich client closes through a graceful <code>MainWindow.Closing</code> path that the platform can hook synchronously, so ClientShutdown fires deterministically there.</p><hr /><h4>In this section...</h4><p><ac:structured-macro ac:name="pagetree" ac:schema-version="1"><ac:parameter ac:name="root"><ac:link><ri:page ri:content-title="@parent" /></ac:link></ac:parameter></ac:structured-macro></p><hr /> </ac:layout-cell></ac:layout-section></ac:layout>