Seaside components within Pier, and their state.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Seaside components within Pier, and their state.

Nick Brown
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
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Seaside components within Pier, and their state.

Lukas Renggli
> 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
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Seaside components within Pier, and their state.

Nick Brown
On Fri, 18 Dec 2009 13:58 +0100, "Lukas Renggli" <[hidden email]>
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

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Seaside components within Pier, and their state.

Lukas Renggli
> 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
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Seaside components within Pier, and their state.

Nick Brown
> 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
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Seaside components within Pier, and their state.

Lukas Renggli
2009/12/18 Nick Brown <[hidden email]>:

>> 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.

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.

> 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
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Seaside components within Pier, and their state.

Nick Brown
On 18/12/2009 17:45, Lukas Renggli wrote:

> 2009/12/18 Nick Brown<[hidden email]>:
>    
>> 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.
>    

Yes, that's what I'm talking about.

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Seaside components within Pier, and their state.

Lukas Renggli
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 <[hidden email]>:

> On 18/12/2009 17:45, Lukas Renggli wrote:
>>
>> 2009/12/18 Nick Brown<[hidden email]>:
>>
>>>
>>> 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.
>>
>
> Yes, that's what I'm talking about.
>
>> 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
>



--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki