forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject Re: RT: Storage of Properties
Date Sun, 24 Feb 2008 20:15:20 GMT
Thorsten Scherler wrote:

> Hmm, since a logo is only visible in presentation its for me
> presentational. 

If that was the criterion then text content would also be 
presentational because it only becomes visible when presented.

 From a different angle: A logo is not a way to present 
something else. The logo is this something else. It is data.

Presentation of a logo could be where it is placed, how it 
is sized or if it gets grayscales for printing (though 
ci-experts would question even this as manipulation the data)

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

If this is so I wonder why.

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

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

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

Yet what I'm looking /asking for is a way to offer a default 
configuration of a "skin" 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.
> So you see the dispatcher implements following configurations:
> - global -
>   Accessible via <xsl:param name="defaultVariables" /> in any contract.
> - theme/url specific via structurer/panel

I understand that I really need to play with your baby a lot 
more to know what you are saying.

>>> If you look into 
>>> 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?

>> - to add styling hints that suggest to the presentational
>>    engine how these classes could be presented.
> That is very much possible (not for skins but for dispatcher). Skins are
> very limited in this context since plugin cannot add output specific
> processing to skins. However that is not true for the dispatcher. e.g.
> the solr plugin is a very good example where we do this.

Wow! Now you have me hooked. Will look at that plugin.

>> As a result a plugin can at best add class attributes (and 
>> hope they don't disappear) and the user can then either 
>> accept that their classes "instruction step" or "instruction 
>> result"  or "board members" will all look the same (perhaps 
>> like a bulleted list) or they take the extra step of adding 
>> extra css or adjusting the skin or a contract.
> css is always presentational. All above is a problem of skins but is
> solved in the dispatcher.

Oops. I've missed that. Too much playing with my son :-)

>> And that is what I see as breaking the plugin-concept here.
> No the plugin-concept works very fine as it is IMHO.
>> By being able to offer style hints, an input-plugin could 
>> pass the information that the list of board members might 
>> look good with a little people logo in front of it.
> This is perfectly possible with the current code.

>>  And the 
>> "skinning" could then deside to take that hin, do something 
>> of its own with a class or ignore the class and hint altogether.
> That is how dispatcher work but not skins. You describe the many
> problems of skins as presentational engine but the dispatcher solves all
> of the above.

Sorry, yes. I seem way behind with understanding your work.


>> But why flatten? What's wrong with bundling properties that 
>> belong together in a parent element?
> With flatten I mean: 
> In or That would mean to
> flatten some 
> <pdf>
>    ...
>     <page size="letter" orientation="portrait" text-align="left"/>
> into e.g.
> <properties>
>   <property name="" value="letter"/>
>   <property name="" value="portrait"/>
>   <property name="" 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 

What I'm trying to understand is why hierarchies are bad or 
harder to use?

> David has cleaned up a lot of files to only add what
> is needed. We are close to a blank file.

Bless you, David.

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

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

> Perfect, hopefully somebody can find the time to document the outcoming
> of the thread.

I volunteer to document the properties mechanism.

Best regards,
Ferdinand Soethe

View raw message