forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] issues with wholepage
Date Fri, 18 Nov 2005 12:10:45 GMT
Thorsten Scherler wrote:
> El jue, 17-11-2005 a las 17:55 +0000, Ross Gardler escribió:
>>Thorsten Scherler wrote:
>>>The wholepage.html|.pdf is not really a real good way to generate
>>>article/document aggregation/collection. It is to static (even with the
>>>given configuration options) and limited to only *one* aggregation.
>>Yes, but it is quick and easy if what you want is wholesite.
> Yeah, but who wants really the *wholesite*? Normally you want parts.
> Thinking on lenya e.g. we need the whole documentation for 1.2 and 1.4
> but not the *whole* site.

Me :-))

For example, I have a site that contains nothing but documentation for a 
  product. I produce a wholesite (using the include method) to produce a 
book of the contents.

However, I do agree that often people want parts of a site, not the 
whole thing. All I am saying is that we should accomodate both use cases.

>>>It would be nice to see a document collection done with a structurer. It
>>>should be easy, one only have to include different content-main
>>>contracts. The only small problem will give the toc generation.
>>When I wrote my course notes I needed to create collections of notes 
>>grouped by each lecture (1-3hrs) and by module (3-9hrs). I did it by 
>>creating an XDoc with includes. This allows me to add lead in 
>>information to the collection and where necessary to each section within.
>>I was very happy with this approach.
> Yeah, that is as well a nice solution. Did you use cincludes or
> xincludes?

XIncludes. Of course, I should use CIncludes. I just never got around to 
changing the core pipelines.

>>>The advantage is that you can create as many collection as you want. :)
>>What would the advantage be over the above XDoc with includes approach?
> Not much I guess besides that you could apply different transformations
> for the approach with the structurer.

Can't I do that with the includes approach by providing a view 
definition for that document or the "directory" it is contained in? (in 
quotes because it may be a virtual directory defined by the locationmap).


View raw message