2009/12/18 Nick Brown <nickbrown(a)fastmail.fm>:
> Components are view and controller. If you have data that should
> persist across sessions, you should put it into a separate model
> object. Pier stores its model in the PRKernel instance, that refers to
> a tree of PRStructure objects, and others.
Ok. I've been looking at PBBlog and related classes for a few hints
about this. By all means shout out if I'm wrong about any of the
I want my persistent state to be in a model object which is subclassed
from PRObject (or from PRStructure, if it is to contain child pier
components). Pier will then persist the model instances for me, within
the PRKernel root structure.
PRStructure subclasses are for entities that get their own URL in the
tree of Pier pages. Structures are organized in a tree (see
Furthermore you can store any kind of model object in the unique
PRKernel instance or on any PRStructure using their property
I specify the view class by overriding #viewComponentClass, and the
class will then be instantiated by Pier, as needed.
Yes, for PRStructure subclasses.
Referring to the model from the view, I see that the PBHtmlView class
using #find: to locate any instance of its model class within the tree.
That seems a bit, um, unpredictable for my purpose. Is it a good
practice to refer back to the model from the view by calling "self
context structure", or is there a better way of doing it?
In MVC the view knows the model, not the other way round though.
The reason for #find: is that the blog aggregates its children the
posts, as well as the posts need to know the blog they are contained
BTW, I spent half an hour in a cafe here figuring out the problem of
the components loosing state. Looks like the RESTful URL introduces a
subtle problem here. As a quick workaround I suggest that you go to
the Seaside application configuration and change the session class
from PRRestfulSession to WASession. Clear all cookies in your web
browser and clear all sessions by evaluating "WARegistry
clearAllHandlers". Then it should work again.