forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [views] Change of processing paradigm of forrest
Date Sun, 31 Jul 2005 13:15:59 GMT
Diwaker Gupta wrote:
> On Saturday 30 July 2005 3:22 pm, Ross Gardler wrote:
>>><forrest:contract name="content-feeder">
>>>    <forrest:properties contract="content-feeder">
>>>      <forrest:property name="content-feeder"
>>>        <url>/feeds/somefeed.xml</url>
>>>      </forrest:property>
>>>    </forrest:properties>
>>My point is that I can already do the this same processing with:
>>   <header>...</header>
>>   <body>
>>     <xi:include src="/feeds/somefeed.xml"/>
>>   </body>
>>All that I can see that is changing is that in views the included src is
>>identified in a contract rather than in the original src document. I
>>agree that this allows us to separate the role of site designer and
>>content author, and this is great, but I do not see how this changes our
>>processing other than adding a new configuration location.
>>I'm afraid I'm just not getting the significance of what you are saying.
> Well how would you "skin" the content in this case? I think contracts offer a 
> very nice way of _encapsulating_ the content, and that is what makes them 
> attractive. Another advantage IMHO is that contracts can be parameterised 
> (for eg: the URL for the feed, or the name of the copyright owner)
> Contracts also make it *much* easier for users to control how Forrest 
> generates output. For instance, I might want that I include a custom heading 
> everytime I include an RSS feed -- how would you do that with a simple 
> <xi:include>? Its so easy to add and test a new contract -- I really like 
> that ability.

Please see my original mail in which I state that my example is only to
illustrate that views do not, in my opinion, change the processing
paradigm (see subject of thread) only that they provide a new, and
better, of way of defining what gets processed.

My point is not that xi:include should be used instead of views, just
that views are only a configuration not a fundamental change in the way
Forrest works. Which was the claim for this thread.


View raw message