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"
nugget="get.nugget.feeder">
<url>/feeds/somefeed.xml</url>
</forrest:property>
</forrest:properties>
</forrest:contract>
My point is that I can already do the this same processing with:
<document>
<header>...</header>
<body>
<xi:include src="/feeds/somefeed.xml"/>
</body>
</document>
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.
Ross
