forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scherler....@juntadeandalucia.es>
Subject Re: RT: Storage of Properties
Date Mon, 25 Feb 2008 13:15:03 GMT
On Sun, 2008-02-24 at 21:15 +0100, Ferdinand Soethe wrote:
> Thorsten Scherler wrote:
...
> >>> The structurer (based on jx) is used
> >>> to define which functionality should be used and passes extra
> >>> configuration parameter to the contracts.
> 
> I may have gotten this wrong, but it looks like these params 
> are embedded in the structurer/contract files instead of a 
> properties-document.

They can be in the structurer or contract or coming from
forrest.properties.

> 
> If this is so I wonder why.

To make it possible to change the values for e.g. specific urls.

> 
> If dispatcher/structurer is to replace skins the 
> configuration options need to be simple.

IMO it is.

> 
> Is it possible to have a properties-files for contracts and 
> a additional layer of properties for a structurer configuration?

Hmm, I think you need to get a wee bit familiar with the dispatcher
since I tried to clarify the above point within the last couple of mails
but it seems I failed. Maybe somebody else can find better wording for:
"So you see the dispatcher implements following configurations:
- global - forrest.properties.xml
  Accessible via <xsl:param name="defaultVariables" /> in any contract.
- theme/url specific via structurer/panel"

> 
> > 
> > However each contract can as well access all forrest properties (e.g.
> > index.props in a dispatcher project will show them) by implementing
> > following lines:
> > <!-- If you need default variables: -->
> > <xsl:param name="defaultVariables" select="'test.html'"/>
> > <!-- then extract the variable like: -->
> > <xsl:variable name="skin-img-dir" select="$defaultVariables/*/*[@name='skin-img-dir']/@value"/>
> 
> I'm not sure I understand this, but it looks to me like a 
> way to access the project properties.

Exactly.

> 
> Yet what I'm looking /asking for is a way to offer a default 
> configuration of a "skin" 

theme

> created with dispatcher/structurer 
>    so that I can create a ready made "skin" w/o the user 
> having to set additional properties but with the option of 
> changing them in a properties file if they want/need to.

That are the files provide by the core.theme plugin. see 
whiteboard/plugins/org.apache.forrest.themes.core/themes
.
|-- coat.fv
|-- common.fv
`-- pelt.fv

Which are the default configuration for the coat, common and pelt
theme. 
...
> >>> 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.
> > 
> > The two blocks 
> > - locationmap/
> > - propertiesGenerator/
> > 
> > are mainly responsible for the configuration of forrest. However in the
> > above case they are decoupled from the core.
> 
> Ah, so you have done work there to decouple this once we 
> move to cocoon-2.2-blocks?

yes. If we update to 2.2 then they will as blocks.

>   ...
> 
> >> But why flatten? What's wrong with bundling properties that 
> >> belong together in a parent element?
> > 
> > With flatten I mean: 
> > 
> > In forrest.properties or forrest.properties.xml. That would mean to
> > flatten some 
> > <pdf>
> >    ...
> >     <page size="letter" orientation="portrait" text-align="left"/>
> > 
> > into e.g. forrest.properties.xml:
> > <properties>
> >   <property name="pdf.page.size" value="letter"/>
> >   <property name="pdf.page.orientation" value="portrait"/>
> >   <property name="pdf.page.text-align" value="left"/>
> > 
> > The hierarchy is reflected in the name. 
> 
> Yes I see that. But why do that. After all one of the 
> beauties of xml-config files is the ability to use true 
> propertie-hierachies rather then the look a like of 
> dot-notation.
> 
> What I'm trying to understand is why hierarchies are bad or 
> harder to use?

ForrestConfModule.java (line 326)

 if (nl != null && nl.getLength() > 0) {
                    for (int i = 0; i < nl.getLength(); i++) {
                        Element el = (Element) nl.item(i);
                        filteringProperties.setProperty(
                                el.getAttribute("name"), el
                                        .getAttribute("value"));
                    }
                }

It is bad since it will not work due to above code snippet. ;)


...
> >> Why are the plugins wedged in between the xml and the 
> >> non-xml-version of the default properties.
> > 
> > Not sure myself.
> > 
> >> Would it not make more sense to load them after both?
> > 
> > Yeah, why not.
> 
> Can we change this right away before writing the documentation?

Yeah, it is just moving a couple of lines down in the code.

> 
> >> Cool!
> >> Can I also get a list where the source of a setting is 
> >> shown? How about adding the source of a setting as a third 
> >> element?
> >>
> > 
> > Yeah would be possible, what would be the benefit?
> 
> The benefit would be the easy of tracking down where a 
> property originated. Rather than checking perhaps a dozent 
> or more properties files (if all the places are used).

Yeah understand, the thing is it will cause some work to do so since all
involved classes need to be changed. It should be possible but will
cause lots of work.

> > Perfect, hopefully somebody can find the time to document the outcoming
> > of the thread.
> 
> I volunteer to document the properties mechanism.

Wonderful, thank you very much.

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Mime
View raw message