forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Bolger <pbol...@gmail.com>
Subject Re: The future (was Re: New skin: Coat)
Date Mon, 09 Jan 2006 05:02:04 GMT
> Hmm, yes because the dispatcher is grown from skins and have to slimed
> down. The best way is to return a simple txt string. That would enhance
> the usability of the contract in different formats.


"...best way is to return a simple txt string" - could you explain
this a bit more?




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


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

Of course it may make more sense to have a number of contracts which
provide different variations on this. I was being a bit vague in the
previous email as I thought it would be a good start to tackle the
first part, matching, and get fancy later.

To me the current navigation scheme is has some shortcomings:  they
are generated from the two config files, site.xml and tabs.xml. One
problem with this is that it's manual - there is no advantage over
maintaining an SSI include navigation file, which is the way I'm
accustomed to working, and another disadvantage in that one is limited
to two navigation elements. (On reflection I'm probably wrong here...)
I often use rather a lot of indexing/link generating schemes in a site
(nav, sub nav, local - for long documents which need their own unique
navigation - news, archived news, positions vacant, etc etc.)


Another problem I have with the current nav contracts  (and, I know, I
do keep banging on about this...) is that there isn't enough control
over the output - I'm never going to use the classes which currently
get pasted onto pretty well every html element that Forrest puts out,
they are just extra code. With one exception - a mechanism to indicate
the current page - Forrest hooks provide enough control - that's what
CSS selectors are for - and the html generated at contract level
should be as plain as possible.

Looking towards 1.0 I think we should be looking at identifying the
parts of Forrest which not generic and trying make them optional.
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.


> > I think the appropriate time to do this would be immediately after the
> > official dispatcher release. Anyone interested in collaborating?
>
> Yeah, I am always up for that. ;-) ...but actually that should not be to
> hard to do. Just ask if you have problems.
>
Thanks Thorsten. I'll have another play and get back to you when I get
stuck, which will be soon :)

Mime
View raw message