project based pier
nick.ager at gmail.com
Mon Jan 18 20:14:28 MET 2010
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the smallwiki