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

Thanks for the clarification. If I've understood correctly, the best way to go is to subclass PRStructure for my model classes so that the model objects can be used directly by Pier, otherwise I'd end up having a duplicate Pier structure mirroring my model objects. The disadvantage of this is that the framework infects my classes; using Java terminology they are no longer POJOs [1], or have I missed something? Would the combined approach, I attempted to outline in the previous message be overly complex to implement? I can image that splitting the url handling, and model between two structures could require lots of patching before they interoperate successfully. [1] http://en.wikipedia.org/wiki/Plain_Old_Java_Object

Thanks again for the help. I understand the delegate model, but I'm still concerned about the inherent duplication of the delegates mirroring the model objects. In your example wouldn't there be collections of custom Pier structures so that there would be at least one Pier structure for each University, Student, course and exam, assuming that it was possible to use Pier to navigate to each of the model objects. Perhaps this is a non-issue, but I'd be concerned about keeping the delegates and delegees in sync. Would combining the approaches work? The opening pages would use Pier to allow easy updating, however links to courses, students, exams etc would use procedural navigation code feeding off the model, and finally Pier could be used within the leaf nodes to allow courses, students etc to have wiki structured content. Ideally all bookmarkable, and the model would capture the wiki content created at the leaf nodes. Perhaps I'm making it more complicated then it needs to be?