Let me know if this is completely off track, but I'm
thinking about how best to store properties
with so many different components needing to store and
access properties.
Here are some of my thoughts:
Who needs to be able to create properties?
=============================
- Core
creates properties, sets default values, allows
overriding these values in a project
= properties for very basic settings such
jetty port, plugins used
= project properties
copyright, logos etc
- Skins and/or Dispatcher-Components
(I'd like to keep at least one skin - which may be a
dispatcher configuration -
as a very easy to use and manipulate default)
create properties, set default values, allow overriding
these values in a project
= properties for look and feel
interface layout, css, colors etc
(Note: Even if we completely switch to dispatcher, I'd
like to keep functionalities
of the skin to show ore hide components or
place them differently, even
though this could also be accomplished with
dispatcher programming)
= properties that add functionality or data to the
project as whole
a dispatcher file-change-date-component stores the
desired date-format
- Plugins
create properties, set default values, allow overriding
these values in a project
= plugin-dependant properties
page format and other settings specific to pdf-generation
= specific css to be used when generating html from an
input-plugin
Each input-plugin could tag there input with ids or
classes and influence
final formatting by offering a css-block to be inserted
at the end of the Forrest
css and before user css-files.
What needs to be considered/what is desirable
===============================
** Overlaps **
Many properties will be used and might even be set by
different components.
For example the pdf-plugin might come with a basic set of
properties and defaults.
But a skin might also offer defaults for pdf-output matching
the skins specific style.
On the other hand, the pdf-plugin will probably need to read
some core properties to
generate the copyright footer.
** Validation **
The ability to validate a properties-storage should be kept
while the process of extending
the property set in plugins or skins should be simplified.
Blocks of included data that hinder validation (such as
extra-css in skinconfig) should be
avoided. Grammatically different information like css or
xml-properties should be kept separate.
** Clear hierarchical structure and inheritance **
I'd much prefer inheritance to the current need of copying
new properties into existing project files.
New properties should automatically become available to all
projects and entries in project-files would
only be required if I wanted to set the property different
from the default.
A clear hierarchie should make it easy where to look.
In order of decreasing priority
project properties > skin/dispatcher properties > plugin
defaults > Forrest defaults
This also means that a skin can, but doesn't need to set
anything for pdf-generation if it didn't want to change
anything.
Technical implementation
=================
How about building a pipeline that prepends the basic
Forrest properties with xml-data from configuration files
on a higher level of priority. Meaning: Insert the
plugin-properties before the Forrest core properties, the
insert the skins
properties before the plugin properties.
This way it is technically very simple to catch the property
with the highest priority but there is also the option to
address
other levels if needed. What's more, a simply call of that
pipeline will show you the complete configuration in you
browser and
(if the pipeline aggregation inserts useful comments) you
can see right away where a certain property came from.
Validation is tricky. Ideal would be that every source of
properties publishes a realx-NG grammar-module in a way that
all
modules can be aggregated in a pipeline. This way the
modules can be used to validate properties at the source but
also to
validate a single common properties-file for the project.
wdyt
Ferdinand
