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
properties-document.
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/*/[EMAIL
PROTECTED]'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 - forrest.properties.xml
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
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?
- 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 :-)
Great.
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.
Wonderful.
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 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?
David has cleaned up a lot of forrest.properties 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
