|
 |
 |
 |
 |
 |
 |
Barracuda - Definition of Terms |
 |
 |
 |
Key TerminologyIt 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. |
|