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 is: https://svn.apache.org/repos/asf/forrest/trunk/main/java/org/apache/forrest/conf/ForrestConfModule.java > > 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 https://svn.apache.org/repos/asf/forrest/trunk/whiteboard/cocoon-2.2-blocks/ 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 default.plugin.properties.xml > 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 ForrestConfModule.java 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 forrest.properties et.al. 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 ForrestConfModule.java 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 configuration. > > 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. The https://svn.apache.org/repos/asf/forrest/trunk/plugins/org.apache.forrest.plugin.output.inputModule/ 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 forrest.properties/~.xml 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. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
