Re: project based pier

Thanks for the replies, they've clarified my thinking and helped me formulate my real question :-) Continuing with squeaksource as an example, in a hypothetical simplified implementation it might use a model consisting of a collection of projects & 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: 1) Create a Pier hierarchy of pages which mirror the model and potentially duplicate the data within it 2) Use the Pier page hierarchy as the model 3) Use the model to dynamically create Pier pages during a request. As I see it there are problems with all three approaches: Solution (1) duplications data, with all the inherent issues around synchronising the two object hierarchies Solution (2) mixes model and view. Solution (3) also mixes the model and view and would seem to subvert the intention and elegancy of Pier. Perhaps the solution is to mix Pier and a more 'traditional' 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 'traditional' seaside components. For example /projects/gofer/wiki/anotherpage would split the URL handling between the model handling the '/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's data is still at the very early stages. Hope this makes sense. Any thoughts? Nick