At 20:14 18/01/2010, Nick Ager wrote:
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.
Hi Nick,
I'm developing a system where Pier is successfully used following an
approach which is close to (1), but there is no duplicated code/data,
etc. ) To keep the analogy with MVC, I use Pier as View & Controller,
but not as Model. The PRStructure hierarchy is used as an
"organization" medium for parts of my business model that need
visualization and user interaction. The latter are implemented by
PRViewComponens (WAComponents).
With your approach (2) there is indeed a risque of mixing model and
view, but all depends on your application domain. As already stated
by Lukas, if your business model elements "naturally fit into a
tree", then it would probably be "natural" to adopt this approach.
I won't recommend the 3rd approach since inconsistent with the design
of Pier, and unnecessarily complicated.
Hoping this helps,
Regards,
Reza