Thanks for the replies, they&#39;ve clarified my thinking and helped me formulate my real question :-)<div>Continuing with squeaksource as an example, in a hypothetical simplified implementation it might use a model consisting of a collection of projects &amp; users. Each project would contain a list of packages with each package having a list of package versions. With my limited knowledge of Pier a couple of implementations seem possible:</div>
<div>1) Create a Pier hierarchy of pages which mirror the model and potentially duplicate the data within it</div><div>2) Use the Pier page hierarchy as the model</div><div>3) Use the model to dynamically create Pier pages during a request.</div>
<div><br></div><div>As I see it there are problems with all three approaches:</div><div>Solution (1) duplications data, with all the inherent issues around synchronising the two object hierarchies</div><div>Solution (2) mixes model and view.</div>
<div>Solution (3) also mixes the model and view and would seem to subvert the intention and elegancy of Pier.</div><div><br></div><div>Perhaps the solution is to mix Pier and a more &#39;traditional&#39; seaside approach, where the view would reflect off the model when the data is well structured, and Pier components would be used in places where the content is more free-form.  However this implementation would seem complex as the URL handling will be shared between Pier and &#39;traditional&#39; seaside components. For example /projects/gofer/wiki/anotherpage would split the URL handling between the model handling the &#39;/projects/gofer/wiki and Pier handling wiki/anotherpage.  Also the data would potential reside in two places - the Pier kernel and the model - though my understanding of how pier persists it&#39;s data is still at the very early stages.</div>
<div><br></div><div>Hope this makes sense. Any thoughts?</div><div><br></div><div>Nick</div>