Appendix
Architecture
- Architecture
Aria is an application development framework designed to relieve the programmer of many common tasks involved in building smart client applications.
This appendix describes the overall architecture of Aria and details how its subsystems interact. The appendix may be of use to application architects and to application programmers.
The Aria Solution
At its simplest Aria s a set of factories designed to hide some of the complexity involved in application construction. Aria builds upon several well known patterns (see Design Patterns [1]) to simplify object creation and to separate concerns within the application.
Typical of this is the use of factory methods to hide the details of object construction and the use of adapters to provide uniform access to data.
Using these facilities the application developer can offload much of what we term `plumbing' to the Aria library.
The solution offered by Aria and enhanced by Aria is layered in an object oriented fashion so there is considerable control as to how extensively Aria need be used in an application. At its fullest Aria can provide a large proportion of what is needed to build a complete application, apart that is from the application specific business logic
At a high level Aria consists of
Figure 1: Overall application structure
Project support for coordination of resources
Most applications deal with a variety of objects and resources and an Aria application is no different. In a bid to coordinate resource usage Aria includes a project concept. This project is little more than a mechanism for holding references to the various resource manager objects and types needed by an application.
The use of a project facilitates access to resources by providing a central access point. Making the project the owner of these resources also means that the responsibility for resource creation and disposal can be coordinated. This coordination helps provide an orderly and predictable application startup sequence.
The term resource is used in a broad context to mean any class or object used by the application and this includes the management objects that form part of the Aria framework. An Aria project therefore has application specific resources such as pages, data, colours and fonts as well as the framework originated resources such as page factories, component/widget factories classes, validation factories and event and data management components.
The project acts as a store for most of an application's data, delegating to other classes to manage things like styles and pages. The project retains ownership of these classes and therefore it in turn owns all the resources used by the application. With this demarcation of resources it is possible to coordinate several project (or modules) within a single JVM and therefore the ProjectManager singleton is used to store references to the projects and it provides access to these projects by name.
Application lifecycle and stubs
The core mechanism for loading the application and the project is encapsulated in the ApplicationContext context class. The class coordinates loading of classes that are used by the project, given that many of these classes can be configured and customized via the startup files and other configuration files. The application context is also responsible for some of the lifecycle interfaces, for instance adding a shutdown hook to coordinate resource cleanup when the JVM exits.
Normally the application context is used in conjunction with an instance of StartupObject . The startup object depends upon the widget set being used and encapsulated some of the widget specific issues (by instantiating an instance of WidgetAdapter specific to the widget set being used), and by managing the display. For instance the basic Applet class for Swing coordinates the setup of the page container used to display Aria's pages. However the startup object relies on the application context and the support classes that it instantiates (like the PageManager ) to manage the application lifecycle.
Several startup objects are provided, one for each of the Widget sets supported by Aria, plus some additional forms that allow customized display such as embedding of Aria applications within other applications.
Factory methods to remove repetition
Perhaps one of themost obvious places to begin our description of Aria is with user interface construction and a description of how widgets are added to an application.
Many Java IDEs rely on the basic Java bean facilities to manipulate user interface (UI) components. These beans provide fine grained access via accessor methods and while this is well suited to generated code it is not very programmer friendly. More often than not once generated the UI code is further manipulated by the programmer and this manipulation may break the IDEs graphical editing capabilities. Not only does this situation rapidly degenerate into ugly code and maintenance issues but it also is cause for excessive code bloat.
Aria provides several factory methods that take car of constructing the UI objects and setting the most common properties such as location and content. Aria also includes support for style sheet like specification of attributes such as colour and typograhical information. These additional attributes can be applied by simply using a different object factory.
The object factories can be used interchangable and also help construct an object hierarachy as components and containers are added.
A single factory method call can replace up to a dozen lines of generated code.
Later this document will detail how this method of object construction can even be removed from the Java code base and declare via XML. This XML declaration however is still routed though the same component factories outlined above.
Aria 3.0 introduced a common mechanism for registering various modules and components. This registration mechanism allows multiple named configuration files to added for most components. The mechanism allows handling multpiple third party components and for qualified selection of components based upon usage or upon a developer defined match/callback
Extensible loaders
Aria extends the page loader mechanism, adding several additional page loaders for different file formats. The loader mechanism is designed to be extensible but in many cases declarative systems can be mapped the GenericBuilder which defines a hinting and mapping format for this purpose. The generic builder can also be further customized, with the addition of extra parsers and interpreters so that systems as diverse as Python, VB and Oracle Forms can be mapped to Aria.
Using this extension mechanism means that providing editor support for these formats is relatively easy as the editor itself employs a customized loader. Once the loader/builder is complete the internal representation of the format should be the standard Aria form (although the widget sets may vary).
Factories to target different devices/platforms
One of the key design goals behind Aria was to target limited devices such as handheld computers. For this reason Aria was initially built to support AWT based UIs and JDKs as early as JDK 1.1. Later support was added for JFC/Swing interfaces and additional widget types.
The relatively low base means that Aria can support a wide range of devices not just the latest desktop computers.
The use of component factories mean that the UI implementation can be changed from AWT to Swing simply by changing a startup parameter. Aria also employs a pluggable architecture for registration of the component factories so there is litle difficulty extending Aria to support other UI widget sets such as the LCDUI found in J2ME devices such as RIM's Blackberry devices of Palm's PDAs.
Ignoring the some the device limitations (such as screen resolution) for a moment this targetable UI support means that the same code can be used to simultaneously support a variety of devices.
Full API access
Unlike many other client solutions Aria provides full access to the underlying API. Widgets and components created with Aria can be accessed and manipulated as though they were constructed directly using the API.
Some wrapper for standard widgets are provided but this is for convenience and to allow switch of implementations. The wrappers are thin layers and do not block access to any of the underlying features.
Furthermore all the normal mechanisms for operating on components such as the built-in event handling are available and can be used in conjuction with the features provided by Aria. If for some reason the Aria approach is found to be limiting then it can be supplemented or replaced by direct coding.
This strategy also means that Aria applications can be extended by adding third party components and tools without restriction. Ultimately the Aria code base is open source and is available under a license that allows modification so (probably as a last resort) any of the Aria features could be modified to meet the applications needs.
Layered approach to styles
As has already been mentioned above Aria support a style sheet like way of configuring the appearance of widgets.
Styles can be declared in an XML style file and applied to the components during the component construction process. All that is needed to employ the style sheets is to use the StyleFactory class to construct the widgets instead of the basic component factory. In fact by default Aria will use the style factory.
Moving style declarations to a separate XML file not only means further cleanup of the UI code but it also facilitates additional features such a rebranding an application. Changing the style file associated with an application way also go some way towards addressing the differences in the device capabilities mentioned above.
Styles can also be applied to an application by using a Java Look and Feel (L&F) or a theme, however the styles sheet support provided by Aria offers a much finer level of control over an application's appearance than could be achieved with a L&F alone.
Modular extension
To support multiple widget sets Aria employs an abstract registration mechanism whereby component factories can be added to an application. The Project class owns the component factory and additional factories can be registered at any time although registration is normally carried out at startup.
The component factories offer a number of interfaces for creation of an object. The build in components are assigned unique identifiers whereas additional factories generally rely on a type name to construct the component.
The component class name can also be used to instantiate a component so that third party components or components not expressly supported by a factory can also be added.
The component factories also make use of the AttribuedComponent interface to set component attributes in a generic way rather than having to have detailed knowledge of the accessor methods and without recourse to reflectionor the bean support classes. This method of setting attributes works well in a cross platform situation where there may be differences in the implementation of a particular feature, for many APIs from JDKs are now deprecated.
As factories are normally registered during startup with the project and as the order in which the factories are registered may be important it is therefore easy to see how important a role the project has in creating a predictable startup.
Page management
The component factories described above can be used on their own without need for other parts of the Aria or Aria frameworks but much advantage would be lost if such an approach is adopted.
Applications rarely consist of a single screen or page so Aria provides additional support for instantiating and uses pages in an application framework. The term `page' derives from the notion of presenting an application with a series of page or screen. Logically these pages may equate to steps within a business process or data capture cycle.
Depending on the type of application pages may be used on a one off basis or reused repeatedly, perhaps with updatable content.
Aria provides a page management facility to store pages and manage the context in which they are displayed. Normally only one page is visible at a time but pages may also be used within a frameset to allow further decomposition of the on screen layout. Each element in a frameset holds an individual page.
The PageManger class is owned by the project and in turn it owns the individual pages in the application. Aria includes page navigation methods such as showPage and showPrevious. If the page manager determines that it does not already hold a reference to the request page it will instantiate the page on behalf of the application.
At its simplest a page is instantiated by invoking the ClassLoader to create a new instance of the class. The page is then inserted into the display area via the PageDisplay interface which is implemented by the applet/application class.
If the page is already loaded and is not the currently displayed page the new pages is swapped into the display and the previous page is removed from the container and hidden.
The page manager invokes several methods during page creation and display to allow the page update its content, these lifecycle methods include notification of page creation, activation, and deactivation.
Since a page may be declared via XML it is not possible to directly instantiate an instance of a page class that will represent the content of the XML file. Instead the page manager delegates to a secondary loader (registered at startup) that processes the XML file and creates and configures the page's components.
During construction an instance of an Page is created or of a derived class and the components are addressed to the new page. Once create in this way the XML originated page is largely indistinguishable from one created from a Java class.
The same lifecycle events are fired and an XML page can therefore use the use the page creation response methods to do any additional setup. In a Java page the constructor might do more than just create the widgets so the page creation method provides an opportunity to do equivalent processing for the XML page.
Given that an XML based page may reuse the same base class definition the page creation response method gains in importance as it may be used to bind references to widgets for subsequent use in the class.
The application context by default instantiates at least one page loader ( PageLoader ) and adds it to the page manager's list of page loaders. The default page loader is the AriaBuilder class that parse the page XML. The page manager may therefore have many different page loaders for various file formats and it will iterate through these page loaders till the requested page is successfully loaded.
XML as a shortcut to declaring content
XML as a means of declaring content opens upon many possibilities. Coupling between business logic and the user interface is reduced and the implementation of the UI is more flexible as it can be rendered for different situations in different ways.
The XML needed to represent a page is also relatively compact in comparison to the byte code produced for an equivalent page. This can be of benefit where bandwidth is an issue.
XML can also be generated on demand and in some situation this might be desirable, for example where repetitive catalogue content is being streamed from a database yet where the content may content subtle variations that need to be accommodated in the layout.
Proxies for event management
As with the UI construction Aria provides extensive support for event handling. Using Aria all the plumbing code needed to direct the application to an event response method is hidden from the programmer. There is no need to declare listeners or adapters, all the application need to is declare its interest in receiving notification of an event. 
To handle an event the Aria page container registers a proxy for handling the event and using reflection behind the scenes the appropriate response method is invoked by the proxy. To support this reflection mechanism the response method must be in a class derived from the Page class, normally this is the case.
Figure 3 2: Event dispatch for a mouse event
While the response methods invoked in this way are parameterless access to the event is available through the page. The response method may also be overloaded in a polymorphic fashion and in this way libraries of page types may be constructed. Typical of this is a definition of response methods that handle page navigation functions. Such functions can be provided at a low level and shared by derived classes so that the navigation methods need be defined only once.
Input validation
Using a mechanism similar to the event registration Aria can register validation rules for input fields. The validations are special response methods invoked wherever an input field gains or looses control of the input focus, or upon page transition.
In response to this change of focus a validation rule is invoked. Several predefined validation rules are available, for example a MinMaxValidation defines a rule that checks for that an input in with a specified range of values. The limits or parameters for the validation rule are named and the name is associated with values read from a configuration file (by default validations.xml). The validation parameters can even contain method calls that are evaluated at runtime.
Each Aria page can have a validation factory that will construct the parameterized validations on behalf of the page. The page delegates addition of the validation rule to a validation handle that adds the appropriate event handlers to the component being validated. The validation handler coordinates the validation rule checking in cases where more that one rule needs to be evaluates or where dependencies exist.
Some validations may be marked as mandatory so that their input must be valid before certain actions such as page transitions can take place. The validation handler object provides some several methods for checking and rechecking the state of a page's inputs.
Should an error (such as an out of range value) be encounter while validating an input an exception is thrown. The exception is handled by an instance of the ValidationExceptionHandler class. By default it is the page that actually that implements and handles this response by displaying a warning or error message. However the application can override the processing to provide a page specific way of handling the error or the application may choose to register a completely different error handler. An example of this might be where an application chooses to display a list of error in a common window instead of popping up separate error messages for each error.
Figure 4: Exception handling during validation
Data modelling
An application is of little value without data and very often an application serves to do very little other than providing convenient access to or representations of data.
Much of the logic in a form or page based application can revolve around getting and setting the values of UI components. Much of this work is repetitive and mechanistic.
To remove the burden of managing this data access Aria provides a hierarchical data model. This model can be accessed using an XPath like syntax so that the application programmer need not be concerned with the details of how a model node is reached and accessed apart from specifying the path to the node.
Each node in this model can be a simple primitive type such as a string or number or it can be rich types like a list object or even a database table.
The DataModel class provides an abstract representation of the nodes in the model. The model also acts a way of unifying all the data used within the application although data of different types (database tables for example) may be maintained on a different branch within the overall model.
This single data hierarchy and common access mechanism greatly simplifies data access. Despite this rich capability one size rarely fits all uses and therefore the model architecture is extensible right from the management of the model through to the representatation and usage of the model nodes.
Data loading
Once again the project class owns the model and upon startup the applet instantiates a data source (DataSource in the basic Aria setup). The data source can then load the data from various sources. Aria's data source reads a number of configuration file and has multiple data sources. The data loaded by the data source is attached to the model at a node specified by data source's XML configuration file.
At this point the model need not be fully populated and some data may be loaded on demand. In some cases the model may not actually store the data and instead the model node may merely be an interface through which data is accessed. Database access is an example of this as is access to remote data and services.
At runtime the model may also be extended by the addition of sub branches as more data becomes available.
The creation state of the model is largely transparent to the application. For example if a node is accessed it will be automatically created if not already in existence. In this way storage can be made available for say a calculated value or an input value as needed. Frequently calculated data is assembled or produced only as progress is made through an application session.
Indeed this dynamic extension to the model can greatly facilitate the simplification of an application as it need not know very much about the overall state of the underlying data model. In practice this agnostic approach to the model allows opportunities for `lazy' loading of data and for redundant data sources (i.e. where a failover source of data is available should the primary source be unavailable for any reason).
Data binding
Although Aria provides a simple method of accessing data in the model it is unnecessary to use this method display and store data in the UI components. Data in the model can be simply bound to UI components.
Just as validation rules and event response methods can be associated with UI components as though they were component attributes data can also be bound in this way. Again access is through the page container and all the application need to is specify which piece of data to bind to an individual component.
Beneath the scenes a factory class is again used to construct data bindings (derived from the DataBinding class) and associate them with the component. The data binding knows how to get and set data and persist it to the model, equally it knows how to pull data from the model it and update the UI state. This two way data update means that the binding can update both the model and the UI without further intervention from the programmer.
The data binding and the underlying model can be seen to act as a data channel for passing information from one page to another without directly referencing one page from another. Thus an axample of this might be where a page displays an input for a user name or ID, if the input field for this information is bound to the model any other page that binds a UI component to the same model node will automatically display the same data once that page is displayed.
Not all data is equal and some UI components demand different data. For instance an edit field might require a simple piece of text or a string a drop down list demands a set or list of data and a table component demands tabular data. Because the required data is not necessarily of the same type or structure as is held at a particular model node an adapter class may need to be created to allow the data be accessed and represented in a meaningful way.
Figure 5 Data binding
The core Aria package provides a limited set of adapters as itself provides only a limited set of model nodes, mostly for static data sources. Aria on the other hand provides much richer and varied data sources. Indeed Aria's data model encapsulates remote data and remote services both of which may return unknown data types. Aria therefore defines an extensible factory for the creation of bindings and adapters. The factory uses a double dispatch mechanism whereby both end of the binding are used to determine the type of binding required. A binding may in fact be composed of several layers of adapters depending upon what is demanded by the UI component and on what is offered by the model.
This flexibility in creating bindings and in handling differing data sources removes considerable burden from the programmer. In this way business logic can be coded with a large degree of disregard for how the data is display and how it is stored.
Equally, the use of adapters and dynamic data binding also increase the flexibility with which a UI can be constructed. Some page can effectively be build without detailed knowledge of the data they will represent. In some applications such as catalogues or browsers this flexibility may make it possible to have a page adapt itself to a broad range of content. Traditionally this would have required custom logic and would have introduced extensive coupling between the presentation and the model.
Database access
One of the most common data sources is the database. Aria provides access to databases via the model. Tables can be preconfigured for specific queries (including parameterized queries) or the queries can be constructed dynamically.
Aria also manages the connections on behalf of the application by providing pooling and by hiding details of the connection from the application. Not only does this remove configuration information from the application code but it also make the coding simpler.
To support the widest possible range of scenarios Aria uses JDBC for the underlying database access but limits itself to a fairly low level of features as some of the lightweight and open source databases have limited features. Aria builts upon this access by then adding features such as a caching layer and replication services.
For the most part once a table has been configured the application can use it as though it were any other node in the model. Rows and Fields can be addressed using XPath like expressions and the tables can be bound to UI components via the sort of adapters mentioned above.
For remote client applications databases can be replicated to the client device on demand and cached locally across sessions. Whenever a database resource is accessed the state of this cache is checked and updates are obtained as needed.
The transparent replication of tables from a server to client make it very easy to move functionality from a server to a client in order to create a standalone client.
The database may be used in the reverse scenario where a client application has been operating off-line and has stored information in the local client side database and needs to update the server. The client will again synchronize with the server side database, uploading data once a new session is initiated. Of course in a multiuser environment this sort of update places special design considerations on the database so that the consistency of any shared data can be preserved.
Services and communication
Aria introduces another special type of node to the model, an ServiceProxy node. This node type is a wrapper for a call to some function or service. At its most basic the service proxy node calls a function and as a result returns data. Access the proxy via the model effectively means calling that function. The function can be paramaterized by the nodes attributes and can be implemented in a variety of ways.
In Aria the service proxies are frequently layered to provide additional processing for features such as data checking, encryption, compression and so on. In some architectures this layers objects are termed `interceptors'.
Another common use of the service proxies is to wrap transport protocols such as Http. As you can imagine with something like an http call there are two sides to the call, a client and a server side. Aria provides for different configurations for the client and server sides and therefore the stack (of services) for each side of such a call can be configured as appropriate.
Routing
The layering of service calls is called routing in Aria. For example a call to a remote business operation might be made over a secure http channel. To provide such a route several services would be used; an encryption service, a compression service and an http service on the client side, while on the server side the call would pass through the http server side service, a (de)compression service, and a (un)encryption service before finally being processed by a business object of some sort.
As you can imaging an application may need several of such service stacks to implement all its needs. Aria allows a service proxy to be routed via any named route. The services at either end of the route act as the endpoints. At one end the service represents the point at which the service/route stack is bound into the model and at the other end the final service nomally implements or interfaces to the business process.
Although a route is comprised of several service proxies the stack of services that comprise the route are treated slightly differently than plain service nodes. A route can be reused by multiple service proxies, for example the http transport route described above could be reused for numerous calls within an application.
Aria's support for routes does not stop with transport protocols. Aria also provides routes for fault tolerant communication, store and forward communications (i.e. data is forwarded once a communications channel becomes available), for redundant routing (communications can be attempted over several routes in parallel) and for failover services (an example might want to provide a default locel implementation if the server cannot be contacted).
Resource Loading
Invariably an application makes use of many resources such as graphics, text, data and files of various formats. An application could simple assume the resources it needs are available or are installed but this would make for an inflexible approach. Furthermore depending on the distribution mechanism the resource could well be located on a client machine in the fie system or in an archive or on a server somewhere. During the lifetime of an application the location of the resource may even change.
Aria's resource manager class provides several methods for locating and retrieving a resource. The resource manager can also construct an input stream on behalf of the application and it may also retrieve objects such as graphics on behalf of the application.
In order to locate and/or retrieve a resource the resource manager attempts to find the resource on the classpath and on the file system. The resource manager can also make use of a custom class loader to search additional paths if needed (this strategy is employed by the IDE at design time).
In addition to this direct loading of resources Aria provides support for extract resources from the classpath to a temporary directory for subsequent loading. This may be necessary where it is assumed that a resource is accessed as a file (some databases make this assumption) or for loding of system files such as native libraries.
MVC pattern for separation of concerns
The Model-View-Controller pattern is another de facto industry standard and already it should be apparent that such a constructional pattern is employed by Aria. Support for this pattern is provided by the factory classes that help encapsulate the various UI components and features, by a rich data model and by the event and validation handling facilities that can be used to control the application in conjunction with the business logic.
The MVC patterns help to separate the architectural and modelling concerns in an application. With such a separation the role of each component is clearer and hence more maintainable.
Java Language
This chapter explains some of the key Java Language features that are used in Aria. It is intended to highlight the impact of these features on Aria rather than being a tutorial or programmer's guide for the language itself.
Don't forget you can use Java
It may seem a little obvious but it can be easy to forget: Aria is a Java based system. The objects created by Aria are all Java objects and you can interact with them using the normal Java programming idioms.
The upshot of this is that you are not constrained to use what is in the Aria framework. If something is missing or does not suit your purposes then you can just code it in Java.
For example Aria provides numerous ways of adding components but sometimes you may have special needs and these needs may not suit the Aria programming idioms. Instead of using saying the component registry or the component factories you can just add the component you need in the page's constructor or in the pageCreated method.
Object types
Java is a strongly typed language but to a certain extent the loose coupling and late binding promoted by the Aria and Aria frameworks can hide this facet of the language. However the framework is primarily a Java based system and ultimately the language's type system will come to play.
This hiding of information may in some circumstances limit the amount of compile time checking carried out by the compiler when building a Aria application. For this reason it is recommended that you use the debug version of the Aria libraries when developing an application. These libraries output a lot of useful debug and diagnostic information and this information can help you track down numerous problems, not just type issues.
As Aria is an open source language you can also obtain the source code and include it in your project so that you can gain even more information about the cause of a particular problem.
If for instance you use the model to pass data between components of your application you may at first be unaware of type issues as the data model is to some extents agnostic about data types. However your application's components will probably require a specific type and if this type is not what was stored in the model you may get type conversion exceptions.
As the chain of events that leads to such situations may be many layers deep you will probably want all the debug information you can get. In the release builds the Aria framework will suppress some error messages and so all you would see would be a message saying that there was a failure invoking a method, with the debug version you should be able to pin-point the source of the error.
Also, with a system comprised of many loosely coupled files you can also get the above types of problems if the wrong type of data has been mapped into the application, but of course this sort of problem is not unique to Aria. Again the debug versions of the libraries can be helpful and with Aria you also get configuration and visualization tools that may help prevent such problems arising in the first place.
Returning to the subject of types, the framework provides the IntegerAdapter and DoubleAdapter classes to make it a little easier to work with the model when using integer and double values. The same techniques used in these classes can just as easily be applied to other types. The adapters simplify access to objects of either Integer or Double within the model and make it less likely that you will forget to make a necessary type conversion. The adapters also have the nice fringe benefit of making the code a little easier to read.
Inheritance
Inheritance is one of the cornerstones of object oriented languages such as Java. One aspect of inheritance is information hiding and this is something that you should be aware of when programming a Aria application. The framework does a lot of work on your behalf and sometimes it is easy to forget this.
One of the most common ommissions is the use of the properties of the base class for pages, Page . The Page class contains several references to key objects like the project manager, the style manager and the project. Remembering to use these variables in your code can save a lot of work.
You should also remember that inheritance may be several levels deep, so don't just stop looking for what you need one level down.
Inheritance also works the other way round too and you can extend many of the features in the Aria framework. Many of the features of the framework are designed with this in mind and are intended to allow you plug-in variations of the default structures and mechanisms.
Package Names
The package name in a Java application should correspond to a directory or folder in the operating system. In Aria this directory must also be a child of the project's source directory.
Special consideration should be given to package naming for cross platform applications and it is worth noting that the file and directory naming conventions vary from operating system to operating system.
In particular Windows users should note that unlike most operating systems Windows is not case sensitive. Furthermore Java is case sensitive so when the JVM loads resources such as images and other files the case of the path and file name is important.
When testing within the development environment under a platform such as Windows it is possible that a file can be loaded even if the case is incorrect as the operting system will ignore such details. However once the application is distributed and when loading from a Jar file the JVM will expect the case to match exactly.
When applied to package names this logic means that the directory names must match the segments of the package name exactly. Windows users should also be aware that Windows Explorer can capitalize the folder names so what is displayed by explorer may not match the actual filename exactly.
Here's what the Java Language Specification has to say about packages:
|
Programs are organized as sets of packages. Each package has its own set of names for types, which helps to prevent name conflicts. A top level type is accessible (§6.6) outside the package that declares it only if the type is declared public. The naming structure for packages is hierarchical (§7.1). The members of a package are class and interface types (§7.6), which are declared in compilation units of the package, and subpackages, which may contain compilation units and subpackages of their own. A package can be stored in a file system (§7.2.1) or in a database (§7.2.2). Packages that are stored in a file system have certain constraints on the organization of their compilation units to allow a simple implementation to find classes easily. A package consists of a number of compilation units (§7.3). A compilation unit automatically has access to all types declared in its package and also automatically imports all of the public types declared in the predefined package java.lang. For small programs and casual development, a package can be unnamed (§7.4.2) or have a simple name, but if code is to be widely distributed, unique package names should be chosen (§7.7). This can prevent the conflicts that would otherwise occur if two development groups happened to pick the same package name and these packages were later to be used in a single program. |
Classloaders
Aria makes extensive use of classloaders both within the editor and at runtime. Aria even includes a custom classloader so that you can access resources from the standard Aria folders (pages, resources, classes and lang) without having to include those folder names in the file path.
The classloader infrastructure comes into play whenever you need to load files, classes or other resources. Ultimately the system classloader is used and loads files from the classpath. The impact of this is most apparent if you wish to load third party classes. The classes may be found at design time within Aria as Aria will load extra Jar files in some cases, like for example when components are registered. However at runtime you may have to explicitly alter your classpath by adding references to such Jar files.
Aria may also help you by packaging the classes you use into a Jar file but you may be well advised to review what is included in the Jars so that you can get a more optimal distribution.
Classloading also affects the way in which you use resources. At runtime, once your files are packaged into the Jar files they will be read-only and the paths to the files will be case-sensitive. On a Windows system where the paths and filenames are normally not case sensitive this can represent a significant testing issue, so be advised that you should try and respect the case of paths and filenames at all times.
Reflection
Reflection plays an important role in Aria. Many of the links between you application code and the framework are made via relfection. It may be worth taking a look at the reflection API to see how in works in practice. Notably Aria event handling and dynamic attributes (See Evaluated attributes and helpers.) are invoked via reflection.
Encodings
Encoding is sometimes an issue for Aria and for Java applications. Aria is affected by encodings when working with localized text (see See Localization.), or indeed for any text file resource that the framework loads.
Encodings also come into play when working with client-server systems. Data transmitted over the network will need to be properly encoded so that the data can be correctly decoded on the server side. This encoding of data is also an issue for simple posting of data and Aria includes a service for URL encoding and decoding data.
Even if data is not being transmitted over a network URLs are commonly used and you should be aware of the requirements for encoding URLs. The services provided by Java and Aria make it relatively easy to solve encoding problems so long as you are aware of the issues.
Again, the interaction with the Windows operating system may be the source of confusion as the operating systems constraints on filenames do not match the specification for URLs and if the two are mixed you may well not notice any problems, that is until the naming conditions are broken. Typically this may occur when selecting a path or file name and passing it as a URL.
Annotations
Aria includes support for a number of annotations that you may find useful, and which may save some coding. Annotation support was introduced with JDK 5, so you must be using that JDK or later for the following annotations to work.
|
Annotation |
Usage |
|---|---|
|
@Bind |
An annotation for binding components and data declaratively. The component becomes valid just before the pageCreated() method is called. The annotation argument is the source path for the binding @Bind( "a/b/c" ) protected XButton myBtn; or @Bind( "a/b/c", extra="output=aria_state/x/y/z,unique=true" ) protected XButton myBtn;
where the extra attribute specifies a comma separated list of attribute name-value pairs |
|
@Event |
An annotation for binding components and data declaratively. The component becomes valid just before the pageCreated() method is called. The annotation argument is the source path for the binding
@Event( method="myHandler", type="ActionHandler" ) protected XButton myBtn;
where the extra attribute specifies a comma separated list of attribute name-value pairs |
|
@Find |
Performs the equivalent of the findComponent method, finding a component in the XML of the same type. Using this annotation you can avoid the typecasts that are required when using the findComponent method.
@Find private Button nextButton
find the button declared in XML as
|
|
@Page |
An annotation for binding a class to a page file for layout and styling information. It is not intended that such pages will be loaded as part of the normal aria application lifecycle, but instead they can be created directly
@Page( "foobar.xml" ) public class MyClass { ... } |
|
@Validate |
An annotation for finding components and binding to an object declaration. The component becomes valid just before the pageCreated() method is called.
@Validate( "CreditCard" ) protected Button myBtn;
or
@Validate( value="CreditCard", method="validate", when="mouseClicked", extra="type=custom,message=msg_res_key" ) protected Button myBtn;
with all values other than the value attribute being optional. The extra attribute is a comma separated list of name-value pairs. |
Learning Java
For those of you new to the Java programming language here are some resources that may be useful in learning the Java Programming language. Many more resources can be found by searching the Internet and the many Java related websites..
|
Learning the Java Language http://java.sun.com/docs/books/tutorial/java/ Sun's site for learning the Java language |
|
New to Java Center http://java.sun.com/learning/new2java/ More resources for those of you who are new to the Java programming language. |
|
Java Coffee Break http://www.javacoffeebreak.com/ Never programmed in Java before? Not sure where to start? This quick tutorial will get you up to speed. You'll learn how to compile and run simple Java applications |
|
Java from the ground up http://webdeveloper.com/java/java_programming_grounds_up.html |
|
The Java Ranch A friendly place for Java greenhorns |
|
Introduction to Programming Using Java http://math.hws.edu/javanotes/ Introduction to Programming Using Java, the fourth edition of a free, on-line textbook on introductory programming, which uses Java as the language of instruction. |
Further Resources
Sun's Javasoft website has extensive information about using an learning Java. A good place to start is the New to Java Center:
http://java.sun.com/learning/new2java/index.html
Reference
This chapter includes a collection of cross reference information.
Component attributes
The basic component factories process a small number of attributes that are common to all built-in (core) components:
| Attribute | Usage |
|---|---|
| x | The X or horizontal coordinate of the component when a null, absolute or guide layout is used. |
| y | The Y or vertical coordinate of the component when a null, absolute or guide layout is used. |
| w | The width coordinate of the component when a null, absolute or guide layout is used. |
| h | The height coordinate of the component when a null, absolute or guide layout is used. |
| style | The name of the style to be applied to the component |
| name | The name by which the component will be referenced. All components that have events, data bindings, validations or other references should be named. |
| type | The type of the component. This parameter has been deprecated. Originally it was used when all components were specified with a component xml element. |
| content | The usage depends on the component. For components such as labels and edit fields that display test this attribute sets the component test. For others such as images or meta components then the attribute specifies the filename containing the required data or content. |
| constraint | This is the layout manager constraint for the component and it's value should reflect the appropriate layout manager choices. |
| key | This is the key into the resource bundle file. The value is used to set the text in situations where the text is localized or translated. The key should be contained in the resource bundle pointed to by the page's resource attribute. |
| opaque* | Flags an opaque component |
| visible | Sets the visible / invisible state of the component prior to initial display |
| enabled | Sets the enabled / disabled state of the component prior to initial display |
A number of components use the AttributedComponent interface to set special attributes, these are listed below:
| Component | Attribute | Usage |
|---|---|---|
| Checkbox | selected | Sets the selected state of the check box, values=true|false |
| Image | content | A String value specifying the image name. The file name must be one that can be processed by the project and normally this means that the file is on the project classpath or in one of the subdirectories of the project such as the resources folder. |
| imagename | A synonym for the above. | |
| Label | align | Sets the horizontal alignment of the label text. Possible values are: "left", "right" and "center" |
| alignment | A synonym for the above. | |
| buffered | A boolean value to turn double buffering on or off. Double buffering may have a slight impact on the repaint performance, the setting can also be modifed via the toolkit. | |
| opaque* | If true the component paints every pixel within its bounds. Otherwise, the component may not paint some or all of its pixels, allowing the underlying pixels to show through | |
| Panel | border | Turns on or off the painting of the panel's border. If a value of 0 os used then no frame is drawn. For a value of 1 a single line is drawn around the frame in a colour just darker than the background. If a value of 2 is passed in then a 3d effect is used to show a raised border. |
| RadioButton | selected | Sets the selected state of the radio button, values=true|false. Setting this value will automatically set up a group for the radio button if none is already available. A new group is created for the first such radio button encountered within a container or panel. |
| alignment* | Sets the horizontal alignment of the icon and text: SwingConstants.RIGHT (the default), SwingConstants.LEFT, SwingConstants.CENTER, SwingConstants.LEADING, SwingConstants.TRAILING |
|
| Table | headingStyle | Sets the header style, the style refers to the styles listed in the Aria style file. |
| selectionStyle | Sets the style for the selected row within the table | |
| borderStyle | Set the style for the table's border | |
| interactive | Flags whether or not the user can select a row within the table, values=true|false | |
| updateModel | Tie the model selection to the table's selection | |
| Button | alignment | Sets the horizontal alignment of the icon and text: SwingConstants.RIGHT (the default), SwingConstants.LEFT, SwingConstants.CENTER, SwingConstants.LEADING, SwingConstants.TRAILING |
| Edit | alignment* | Sets the horizontal alignment of the icon and text: SwingConstants.RIGHT (the default), SwingConstants.LEFT, SwingConstants.CENTER, SwingConstants.LEADING, SwingConstants.TRAILING |
| border* | Sets the border of this component. A value of zero turns off the border | |
| editable | Sets the editable property of a Swing edit component | |
| margin* | Sets margin space between the text component's border and its text. The value is the size of the margin in pixels. | |
| format* | Sets the formatter for the edit field. The value can be
integer for an edit that only allows integer values currency for an edit that only allows monetary values date for an edit that only allows date values decimal for an edit that only allows decimal values or a mask specification for a mask format. See the JFormattedTextField documentation for more information. More precise control can be obtained by setting up a formatter in code and using the setFormatter method. |
|
| Password | alignment* | Sets the horizontal alignment of the icon and text: SwingConstants.RIGHT (the default), SwingConstants.LEFT, SwingConstants.CENTER, SwingConstants.LEADING, SwingConstants.TRAILING |
| ScrollableMetaContent | horizontal scrollbar* | Determines when the horizontal scrollbar appears in the scrollpane. Legal values are:"as needed", "always" and "never" |
| vertical scrollbar* | Determines when the vertical scrollbar appears in the scrollpane. Legal values are:"as needed", "always" and "never" | |
| Scrollbar | horizontal scrollbar* | Determines when the horizontal scrollbar appears in the scrollpane. Legal values are:"as needed", "always" and "never" |
| vertical scrollbar* | Determines when the vertical scrollbar appears in the scrollpane. Legal values are:"as needed", "always" and "never" | |
| SplitPane | orientation | Sets the orientation of the splitter. A value of "horz" creates a horizontal split, anything else gives a vertical split |
| location | Sets the devider size. The size may be an integer or double value. | |
| size | Set the devider size in pixels. | |
| Table2 | headingStyle | Sets the header style, the style refers to the styles listed in the Aria style file. |
| selectionStyle | Sets the style for the selected row within the table | |
| borderStyle | Set the style for the table's border | |
| interactive | Flags whether or not the user can select a row within the table, values=true|false | |
| updateModel | Tie the model selection to the table's selection | |
| TextArea | rows* | The number of rows |
| columns* | The number of columns | |
| wrap* | Turn wrapping on or off with a value of true or false | |
| wordwrap* | Turns wrapping at word breaks on or off with a value of true or false | |
| editable | Sets the editable property of a Swing edit component | |
| border* | Creates a line border if this attribute is found | |
| Page | class | The name of the page class to be used for this page's implementation |
| resource | The name of the resource bundle | |
| layout | The type of layout manger |
*applies to the Swing version of the component only
Startup Properties
The startup.properties file is a key file in controlling the behaviour of an application. This appendix documents the parameters in the startup file.
Properties
The list below contains the basic set of properties used by Aria. The properties file is a generic mechanism and can be used for other purposes such as application specific variables and therefore it cannot be guaranteed that this is an exhaustive list of values that can be found in the startup file.
| Property | Role |
|---|---|
| UseWindow | (true|false) Toggles use of a separate Window for the application. With a Window the application does not appear in the normal frame of the applet viewer and can appear as though it occupies the fullscreen (depending on the values of ClientWidth and ClientHeight). |
| ClientWidth | Width of the applet or application window in pixels, defaults to 640 |
| ClientHeight | Height of the applet or application window in pixels, defaults to 480 |
| StartPackage | The name of the package in which the page implementations are found e.g. com.mycompany.mypackage |
| StartClass | The name of the start page or the first page that is displayed. e.g. Welcome . The page name is qualified by prefixing it with the StartPackage name. If a value of NONEis given then no page is loaded. This can be useful when using framesets as the frameset may also specifies content for each of its areas and this could lead to unnecessary reloading of pages in the content area. |
| Title | The application title, shown on the main window. |
| StyleFile | The name of the file containing the style definitions, by default this is styles.xml |
| ModelData | The name of the file listing the datasets used by the application, by default this is datasets.xml |
| CenterWin | A boolean value (true|false) indicating whether or not the application window is to be centered on screen. |
| DataSourceClass | The name of the class that implements the datasource, by default this is org.formaria.data.OptionalDataSource |
| LibVisualise | A boolean indicating whether or not to show the visualizer. The visualizer allows you to see the data in the model at runtime. |
| Validations | The name of the file containing the validation rules, by default this is validations.xml |
| ValidationFactory | The name of an alternative validation factory class. |
| LogLevel | An integer value indicating the logging level used by the debug version of the application. |
| LifeCycleListener | The name of a class that implements the LifeCycleListener interface. This interface is used to perform special shutdown operations. |
| ComponentRegistry | The name of the XML file containing component registry information. |
| NumComponentFactories | Specify the extra component factories to use and the source of registry info |
| ComponentFactory0 | An entry like this is used for each component factory and names the class that implements the component factory. |
| BuilderClass | The name of the default builder class, normall org.formaria.builder.AriaBuilder |
| DefaultModelClass | Sets the default model class. Normally this is BaseModel . The model class has a major role in Aria applications and any changes to this parameter should be undertaken with caution. |
| SavePath | The output path for temporary or cached data. If this setting is not preset or if it is blank Aria will save data to the System specified temporary directory. |
| TriggerValidations | When set to true a page's validations are triggered prior to page transition and a failure in the validations will block the page transition. |
And some properties introduced with Aria 2.0:
| Property | Role |
|---|---|
| LAF | The class name of a Look and Feel installer. A look and feel installer includes a static method installLAF that carries out whatever steps are needed to install the look and feel. The method is called when the application first starts. |
| SynthConfigFile | The file used by the Synth look and feel for its configuration. |
| SynthResourceLoader | The class used by the Synth look and feel to load the resources referenced in the Synth configuration file. |
| AntiAlias | A value of true turns anti-aliasing on for all components within a Swing application. |
| LogWriter | Specify the class name of a log writer, for example org.formaria.log.QueueLogWriterwhich writes to the output stream in a background thread - this provides for better application performance during heavy logging. |
| ProjectPath | The root path of the project. This property is generated dynamically and does not appear in the properties file and is instead set during startup. |
And some properties introduced with Aria 3.0:
| Property | Role |
|---|---|
| BuilderClass[N] | The name of a builder class, where N is the number of the builder such that N is less than NumBuilderClasses2. An attempt is still made to load the default builder class via the bare BuilderClass property. |
| NumBuilderClasses | The number of builder classes to attempt to load. |
| DataBindingContextClass | Specifies a binding context class, an instance of which will be used to manage the PageHelper to manage the bindings. The class should implement the DataBindingContext interface. An example of this is the HibernateDataBindingContext which transparently starts the database transaction (hibernate session) before the bindings are evaluated. |
| DefaultTarget | If this value is set to NONE then the internal frames/desktop style of application will not attempt to set and load a default target area and this means that a desktop/internal frames application can be started without an initial document being required/displayed, i.e. an empty desktop provided that the frames file does not define frames or content areas. |
Embedding
Aria can be used to build applications for embedded devices and PersonalJava devices. Many differences exist between the lastest desktop Java VM and the VMs available for non desktop devices.
Choosing the JDK
The choice of JDK will depend on the various features available and how that feature set matches your requirements. For example on Windows CE platforms there are a number of JVMs available including Esmertec's Jeode and NSI's CreMe VMs. Licensing costs also vary between VMs and can be an important consideration.
While most VMs will at least support JDK 1.1.x there may even be differences between VMs at this level in terms of how the various libraries are implemented. An example of such differences can be found in the way various AWT widgets such as combo boxes are rendered on different VMs.
Some VMs support a more recent subset of the latest JDK but you will need to test such features to ensure that suitable behavior is obtained. It is not enough to test on the desktop and just deploy to an embedded device, but you probably knew that already.
Choosing the right libraries
In the underlying Aria platform some bits of code are excluded as they are not supported on early JVMs. For this reason a special build for the JDK 1.1.x compatible JVMs has been released (this also supports Internet Explorer's built-in JVM).
Rebuilding the libraries
If the JVM you are using does not match either the desktop or the JDK 1.1.x built then you will need to rebuild the Aria libraries.
Removing the shutdown hooks
The desktop build of Applet includes a shutdown hook for purposes of logging some summary information to the console when the JCM shuts down. To build for early JVMs it may be necessary to exclude the classes in the org.formaria.aria.build.optional package from the build.
Real-time support
We are currently working on adding support for real-time Java (via RTJS). For further information please contact Formaria directly.
Building
- Building Aria
The complete source for both Aria and AriaEditor is available from the SourceForge repository. The files are available in the Subversion repository and a few simple steps are needed to check out and build the projects.
Accessing SVN
The Subversion repository can be access anonymously either via the command line or via a tool such as SmartSVN or TortoiseSVN.
|
Parameter |
Value |
|---|---|
|
Server |
https://svn.sourceforge.net |
|
Path |
/svnroot/aria/ |
The projects require a number of support project, all of which you can check out from the repository to C:\SVN or the equivalent for Unix/Linux platforms. These projects are:
|
Project |
Role |
|---|---|
|
Aria |
The main Aria project |
|
AriaALL |
Builds the Aria NBM, NetBeans module |
|
AriaSuite |
Ties the various NBMs together. |
|
AriaEditor |
The AriaEditor editor NBM |
|
lib |
A collection of third party libraries |
|
javac |
JDK files |
The javac project is not completely contained in the repository due to licensing issues.
Preparing to build
Before building a couple of preparation tasks need to be performed:
1. Copy the contents of the JDKs to the javac project. The JDK 1.1.8, 1.3 and 1.5 files will be needed. At least the bin , lib and jre folders are required. The files are required to build the various versions of the Aria libraries
2. Update NetBeans (via the Tools|Update Center menu option) following the initial installation to ensure that the latest NetBenas module development support is available.
3. Open the Aria , AriaSuite and AriaEditor projects. In opening these projects other referenced projects may be opened, but you can close these.
4. Modify the common.xml file under the NetBeans/harness folder (under Program Files on Windows) so that:
is replaced with:
5. Check that the AriaEditor/src/nbproject/private/private.properties contains a value for module.excludes like:
module.excludes=**/net/Formaria/editor/eclipse/**/*
Building
Building the project should now be straightforward.
1. First build the Aria project by right clicking in the project view and choose Clean and Build All .
2. Now open the Aria module under the AriaSuite project. When the project opens (it should have a different icon to the main Aria project) build it, this creates the .nbm file for Aria project. This file is referenced by the AriaEditor module.
3. Build the AriaEditor module.
And that's it, you should be able to launch a new instance of NetBeans from within the IDE to run or debug the module.
Eclipse
The AriaEditor is available for Eclipse from the SourceForge repository. The Eclipse version shows some differences from the NetBeans plugin and this appendix is intended to guide you through some of the differences.Installing the plugin
Creating a new project
The process of creating a new Eclipse project is very similar to that described in A quick tour of the editor.html.
Accessing SVN
The Subversion repository can be access anonymously either via the command line or via a tool such as SmartSVN or TortoiseSVN.
|
Parameter |
Value |
|---|---|
|
Server |
https://svn.sourceforge.net |
|
Path |
/svnroot/aria/ |
The projects require a number of support project, all of which you can check out from the repository to C:\SVN or the equivalent for Unix/Linux platforms. These projects are:
|
Project |
Role |
|---|---|
|
Aria |
The main Aria project |
|
AriaALL |
Builds the Aria NBM, NetBeans module |
|
AriaSuite |
Ties the various NBMs together. |
|
AriaEditor |
The AriaEditor editor NBM |
|
lib |
A collection of third party libraries |
|
javac |
JDK files |
The javac project is not completely contained in the repository due to licensing issues.
Preparing to build
Before building a couple of preparation tasks need to be performed:
1. Copy the contents of the JDKs to the javac project. The JDK 1.1.8, 1.3 and 1.5 files will be needed. At least the bin , lib and jre folders are required. The files are required to build the various versions of the Aria libraries
2. Update NetBeans (via the Tools|Update Center menu option) following the initial installation to ensure that the latest NetBenas module development support is available.
3. Open the Aria , AriaSuite and AriaEditor projects. In opening these projects other referenced projects may be opened, but you can close these.
4. Modify the common.xml file under the NetBeans/harness folder (under Program Files on Windows) so that:
is replaced with:
5. Check that the AriaEditor/src/nbproject/private/private.properties contains a value for module.excludes like:
module.excludes=**/net/Formaria/editor/eclipse/**/*
Building
Building the project should now be straightforward.
1. First build the Aria project by right clicking in the project view and choose Clean and Build All .
2. Now open the Aria module under the AriaSuite project. When the project opens (it should have a different icon to the main Aria project) build it, this creates the .nbm file for Aria project. This file is referenced by the AriaEditor module.
3. Build the AriaEditor module.
And that's it, you should be able to launch a new instance of NetBeans from within the IDE to run or debug the module.
Widgets
- Widgets Sets
Aria and Aria support a number of widget sets, some sharing a common ancestory and others significantly different. Aria abstracts the widget concept so that it can work with various widget sets in a consistent way. The ability to handle multiple widget sets means that with certain limitations you can switch between widgets sets without having to change large parts of your application.
TODO - Lots
Widgets sets
Swing
Swing is probably the most sophisticated and best supported widget set supported by Aria. Most of the advanced graphcal components supported by Aria are Swing components and rely on the Java2D library for much of their power.
Swing is available on a wide variety of platforms, inlcuding some mobile devices. Swing's power really shines through on the desktop where it can be combined with technologies like Aria and Java Webstart to deliver compelling applications.
AWT
AWT, the original Java widget set lacks the sophistication of Swing but still allows powerful applications to be constructed. AWT has fewer components available than Swing, and this is reflected in Aria's support. The AWT and Swing widget support in Aria has been designed to allow easy switching rather than strict adherance to either API.
SWT
A major revision and implementation of the SWT widget set has taken place. The most important widgets are now wrapped and usable in Aria. The applet/application has also been updated to share the very latest Aria infrastructure. A number of helpers, utilities and layout components have also been included. Along with the core SWT development a sample SWT application manager has been included, the Aria International Soccer Manager, demonstrates how to build a complete application using Aria and SWT.
HTML
While Aria includes some HTML support it is incomplete and at the time of writing it should be considered experimental. The HTML support is designed to allow features of an application to be delivered via a web browser or to allow integration of Ajax like components.
J#
J# is a Microsoft .Net platform modelled on Java and the AWT. J# also includes some incomplete support for Swing like components. J# support may be of interest to those developers who must support devices where no JVM is available. Aria's J# support is functional, but should still be regarded as experimental.
Others
Some third parties have used Aria with other widgets sets on mobile devices (e.g. the LCDUI), please see the Aria forums for more information.
Widget abstraction
Portable coding
The ability to switch widgets sets is probably of most interest to developers of mobile applications who may have to support embedded applications. While Swing is becoming more widespread many mobile devices still do not support it and therefore AWT or SWT may be a more viable options.
Design considerations
Of course any common abstraction can make it difficult to support widget specific features and Aria's widget abstraction is no different. That said Aria does little to hinder access to native features, so you can still build the best possible UI.
The key to writing portable applications is to isolate the widget specific code as much as possible.
Modularity
Finding a JVM
Upgrading
- Upgrading
A significant number of changes have occured between version 1.0.4 of Aria and Aria 2.0. Many of these changes are barely noticeable but other include complete refactoring of components and subsystems and the deprecation of whole classes. This chapter covers some of the major issues involved in upgrading from previous versions of the Aria library.
Projects
In earlier versions of Aria a number of singletons were used to provide easy access to key classes and key resources. While this worked reasonably well for a single project it meant that multiple projects did not sit well with one another in the same JVM. The use of static references also complicated the initialization process and therefore the process of loading project resources.
Aria 2.0 does away with almost all of these statics and instead has one central reference point, the ProjectManager . The project manager class in effect now `owns' each project and is also the root of the object hierarchy. Each project in turn owns a set of manager classes (the classes that were singletons). Many of the reference methods to the singleton classes are still provided but they merely delegate to the ProjectManager and Project classes.
Many methods have now been expanded to include a reference to the owner project and in this way it is a little easier to ensure the correct object hierarchy. Many of the classes that use project references in this way include accessible member variables that store the project reference, for example the Page class now contains a protected member project .
Projects
As part of the restructuring of projects the ResourceManager has been deprecated and moved. The class was no longer consistent with the role of the project as the owner of resources. In most cases a reference to the ResourceManager can be replaced with a reference to the project and in the case of pages this reference is available in the parent class as mentioned above.
Page split
Another major change introduced in Aria 2.0 is the splitting of the Page class. The Page class is probably the most important class in the entire framework and contains many valuable methods. The class was part of the user interface component hierarchy and was therefore shared across widget packages. As the library has grown it has become more difficult to maintain this hierarchy without duplication and therefore we split the page class. Now most of the functionality of the class is provided by the PageHelper class.
Most of the time you should be unaware of the change. In some cases you may want to refer to the member variables in the class and for this reason access to the members has been deliberately left open.
The split also facilitates alternative page implementations, perhaps even for other platforms.
ComponentAdapters
The AWT and Swing widgets in Aria 1.0.4 all shared a common ancestor, the java.awt.Component class. Unfortunately this does not hold true for other widget sets include SWT and most other widget sets. To provide support for other widget sets we have abstracted the interaction between the framework and the widgets using a ComponentAdapter with concrete implementations of this interface being provided for Swing, AWT and SWT widget sets.
Widening of methods
One consequence of the broader support for widget sets is that we needed to widen some of the interfaces and hence many methods now take Object references where previously the took Component or Container references.
Some methods such as findComponent also now return Object references and you may need to cast the return value to the type you need.
Page references
The page class now has a number of member variables for convenience and to facilitate coding. These include references to the project and the model root. Please refer to the API document for more details.
New features
Some parts of the code and notably the examples have been changed to use new features introduced in Aria 2.0. Examples of this include the NavigationHelper class that now employs library functions whereas previously in necessitated a class derived from Page .
Aria 3.0 deprecates the NavigationHelper class as it no longer servers much use.
Deprecation
Several classes are now deprecated, these classes are moved to the org.formaria.deprecated package. The classes remain functional but be advised that we will probably drop the classes from the next major distribution of Aria.
Omitted components
Aria now relies of NetBeans to provide many of the editing facilities needed to build projects (of course you can still build applications using other tools). The NetBeans plug--in, Aria Editor is now a powerful tool with which to build Aria and Aria applications.
because of this move to the NetBeans platform the editor that was part of early distributions is now entirely omitted and will not be maintained. The new editor has a much richer feature set.