The In-built Config Tool in Outline

An Apache website operates like a billboard. Its resources are files the webmaster can create, edit, rename or delete at will. A resource file can be in error but this only becomes apparent when the resource is requested. Apache does not check the files upon creation or change. If you put nonsense in, you get nonsense out! It is common practice to trial files in a test location before moving them to their operational location. The billboard operation of Apache is simple and gives webmasters autonomy. Changes to the data object model may require the webmaster to coordinate efforts with the system administrator, but in the general case the webmaster acts alone.

In Dissemino web applications, individual files can be defined as passive resources and are served as-is. Directories can also be passive and any files placed in them automatically become passive. But this is the closest Dissemino gets to billboard operation. Since passive files are not processable by definition, use is limited to dispensing relatively static material such as the HadronZoo download tarfile. Passive directories commonly act as a repository of background generated periodic reports, but they are not widely used otherwise. Needless to say, passive resources are not the norm.

Most web application resources are not files! All resources have config XML held in a file, but for high performance, the resources and their components are actually objects within the Dissemino program space. This internal object model is built during the config read. A wholesale config read, of all web applications hosted by the Dissemino instance, in their entirity, occurs at startup. But startup is an event webmasters will normally have no control over. So in order to create a new resource, or edit an existing one, the config XML is created or edited first, and then parsed in to an already live system. At this juncture the internal object model holds the new or updated resources only as test material. Until it is formally accepted, browsers submitting the webmaster session cookie will see the test resources, but all other users will see only the currently accepted versions. Acceptance is a matter of hitting the accept button, at either the resource or the application level.

Config Tool Layout

The in-built config tool has the same AJAX operated split screen layout as this Dissemino Manual, with the navtree on the left and the selected article on the right, except that the articles are not inert. Some report stats while others contain forms for creating and editing webapp resources and data object entities. The navtree has three sections, as follows:-

1: Sphere Level Resources

2: The Data Model Section

Under the Data Model section are items for managing data model entities of enums, classes and repositories. These all work the same way. Already existing entities of the respective type appear as child items while the item itself will link to a blank form for creating a new entitiy. The forms are intended to be self explanatory. The forms for editing existing entitiies are essentially the same as the forms for creating new entities and they all follow the same format: A table of existing components, each with a delete/deactivate button, plus a blank line and an add button for adding new components.

3: The Application Resources Section

The Application Resources section is a mix of application config forms and reporting tools as follows:-

Who Can Do What

The options offered by the config tool depend on the jurisdiction. If the web engine hosts only a single webapp, the system wide data will be visible but changes will be limited to the applicable webapp. If multiple webapps are hosted, all resources from all the webapps will be visible, but unless otherwise determined by the applicable webmaster, changes will be restricted to internally hosted webapps only. The system administrator, does not have an automatic right to edit webapps, even when the web engine has the sphere of the standard ports.