Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43C25EF7.90100@apache.org>
Date: Mon, 09 Jan 2006 13:02:47 +0000
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: The future (was Re: New skin: Coat)
References: <43B8CCC3.6000904@apache.org>
	 <1136238632.8522.40.camel@localhost.localdomain>
	 <43B9AF60.7030309@apache.org>
	 <1136246066.8522.97.camel@localhost.localdomain>
	 <eab855560601031309yc5c903aw@mail.gmail.com>
	 <1136412491.8288.37.camel@localhost.localdomain>
 <eab855560601082102k1d31dce5k@mail.gmail.com>
In-Reply-To: <eab855560601082102k1d31dce5k@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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