|
|
|
Basic concepts overview
Project Zero provides a full-stack environment for developing and running modern Web applications. There are a number of core concepts that define the architecture of a Zero application. These core concepts are introduced here and explained in more detail throughout this Core Developer's Guide. The following sections of this article provide information about some of the core concepts of Project Zero:
Scripting and Java as the system language
While the Project Zero runtime is written in Java, components of a Project Zero application are written primarily in a scripting language. Project Zero supports two scripting languages. The default scripting language is Groovy. Groovy is a scripting language based on Java and enables Java programmers to easily and naturally transition to using Groovy. Also, through an extension module, Project Zero supports PHP as a scripting language.
When creating an application, the service logic, views and other elements of your application are written primarily in one of these two scripting languages. However, reusable libraries and extensions to Project Zero can be created in either the scripting language or traditional, non-scripting Java classes.
Events
Project Zero is an event-based system. All of the key behavior of the system is exposed to the application as a set of events, with the appropriate event state. Application developers mainly provide a set of handlers that hook into the well-known system events to achieve application behavior needed. The standard Project Zero events are meaningful activities of interest to applications.
Common events that most application developers use, like providing a response to a GET request to a URI or when an application is started, are provided. Event handlers are stateless blocks of function that handle the events. Events are identified by an event name, such as GET or LOG. Event handlers indicate an interest in handling a particular event under a particular condition. For example, a developer can register functionality against the condition of a HTTP GET request when the URI matches '/foo'. These event registration rules can be provided in the configuration file for your Project Zero application or they can be implied from a convention on the directory structure of the application. For more information, see the Resource (REST) handling? article. Event handlers can be created using a script or using Java classes.
Global context
 Note to M1/M2 users: The global context has changed since the M1 and M2 builds. See the migration and other information about this change, provided in the Changes in the global context article.
Event handlers in Project Zero do not have explicit input and output parameters (for example request and response, respectively). Because all event handlers in Project Zero cannot maintain a variable state across invocations, and are therefore stateless, Project Zero provides the global context as a mechanism to access and maintain all state information. The global context provides all of the interesting data about the current event to the application and provides the mechanism to store and share information between components of the application.
The global context is scoped and divided into a set of zones where each zone maintains data with different visibility and with a different life cycle. For example, the user zone contains the session state for a given client, is visible only for that client, and maintains the data until the user becomes inactive. The request zone contains the state of the currently active request, is visible only to components run for that request, and the state is only maintained until the end of that request. See the Global context article for more details.
Data stored within the global context is accessed with a URI naming scheme. For example, if you stored the foo string in the request zone, the address of that string might be /request/foo. The global context also provides a number of powerful behaviors to simplify access to data stored within it. For example, if you store a map in the request zone at bar, you could access keys within that map directly using an address such as /request/bar#keyA.
In your application, if you need to pass data between handlers or components within your application, you can do that through the global context. In fact, the global context should contain all state data for your application.
REST and RESTful resources
The Project Zero environment is optimized around the REST design model and modeling applications in a RESTful style. This means that there is specific support for organizing your application around the concepts of REST. You can see this in the GET, POST, PUT and DELETE events that are fired in response to an incoming request. Project Zero encourages a model where you know and understand the HTTP methods and implement appropriate behavior. All resources that respond to requests can be implemented using a REST approach in Project Zero.
Project Zero also supports a constrained model for RESTful resources. A RESTful resource is logically a service that follows an entity style. Entities are nouns, such as Employees or Blogs. RESTful resources have a collection view and an individual item view. Using the HTTP method, you can act on either the collection or the individual items. Project Zero supports a particular model for easily implementing this RESTful resource pattern and for simply exposing key information about the resource to your scripts. See the Resource (REST) handling? article for more information.
Conventions and the application directory structure
The Project Zero environment provides a number of conventions that, when followed, greatly simplify the development of Project Zero applications and minimize the amount of configuration information that must be specified. The goal of Project Zero is to have as little configuration information as possible. Some of the conventions are common and expected. For example, you can place a script in the public folder of your application and run that script in response to an HTTP resource with no configuration data. Other conventions are more tailored to a particular pattern. The RESTful resource model described in the preceding section is a good example of such a pattern.
The layout of directories in a Project Zero application plays a key role in the conventions. The directory structure provides context information about what a particular file or script represents, how it might be accessed from HTTP, and which events it intends to handle. The structure of the application is intended to help you organize your application components intuitively and it will help you access powerful capabilities easily. See the Application directory structure? article for more information.
Application-centric runtime
One of the simplifications of Project Zero is the notion that each application is a standalone runtime. Rather than loading runtime components 'just in case' the application might use them, the application runtime contains just the set of features that a single application is using and is thus small and efficient. There is no deployment process for Project Zero applications. You simply have a set of files that represent your application and a set of dependencies on extension modules. You can copy the application to a machine, resolve the dependencies and start the application. Multiple applications can, of course, run simultaneously but they run independently providing isolation, simplifying versioning issues, and enabling easier management.
Extension modules
Project Zero applications declare dependencies on extension modules they are using. The Project Zero core is a very small kernel that provides the implementation of the Project Zero system. The event engine, global context system, and HTTP protocol handling make up the majority of the Project Zero core. An application declares a dependency on a particular version of the Project Zero core. It then declares dependencies on other components it is to use. For example, if you want to use Dojo to build an AJAX client, you declare a dependency on Dojo, zero.data if the application connects to a database, or zero.atom when consuming or producing Atom feeds.
When you run your application, only your dependencies are loaded. Extension modules can also contribute function directly to your application. The zero.core.webtools? extension is an excellent example of this. When you use Web tools you get a set of URLs (such as /zero/webtools/snoop.gt) that work in your application without adding any new files to your application.
Project Zero provides numerous extension modules for common features needed by applications. The list of available extensions will grow rapidly over time. The goal is to have most common capabilities needed by application developers provided through an extension module that is simple to use.
Summary
This is a quick overview of the key concepts of Project Zero. All of the important details behind these concepts are provided in individual sections of this Core Developer's Guide. If you are new to Project Zero, the Tutorials and Examples sections are a great place to start. They will help you understand how all of these concepts fit together. If you are working through building your own application, this guide should provide you with the detailed information you need.
Related information
Additional resources
|
