Skip to end of metadata
Go to start of metadata

Introduction

One of the key technical decisions we'll have to make for the CollectionSpace application is the choice of a server-side presentation framework. There are a wide variety of these technologies across a range of programming language, but in general the goals of a successful presentation framework include:

  • Rendering of templates and data into HTML markup
  • Providing clean separation of model and service code from the behaviour of rendering views
  • Organizing the request/response lifecycle, including validation of user input
  • Management of URL space: organizing application functionality into meaningful, bookmarkable URLs
  • Responding to service requests: RESTful calls from Ajax clients

Component Frameworks vs. Request/Response MVC

There are two dominant paradigms for presentation frameworks on the server side: component-based and request/response. Both offer their own unique strengths and weaknesses, and choosing between them is not always clear-cut.

Request/response frameworks tend to provide less abstraction, choosing to directly model the Web's natural request and response lifecycle. Often they also provide a thin Model-View-Controller layer on top of this, allowing Controllers to process requests and forward to a View in order to generate the response. The canonical, though deeply flawed, framework of this style is Struts. Spring MVC, Rails, and others provide modern approaches to the request/response style.

Component-based frameworks provide the application with additional abstraction beyond the mechanics of HTTP. The goal here is to encourage developers to factor their code into reusable modules that are less concerned with the details of request processing, and more concerned with actually doing real business logic. Good component-based framework should handle the repetitive glue code typical of most web application for free.

Both approaches generally follow a Model-View-Controller design. The real difference involves the controller layer: how much abstraction do you need from the details of request/response processing? In either case, applications should be built substantially in the service and business object layers of the Model, where absolutely no Web-processing logic should intrude. Similarly, View code should be concerned with the work of rendering user interfaces, not business logic or the mechanics of delivery.

Criteria for Selecting a Framework

URL Space Management

  • Bookmarkability
    • Framework should encourage light or nonexistent server-side state
    • Built-in support for GET after POST and other common idioms
  • Meaningful URLs
    • Users and Web services should be able to "intuit" the URL scheme for an application
    • URLs should clearly represent the content of the application. For example:
  • Stable, reliable back button support

Templating

  • Unobtrusive templates: non-coders should be able to rework the markup without breaking programmatic logic
  • Simple previewability: it should be easy to see the effect a template will have when rendered
  • Simple, built-in localization: easy access to message bundles
  • Templates should be easy to skin and change based on need for different look and feel, branding, etc.

Architecture and Reuse

  • Framework should reduce the need to write glue code: controllers are the least reusable part of the MVC triad, so they should be minimal.
  • Easy data binding: path-based support for connecting templates with model objects
  • Minimal or no requirement to extend framework base classes in order to participating in the rendering life cycle: pure data objects, not proprietary controllers

Relationship to the Client-Side

Rich Web 2.0-style user interfaces are becoming increasingly popular, and provide an opportunity to significantly improve the responsiveness, efficiency, and "user delight" of an application. On the other hand, client-side development presents new architectural challenges, requiring careful consideration of the roles and responsibilities for client and server.

The Fluid Infusion framework and components will provide us with a solid basis for creating rich, easily customized user interfaces running on the client side. While they can be used in fully client-side environments, Fluid components are optimally designed to cooperate with a RESTful, markup-producing server. This is because Ajax performance is usually best when markup generation and workflow is shared across both the server and the client.

The server will generally be responsible for rendering the initial page view, providing a skeletal UI structure and overall layout, which will then be further enhanced and decorated by Fluid Infusion running inside the browser. The client-side will host Fluid components that enable rich interactions built on top of the markup foundation provided by the server.

Common logic, such as validation and workflow management, will be strategically partitioned between client and server. We will establish a shared data validation protocol so that validation can be performed both on the client and server. Similarly, workflow responsibilities will occur both on the server and client. The server will establish the "macro" structure for application navigation, while client-side components will control the flow of interaction for particular activities. An Ajax bus will be created to facilitate the conversation between Fluid Infusion on the client and our UI layer on the server.Colin

More on Server and Client Side Issues

Performance and responsiveness tend to be the major issues for a new projects considering the client/server divide. The greatest latency in well-written web applications is network latency. This makes the request/response cycle the crucial cost in determining performance and response.

Responsiveness is not only important for experience-affect and productivity, but also for maintaining many interaction metaphors, for which delay can seriously impede ability. (Think of a car steering wheel with a built in half second delay). Interactions such as drag-drop, and so on, are only practical if responsive. As events and actions are both client side, with minimal server input (for example, database interaction), they are only practical on a client side.

By contrast, the web was not initially designed for heavy client-sides, and this evidences itself in a number of ways which affect performance and response. Client side work is restricted to a single, challenging language, which has a number of compatibility concerns (now often alleviated by javascript libraries); a browser is sometimes rather dim about the order in which it requests data from the server, meaning scripts can be slow to load and start; scripts typically run more slowly on a like-for-like basis than the equivalent on the server-side; the client/server pipe tends to be poorly managed with a much higher overhead than internal data transfer; the client side has no direct access to communal data or the massive datasets held on the server; nor to operation synchronisation; nor does it run in a trusted environment (trusted by the providers of the service).

These issues mean that it makes sense, if possible, to approach the client/server distinction tactically, on a case-by-case basis, rather than have it determined by a framework, which suggests a framework that is at least slightly agnostic about where abstractions fit within the client/server distinction. Dan

The Tension Between Structure and Approachability

We have to balance two primary factors when choosing a UI framework: simplicity and a shallow learning curve for newcomers and non-Enterprise Developer types; and maintainability and ease of development when building more complex workflows in the application. Since one of our goals is to provide an environment that can be easily customized and changed based on the needs of a particular museum or type of collection, a certain amount of UI tier structure is essential. On the other hand, heavy frameworks like the ones we typically see in Java-based solutions run the risk of slowing down the development cycle and poses a significant barrier to entry. Colin

Highly structured and concept-heavy frameworks tend to be difficult to learn and retain. However, an expert user can typically develop with them more quickly. This learning/retention issue seems much more acute, with most frameworks, than the number of instances of any particular concept.

Weakly structured frameworks also tend to carry an increased ongoing maintenance cost but lower up-front cost than highly structured frameworks. Dan

Evaluation and Selection of a UI Framework

Choosing a UI Framework

  • No labels