18 Dec
2009
18 Dec
'09
12:13 p.m.
Folks,
I'm producing a internal website for my employer, (essentially a front
end for an ancient, somewhat-relation database...), and I've built a few
seaside components (by subclassing WAComponent) for this purpose.
I'm thinking that maybe the best way to structure the site is to allow
these seaside components (tabular displays, forms, etc) to be embedded
within Pier.
I've downloaded the Pier 1.2 image from the piercms.com site, have
loaded my seaside components in, and am able to create links to the
components fine.
My question is: how do I go about preserving the state of my components?
For example, a tabular report will have an ivar which holds a reference
to a query object, which itself holds (among other things) the name of
the database table. After creating the component and setting the table
name via the web browser, returning to the pier home page, and folling
the links to go back to my component, I'm actually given a new instance
of my component, which of course has newly initialized variables. (I can
see the new instances accrewing in the image by exploring
#allInstances.)
Presumably there is some mechanism within Pier for dealing with this.
What do I need to do with my components to tie into this?
Also, note that I'm not talking about achieving Magma-style object
persistence here; saving the image periodically will do just fine for my
purpose.
Thanks,
Nick
18 Dec
18 Dec
1:58 p.m.
My question is: how do I go about preserving the state
of my components?
That seems to be a bug that suddenly appeared. I've created a bug report.
http://code.google.com/p/pier/issues/detail?id=110
Normally components should preserve the state automatically. Every
embedding +mycomponent+ gets its own instance that will be cached
until the session expires. I'll look into this as soon as possible.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
2:24 p.m.
On Fri, 18 Dec 2009 13:58 +0100, "Lukas Renggli" <renggli(a)gmail.com>
wrote:
Normally components should preserve the state
automatically. Every
embedding +mycomponent+ gets its own instance that will be cached
until the session expires. I'll look into this as soon as possible.
Thanks Lukas.
Having the instance cached during the session sounds like the behaviour
I'd have expected to get by default, so it's good to know that is indeed
how things are supposed to be.
To avoid misunderstanding for anyone reading, I'll point out that this
potential bug is not the total answer to my original post. Essentially,
how do I get my component instances (or at least certain parts of their
state) to persist *beyond* the session, in much the same way as a newly
created page will persist?
Cheers,
Nick
3:44 p.m.
Having the instance cached during the session sounds
like the behaviour
I'd have expected to get by default, so it's good to know that is indeed
how things are supposed to be.
That's a very strange bug, because I have sites that depend on the
correct behavior. It must have been introduced recently, but I have no
idea where?
To avoid misunderstanding for anyone reading, I'll
point out that this
potential bug is not the total answer to my original post. Essentially,
how do I get my component instances (or at least certain parts of their
state) to persist *beyond* the session, in much the same way as a newly
created page will persist?
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.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
4:21 p.m.
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.
Cheers,
Lukas
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
following:
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.
I specify the view class by overriding #viewComponentClass, and the view
class will then be instantiated by Pier, as needed.
Referring to the model from the view, I see that the PBHtmlView class is
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?
Cheers,
Nick
6:45 p.m.
2009/12/18 Nick Brown <nickbrown(a)fastmail.fm>fm>:
PRStructure subclasses are for entities that get their own URL in the
tree of Pier pages. Structures are organized in a tree (see
http://www.piercms.com/doc/glossary).
Furthermore you can store any kind of model object in the unique
PRKernel instance or on any PRStructure using their property
dictionary.
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.
Cheers,
Lukas
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
following:
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. I specify the view class by overriding
#viewComponentClass, and the view
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 is
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
in.
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.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
7:11 p.m.
On 18/12/2009 17:45, Lukas Renggli wrote:
2009/12/18 Nick Brown<nickbrown(a)fastmail.fm>fm>:
Yes, that's what I'm talking about.
Referring to the model from the view, I see that
the PBHtmlView class is
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
in.
Ah.
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.
Lukas
Thanks for looking into that, and for the advice. I'll have a go at
adapting my classes along these lines on Monday.
Cheers,
Nick
19 Dec
19 Dec
5:25 p.m.
I've committed Pier-Seaside-lr.445 that is supposed to fix the issue
with the state (as well as some other minor problems with cookies and
restful URLs):
Name: Pier-Seaside-lr.445
Author: lr
Time: 19 December 2009, 5:03:04 pm
UUID: 7fcd6bbf-2855-47aa-9a3b-afc1a2855371
Ancestors: Pier-Seaside-lr.444
- fixes issue where components lost state when PRRestfulSession was
used (http://code.google.com/p/pier/issues/detail?id=110)
Lukas
2009/12/18 Nick Brown <nickbrown(a)fastmail.fm>fm>:
On 18/12/2009 17:45, Lukas Renggli wrote:
--
Lukas Renggli
http://www.lukas-renggli.ch
2009/12/18 Nick Brown<nickbrown(a)fastmail.fm>fm>:
Yes, that's what I'm talking about.
Referring to the model from the view, I see that the PBHtmlView class is
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
in.
Ah.
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.
Lukas
Thanks for looking into that, and for the advice. I'll have a go at adapting
my classes along these lines on Monday.
Cheers,
Nick
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
5249
days inactive
5250
days old
7 comments
2 participants
participants (2)
-
Lukas Renggli -
Nick Brown