forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject RT: Storage of Properties
Date Fri, 22 Feb 2008 17:43:02 GMT
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 
     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 

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 
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 
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.



View raw message