forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: RT: Storage of Properties
Date Fri, 22 Feb 2008 19:44:51 GMT
On Fri, 2008-02-22 at 18:43 +0100, Ferdinand Soethe wrote: 
> 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.

Actually what you describe already exists and we are using it. The core

> 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

The last one is for me presentation.

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

skin and dispatcher can share resources as demonstrated with the fo
stuff. In the same way it is possible to share *-to-html stylesheets
between skins and dispatcher (if capsuled like in the pdf plugin).
However skins have one major different approach to dispatcher:
Skins await an aggregation (without it will not work at all) mix out of 
- content
- skinconf
- navigation
- tabs
This mix are normally used in one big stylesheet document-to-html.xsl
which makes it very hard to implement url specific stuff.

The dispatcher does not need any input to work, nor does it use "one big
stylesheet document-to-html.xsl". The structurer (based on jx) is used
to define which functionality should be used and passes extra
configuration parameter to the contracts.

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

Like I said in the other mail: "The only plugin that should
use skinconf is a skin plugin (if it would exist)!"

> = properties that add functionality or data to the 
> project as whole
>       a dispatcher file-change-date-component stores the 
> desired date-format

The property system should be decouple completely from any
presentational engine (being skin or dispatcher). 

If you look into
there I ported only three plugins/core functionality to
cocoon-2.2-blocks/. Meaning it is very much possible.

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

IMO that are presentational properties and should be handled and defined
from the presentational engine. The core should not process them. 

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

Both skins and the dispatcher work similar in this aspect.

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

That is why we have 

> But a skin might also offer defaults for pdf-output matching 
> the skins specific style.

If it is kept in the project properties there is no problem otherwise it
is hard to control which plugin has preference. AFAIR the one that is
first mentioned in the required plugins, but not sure.

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

Hmm, not sure what you mean with validation of properties.

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

Actually skinconf had become a mix of presentational properties and
other properties (like the fo ones). IMO one need to move (and flatten)
all common properties of skinconf into properties.xml files. This way
they got picked up by and are usable everywhere
in forrest.

> ** Clear hierarchical structure and inheritance **
> I'd much prefer inheritance to the current need of copying 
> new properties into existing project files.

Hmm, that is only true for skinconf. We have a fallback in place for That is the reason why I said "The user would
need to update/migrate/implement this changes to the properties file
(and only this changes since we are using fallbacks in properties)."

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

That is how works.

> A clear hierarchie should make it easy where to look.
> In order of decreasing priority
> project properties > skin/dispatcher properties > plugin 
> defaults > Forrest defaults

See the initialize() method there is the actual order but
skin/dispatcher properties are normal plugin 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.

yes, but it is not the skin that sets this properties but the project

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

is returning such properties if ask for the "properties" module.

> Meaning: Insert the 
> plugin-properties before the Forrest core properties, the 
> insert the skins
> properties before the plugin properties.

Actually for me skinconf/contract properties are apart from other
properties since they are normally view dependent.

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

If you enable the dispatcher and browse to
http://localhost:8888/index.props you will see what you describe. This
is not dispatcher specific but using
org.apache.forrest.plugin.output.inputModule/ to get all properties.

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

IMO properties files should be flat. Like and
the standard java properties. This way we have only one dtd/ng schema
and the validation is trivial.

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

This RT could become a good documentation about how our properties
configuration currently is working.

Thorsten Scherler                       
Open Source Java                      consulting, training and solutions

View raw message