Application Integration Course

Follow one integration across the server and browser. Wisej.NET owns the component state, while a browser widget presents it. Keeping that boundary explicit prevents the vendor library from becoming the application’s business layer.

Distinguish the component from its widget. The component owns application state; the widget manages browser behavior. Events connect them by reporting meaningful changes, rather than copying every browser interaction back to the server.

Trace the data outward as compact JSON, then into the vendor’s options. Trace important events back to the server. This adapter boundary lets server code work with a stable contract instead of vendor-specific details.

Inspect TemperatureGauge in the designer. Value is the property the application changes; ThresholdExceeded is the event it handles. The vendor gauge stays inside this familiar Wisej.NET component interface.

Watch the server change Value and the gauge render it. At the threshold shown, one event returns with useful information. The application responds to the threshold crossing, not every visual animation frame.

Classify the gauge, editor, and grid before writing integration code. Their resource, data, and event needs differ. Comparing those needs first helps choose an integration surface that is sufficient without unnecessary complexity.

Write an architecture decision record explaining your choice. Include reuse, theming, security, and maintenance constraints. The point is to preserve the reasoning, so another developer can judge whether the choice still fits later.

Submit the diagram, comparison table, and decision record together. They should tell one consistent story: where state lives, how the widget communicates, and why the selected integration approach matches its requirements.

You now have an integration design that someone else can review. Use that shared understanding as the starting point for implementation and tests, instead of treating a working visual as the entire integration.

Prove the JavaScript behavior before wrapping it in Wisej.NET. A small isolated example helps distinguish a library or language mistake from a problem introduced by the integration itself.

Inside the vendor callback, inspect what this refers to. It may be the vendor object, which has no fireWidgetEvent method. The method is missing because the receiver is wrong, not because Wisej.NET lost the event.

Keep an explicit reference to the widget in a closure, bind the callback, or call a widget method. Each solution gives the callback a reliable route to the correct instance when the vendor invokes it.

Declare dependencies in their required order: supporting library, styles, vendor script, then initialization. Packages makes that order explicit, preventing initialization from running before its required resources exist.

Move the proven initialization into the Widget’s InitScript and declare its resources in Packages. Keep the same dependency assumptions from the isolated example, so integration does not silently change how the library starts.

Use the browser developer tools to inspect the stored vendor instance and follow valueChanged. A sourceURL gives injected code a recognizable name; a debugger statement helps stop where the callback actually runs.

Keep the isolated example, working InitScript, and debugging notes together. A future failure can then be reproduced outside the integration and compared with the actual widget setup.

The integration now has a tested starting point, explicit dependencies, and a reliable callback context. These foundations make later wrapper code easier to debug because basic JavaScript behavior is already understood.

Start with a Widget to prove the integration quickly. This gives the vendor library a place inside Wisej.NET before you invest in a reusable control with a larger public interface.

Place the Widget on the dashboard and keep the first example small. The immediate question is whether the resources load and the vendor object can run in its container, not whether the abstraction is finished.

Give Packages, Options, and InitScript separate jobs. Packages loads dependencies, Options carries the current data, and InitScript creates the visual. Keeping those roles clear makes a failed integration easier to diagnose.

Create the vendor instance during initialization, then update that existing instance when options change. Recreating it on every update can duplicate handlers or lose state that belongs to the current widget.

Use the server button to change Options and watch update refresh the visual. A queued Call handles an imperative command. Distinguish changing persistent widget state from requesting a one-time client action.

Submit the resource declarations, initialization, update logic, and server interaction together. They should demonstrate both first creation and later changes. Reuse across multiple screens is the next reason to introduce a wrapper.

The prototype has now established that the library can load, render, and respond inside Wisej.NET. Carry those proven behaviors into a reusable wrapper instead of copying the prototype onto every page.

Move repeated widget setup into a reusable class. When resource paths or initialization change, one maintained implementation should serve every screen instead of requiring edits to several copied scripts.

Let SimpleGauge inherit the Wisej.NET Widget behavior and own its Packages, Options, and InitScript. The page should ask for gauge behavior through the class, without knowing how the vendor library is assembled.

Expose Value, Minimum, Maximum, and Caption as typed properties. Descriptions and categories help the designer user choose valid settings, while the wrapper translates those settings into the vendor’s options internally.

Keep the supported properties public and hide implementation details where appropriate. If callers can replace initialization or raw options freely, they can bypass the guarantees that make the wrapper reliable.

Place the class on a demonstration page and change it through normal properties. The absence of page-specific InitScript is useful evidence: the integration knowledge really lives inside the reusable class.

Deliver the class with documented properties, defaults, and a clean example page. A reviewer should be able to instantiate it and understand the supported settings without opening the vendor initialization script.

A good wrapper makes the normal operation straightforward and accidental misuse difficult. Evaluate the public interface from the page author’s perspective, not only from the viewpoint of the person who built the integration.

Build a custom control when the integration needs to behave like part of Wisej.NET itself. The goal is a reusable component that participates in design-time behavior and theming, not just a hosted visual.

Compare a Widget wrapper with a platform-level Control. Choose the stronger integration when native behavior and theme participation justify it; extra implementation work should answer a real reuse requirement.

Pair the server SimpleGaugeControl with its client class under Platform. The two classes have different responsibilities: the server exposes application state, while the client implements how that state appears and behaves in the browser.

Use OnWebRender to build a deliberate client configuration. Include the properties needed to render the gauge, rather than serializing unrelated server objects. A small explicit boundary is easier to reason about and maintain.

Connect the appearance key to the theme definition. This lets the theme control the visual choices instead of hard-coding a separate look into every screen that uses the control.

Inspect the control in the designer and try its size and theme settings. Design-time rendering is part of the integration: other developers need to arrange the control without running the entire application first.

Submit both classes, the appearance entry, and design-time evidence. Together they demonstrate the full path from the server property to a themed control that another developer can place visually.

Watch several instances share the same control implementation on the dashboard. Their values vary, but their behavior and theme integration remain consistent. That consistency is the payoff of encapsulating the integration once.

Decide whether each interaction sends a command or needs a result. That distinction determines how server code continues, what data crosses the boundary, and whether it must await a browser response.

Use Call when the browser should perform an action and no return value is needed. The command is queued, so subsequent server code must not assume that the browser has already finished executing it.

Use CallAsync or EvalAsync when the next step depends on a browser result. Await the operation before using that result, so the workflow follows the reply instead of racing ahead with missing data.

Define a small data transfer object and check its serialized property names. The browser receives the serialized contract, not the original C# object. Explicit fields avoid exposing unrelated state and reduce naming mismatches.

Compare the live operations: a command changes the gauge, an awaited call reads its rendered size, and a compact object returns selection state. Each exchange carries only what that particular interaction requires.

Provide examples of one-way commands and awaited results, plus the return-data contract. A reviewer should be able to identify where execution waits and which fields the browser is allowed to return.

Keep the boundary organized around commands, results, and explicit data contracts. This makes timing and responsibility visible, which is more reliable than treating browser code as a synchronous extension of the server.

Treat vendor callbacks as raw input to the integration. The application needs a stable set of meaningful events, so the adapter must decide what to forward rather than exposing every vendor notification directly.

Separate visual activity from application decisions. Pointer movement or animation can remain local, while a meaningful selection or state change may need the server. Filtering at this boundary avoids unnecessary traffic and handler work.

Register the vendor callback once during initialization and forward a compact named event. Registering it again on every update can make one user action trigger multiple server handlers unexpectedly.

Use the event route that matches the integration surface. Widgets forward through fireWidgetEvent and WidgetEvent; custom controls use their client events and OnWebEvent. Mixing the routes sends data to the wrong handling mechanism.

Define each event name and payload before wiring the handlers. Threshold crossings, value changes, and point selections need different information. Small explicit contracts make it clear what a server handler can rely on.

Interact with the gauge, knob, and chart and follow the events reaching the server. Check that each payload contains the relevant values and that local visual activity has not become a stream of unnecessary server messages.

Submit paired client and server handlers with the contract table. A reviewer should be able to trace each event from its browser trigger to the server decision, including exactly which data crosses the boundary.

Some vendor widgets fetch their own data rather than receiving everything through Options. Give those requests an explicit endpoint and preserve the correct component context, so the response belongs to the intended user and widget.

Use getPostbackUrl when a widget expects a data address. It routes the request to the appropriate session and component instance. The address supplies context, but the handler must still validate the requested operation.

In WebRequest, check the requested action before producing data. Set the JSON content type and write the expected response shape. A valid transport response is not enough if the widget cannot interpret its contents.

Use a WebMethod for a typed operation your client code calls directly. Arguments and the returned value form the contract, so the caller can await a result instead of managing a widget-owned data request.

Choose the endpoint style by who initiates and controls the request. A vendor data source naturally uses its address; application code that calls a named operation benefits from a typed method and explicit result.

Follow the grid’s request to the postback handler and back to the rendered rows. Check the response structure at that boundary; a blank grid may indicate a contract mismatch even when the request itself succeeded.

Deliver both endpoint examples and explain their intended callers. Review authorization and input validation for each path. Choosing a convenient endpoint mechanism never removes the server’s responsibility to protect the operation.

Use the grid and pivot examples to identify the integration pattern beneath vendor-specific syntax. The application still needs resource loading, data operations, events, and a stable Wisej.NET interface regardless of the chosen library.

Give the adapter ownership of creation, options, events, and data access. Keeping these vendor-facing details together prevents individual pages from growing their own incompatible versions of the same integration.

Compare DataSource and CustomStore by the operations they request, not just their syntax. Both need a path to loading and changing data; the adapter translates their arguments into your server’s contract.

Define paging, sorting, and filtering in GridOperationRequest before implementing handlers. Validate those inputs on the server, then map them to the supported operation. Browser-provided query instructions are still untrusted input.

Specify separate payloads for row changes, insertion, deletion, and selection events. Each should identify the intended operation and necessary values, without sending an entire component or exposing unrelated server state.

Follow paging, sorting, and editing through the same server contract while the pivot loads its data. The common boundary keeps application operations understandable even when the browser widgets use different vendor interfaces.

Submit the operation contract, handlers, event payloads, and pivot plan as one coherent design. A reviewer should be able to connect every visible data action to an explicit, validated server operation.

Review the integration as something that must survive repeated use and deployment. A successful first render proves only one path; production readiness also depends on failure handling, updates, cleanup, and maintainable contracts.

Inspect resource paths, event volume, lifecycle cleanup, timing, and realistic data sizes. These concerns can stay hidden in a small demonstration, then become failures when the same widget is reused or deployed elsewhere.

Name injected scripts with sourceURL and fail clearly when prerequisites are missing. Compare the isolated vendor example with the integrated version. That gives you evidence about where the failure begins instead of relying on guesswork.

Update the existing vendor instance in place and destroy it when the control is disposed. Repeated create-and-close cycles should not leave handlers or objects alive after their screen has gone away.

Start the background work through Application.StartTask. When the result is ready, update the client and call Application.Update. The workflow is not complete until the browser can actually display the server’s new state.

Integrate an unfamiliar widget using the same boundaries: a reusable wrapper, server commands, a meaningful event, and a protected data endpoint. The exercise tests whether you can transfer the pattern beyond the course’s examples.

Review the dashboard as several integrations working together. Trace events, calls, loading, and disposal for each widget. Shared visual space should not blur which wrapper owns each resource and interaction.

Finish with a wrapper another developer can understand, test, and reuse. Explain its public contract and lifecycle, including failure behavior. The lasting result is a maintainable integration, not merely an impressive demonstration.