Barracuda - Definition of Terms
barracuda.gif (11456 bytes) Key Terminology

It may be helpful to define several commonly used terms up-front.

  • Paradigms - We speak of 2 distinct application paradigms -- When we talk about the Web-App paradigm, we are primarily referring to uni-directional communication that generally occurs over HTTP and has a very thin, relatively stateless client. This is opposed to the classic Client-Server paradigm where the client is typically much larger, has state, and applications can take advantage of bi-directional communication between client and server.

  • Events - An event is something when something happens in a system. Typically, this will correspond with a client initiated action--the user presses a button or a link--that results in an HTTP Request. In the Barracuda event model, these requests get converted into true event objects (like what you'd see in the JDK 1.1 event model) that can be dispatched to listeners within the system. Events can also be generated on the server side, either in response to an existing event, or as a new entity altogether. Within the event model, the event dispatcher distinguishes between "control" (or "request") events and "view" (or "response") events.

  • Components - We use this term in two distinct ways. Sometimes we refer to client components which generate an event. In this case we mean HTML or WML entities like buttons, links, etc. Most of the time, however, when we talk about components we mean server-side components. These allow developers to bind "widgets" to an DOM object and then program against the widget's "model", much like you would in Swing.

  • Model 2 / MVC - MVC stands for Model-View-Controller. It is a paradigm introduced in Smalltalk and thoroughly incorporated into Swing (and other stated GUI models). Model 2 is a term coined by Sun to describe an MVC architecture for web-apps (stateless) in which HTTP requests are passed from the client to a "Controller" servlet, which updates the "Model" and then invokes the appropriate "View" renderer (JSP, servlet, etc), which in turn renders the view from the data in the updated model.

    The current implementation of the event dispatcher uses a Model 2 paradigm for dispatching events. Request events (corresponding loosely with Controllers) are handled first, and can specify the appropriate Response events (roughly equivalent to the Views).

    It should be noted that while Model 2 is "MVCish", it is not MVC in any sense of the word as typically associated with Swing. Swing is explicitly tied to MVC through well defined Java interfaces (Models, Listeners) that exist for all Swing components. In Model 2, we are talking about an MVC approach (ie. we look at the general system flow and observe that it acts--loosely--like an MVC system). Swing's MVC is much more granular (and thereby much more flexible) than any of the Model 2 implementations.

    When we talk about creating a Barracuda MVC Component model, we are talking about doing something like Swing for the server side. An MVC implementation will integrate into the larger Model 2 scheme.

    For a more complete explanation, see the Definition of MVC document.

If there are other terms which seem confusing please let me know and I can expand this section...

For all the latest information on Barracuda, please refer to http://barracuda.enhydra.org
Questions, comments, feedback? Let us know...
Copyright 1997-2002 Lutris Technologies, Inc. All rights reserved.