Seedling is a platform for component-oriented applications. By this we mean that a developer uses Seedling as a platform on which to build a complete application from smaller-scale reusable software components. The details beyond that depend greatly on the kind of application you want to build. Seedling's current built-in services are very limited, but the most powerful and important part is the configuration engine and component instantiation and retrieval services (the configuration trees and the actual Seedling component tree).
Seedling components are arranged in a hierarchical namespace, providing the platform's basic “branch/node” metaphor. Each component has a unique address within the tree by which it can be accessed from other nodes. A configuration tree specifies the structure of the tree, and the address, type and properties of each node. This is a simple model for organizing and visualizing an application. However, Seedling extends this model in two ways.
The first extension is the concept of configuration layers. Instead of allowing only a single tree to configure components, additional trees can be added in “layers”. “Higher” layers can alter the specifications provided by “lower” layers (for example, change the value of an individual component property, or change the type of a component altogether). Each layer can also add entirely new nodes to the application (for example, a new system-wide service, or a new menu item in a GUI).
The second extension to the basic hierarchical model is scopes: multiple independent hierarchies, each with its own instances of various nodes. Scopes are themselves arranged hierarchically; there is a single “global scope”, from which are derived any number of “local scopes” (which may themselves have subscopes). A scope's address space inherits the nodes housed in its parent scope, so each scope provides access to a unique set of scoped objects in addition to the global objects available to all scopes. This advanced feature can easily implement many common architectural forms, such as user profiles (where each scope houses component instances unique to one user), HTTP sessions (where each scope houses data specific to a browser session or request), and GUI frames (where each scope holds the widgets and logic of a single window).
Given this explanation, the core platform can be understood as a powerful model of component instantiation, defined by three key concepts:
Hierarchical namespaces
Layered configuration of components
Namespace scope
A Seedling application (that is, an application built using the Seedling platform) is made up of one or more modules. Each module contributes new components to the tree, and customizes the configuration of existing components.
Each module has two aspects: a configuration layer that specifies
the module's runtime components, and (optionally) a JAR file that provides
any necessary classes that aren't provided by another module. A module can
be deployed into an existing Seedling runtime system simply by copying it
into a modules
directory.
The core runtime
module provides only the
baseline configuration and namespace features, the heart of the Seedling
platform. Because the runtime has nothing specific to any particular kind
of application (client, server, Web, GUI, etc.), support in that dimension
is provided by separate modules. You build an application by building one
or more modules that run as layers on top of the runtime. Your modules
will have code for custom components, and configuration files to install
those components into the tree. You'll probably add at least one component
to the StartupNode
system so that your program will do
something on launch. Look at src/ticker
for a
complete, if tiny, module.
A long-term goal of the project is to have modules available for many common application services. The project distribution includes support for compiling, testing and packaging Seedling modules.
This document is under active development. Our intent is for it to become a complete guidebook and reference to the Seedling platform: its rationale, its architecture, its best practices, its innermost secrets. As it stands there are gaping holes, but don't let them frighten you. If there's some aspect of the project on which you'd like to gain clarity, just ask about it on the Seedling-user mailing list. We'll answer your question as soon as possible, and probably add a new chunk of text to this document so others will have the information at hand.
Tip | |
---|---|
To join the Seedling-user mailing list, browse to the Seedling project page at SourceForge and click on “Mailing Lists”, or just follow this link. |