Paul Bolger wrote:
it is *really* easy. The best way to start is to write a custom theme.
I'll give it a go - tried renaming contracts and couldn't get it to
work. I'd be interested to learn more about the relationship between
themes and contracts - I presume that contracts are somehow
'registered' with their parent theme. Where is this set?
They are "registered" by virtue of being found by Forrest, there is no
formal registration. Given that requesting "ls.contracts.html" gives a
list of the available contracts [1] you could find out how this list is
created:
[OT] Unfortunately, following how this is done in the code is *really*
difficult due to the amount of indirection between the locationmap and
the sitemaps. There is even indirection from the structurer sitemap to
the themer locationmap and back to the structurer sitemap (now I really
understand Tims request to avoid such indirection, I was about to write
the various snippets that result in the contracts being resolved so that
all could benefit, but it's just too complicated - we need to sort this
out). Instead I have gone for an unifmormative answer rather than an
informative explanation....
Basically if a plugin is found in one of the themer contracts
directories or the projects contracts directory it will be used when
appropriate. That is:
org.apache.forrest.plugin.output.themer/resources/themes/common/html/
org.apache.forrest.plugin.output.themer/resources/themes/pelt/html/
org.apache.forrest.plugin.output.themer/resources/themes/mycustomtheme/html/
(see recent discussion about theme plugins that will allow you to
provide them in a new type of plugin)
or...
PROEJECT_HOME/src/documentation/resources/themes/common/html/
PROEJECT_HOME/src/documentation/resources/themes/pelt/html/
PROEJECT_HOME/src/documentation/resources/themes/mycustomtheme/html/
I note that this information is not clearly expressed in [1], perhaps
you could provide a patch for that doc.
- a set of
contracts to produce very plain lists of links according to various
criteria would be very useful.
What do you mean with this?
A bit of background: The sort of websites I produce use a lot of lists
of links, and a lot of time-based publishing. A good example of this
is the 'news' style element, which usually appears on the front page.
This is a list of the four most recent items from a 'news' directory,
and will usually have the title and first sentence of the story with a
link to the whole document. From what I understand of Forrest there is
no reason why it shouldn't be possible to have a contract which
performs the following:
match documents using criteria x, criteria y etc
optionally limit the list by a number, date etc
sort matching documents by x
generate list of urls (with some fancy regular expressions stuff to
make the list mean more for humans!) inside a standard html unordered
list.
Have you got the news sources in RSS? If so use the Feeder
plugin/contract. (note that contract should now be moved to the feeder
plugin since we now have that capability)
Yes it is possible, and I would say, desireable.
Looking towards 1.0 I think we should be looking at identifying the
parts of Forrest which not generic and trying make them optional.
That's the intention of the plugin system and the dispatcher system.
Another example of Forrest specific would be the 'warning', 'fixme'
etc classes. It would be vastly preferable to be able to add custom
classes/elements if one needed them and to keep the central document
types as neutral as possible.
Yes, see our intended move to XHTML2.
Ross
[1]
http://forrest.apache.org/docs_0_80/howto/howto-structurer-dsl.html#firststructurer
