Application Structure
The Nexaweb platform offers you more flexibility in structuring your applications than both traditional web applications based on DHTML and JavaScript, or Java client-server applications based on AWT or Swing. The Nexaweb Platform offers a wide range of alternatives, on both the client and server-sides, for event handling, UI creation and modification, and access and presentation of data. This document describes some of the development approaches possible with Nexaweb, including under what circumstances each approach may be useful and some tips for ease of development in Nexaweb Studio.
The primary development approaches include the following:
| Approach | Description | When to Use |
| Server-side weighted | Traditional web applications. HTML and JavaScript-based application presentation layers limit the amount of application logic that can occur on the client-side. Also, in Model 2 web applications such as those based on Struts, the Model / Controller reside in the server (ActionServlet, Actions, ActionForms etc.) while the presentation layer is generated through Java Server Pages (JSP)s. | Nexaweb developers who have traditional web development background, whose application requirements include a Model 2 approach, or that are converting traditional J2EE web applications into Nexaweb applications. |
| Client-side weighted | Traditional Java client-server applications. The application layer is defined programmatically by using a UI library or framework such as AWT or Swing. | Any Nexaweb developers who have a client-server background, whose application requirements include minimal Network access or that are porting an existing client-server application. |
| Balanced | A mix of the two approaches above for a balanced or neutral Nexaweb Application. It uses client-side processing whenever network access is not required, and server-side processing when remote resources access is needed. The precise partition of the application between client and server depends on the particular circumstances of the application and your preferences. | Use this approach to develop any Nexaweb application. |
The following sections provide some guidelines for developing Nexaweb applications using the server- or client-side weighted approaches and some guidelines for using other Nexaweb technology features.
Server-Side Weighted
If you wish to develop server-side weighted Nexaweb applications whose requirements include a Model 2 approach, or to convert traditional J2EE web applications into Nexaweb applications you can use the following Nexaweb technology features:
| Nexaweb Development Feature | Description |
| Nexaweb form MCO | You can use the Nexaweb form Managed Client Object (MCO) to generate a parameterized HTTP request equivalent to the one produced by an HTML form. Traditional or pre-existing J2EE server-side mechanisms such as Servlets or JSP pages; or framework constructs such as Struts can process this request with little or no modification. |
| XUpdate statements to update presentation layer | Use XUpdate statements in JSP pages or static NXML pages to perform declarative presentation layer updates. If you generate the UI content dynamically through JSP pages, Nexaweb recommends that you define any static content in the page in a static NXML document included in the JSP page. You can then modify the static content dynamically using XUpdate statements in the JSP page itself. Structuring your application this way allows you to define the static content using the Nexaweb Studio Visual Editor. |
| Server-side UI DOM and event-handling | You can use server-side UI DOM and event-handling if needed; however, this option has a penalty in terms of server performance and loss of scalability. Nexaweb does not recommended this option for most applications. Although, a server-side weighted approach suffers in performance, this approach requires the least effort when porting an existing web application to Nexaweb. |
Client-Side Weighted
If you wish to develop client-side weighted Nexaweb applications whose requirements include minimal Network access or are porting an existing client-server application to a Nexaweb application, you can use the following Nexaweb technology features:
| Nexaweb Development Feature | Description |
| Nexaweb Foundation Classes (NFC) or Nexaweb XML APIs | You can use the Nexaweb Foundation Classes (NFC) to define and modify the UI presentation programmatically, or the Nexaweb XML APIs to do it declaratively. The advantages/disadavanages of using NFC include:
Nexaweb does not recommend mixing NFC/programmatic and XML API/declarative access to components, as this can result in conflicts and problems. |
| Client-side event handling | You can accomplish client-side event handling either:
|
| Accessing server-side resources | You can access server-side resources using the Nexaweb Client APIs including the Nexaweb Messaging Bus. Alternatively, you can use any Java Messaging or Data Access APIs directly, within the security restrictions of the Java Applet Sandbox. A client-side weighted Nexaweb application requires less network access and thus appears more responsive to a user compared with a server-side weighted application. The most extreme form of a client-side weighted Nexaweb application uses the Nexaweb desktop client. Your application deployment requirements determine whether you need to use the desktop client development option. |
Data Use in Nexaweb Applications
The Nexaweb Platform offers the following methods for accessing and presenting data in a Nexaweb application:
| Option | Description |
| Data Plugin Framework | The Data Plugin framework allows declarative data binding to NXML components. Nexaweb Studio provides extensive support for this data use method. Nexaweb recommends using this data binding mechanism in your Nexaweb applications. |
| NFC MVC Framework | You can use the NFC Model-View-Controller framework only with the NFC and cannot mix it with the Data Plugin Framework. Use this method for accessing and presenting data when developing client-side weighted Nexaweb Applications built with NFC. Nexaweb Studio provides limited support for NFC. |
| Manual data access | This approach is the most laborious method to use for your Nexaweb application to access and present data. Although Nexaweb does not recommend this method, you may find it useful when developing server-side weighted Nexaweb Applications or for porting existing Web Applications into Nexaweb. |
Extending Nexaweb With User defined Components
The Nexaweb Platform offers you the following options for extending Nexaweb by defining your own components:
| Option | Description |
| JSP custom tags | Use this method of extending Nexaweb components for integrating component-based frameworks such as JSF, that rely on HTML-rendering custom tag libraries that are connected with server-side Java components. This method renders components made of the aggregation of existing NXML, however, you can accomplish this easier using composite plug-ins. The JSP custom tags method of extending Nexaweb components is the most limited available through the Nexaweb Platform since the resulting tags work only with JSP pages. In addition, the Nexaweb Studio Visual Editor does not support JSP pages, so your custom tags get rendered only at application run-time. |
| Composite Plug-ins | You can use composite plug-ins to create new components from the aggregation of existing Nexaweb components. This approach requires the least coding. Since the composite plug-in UI is defined in a NXML page, you can use the Nexaweb Studio Visual Editor to create new components. In addition, the Nexaweb Studio palette supports plug-ins for drag and drop ease of development. |
| Java Bridge Plugins | Use Java Bridge plug-ins to re-use existing Java AWT or Swing component libraries within Nexaweb Applications, or when creating new complex custom components not easily implemented as a composite plug-in. Nexaweb Studio does not include a Swing or AWT GUI Builder; however, such plug-ins are available for Eclipse and you can use one with Nexaweb Studio. |
by Erik Abel