From jborden23 at mac.com  Sun Dec 13 05:04:41 2009
From: jborden23 at mac.com (John Borden)
Date: Sat, 12 Dec 2009 22:04:41 -0600
Subject: IP address from Session
Message-ID: <AB25EC35-4801-4654-9751-91B26A2B7858@mac.com>

Pier experts,
Does anyone know if it is possible to get the user's IP address from  
the Session object?  Inspecting into it doesn't show anything like  
this, but I didn't know if anyone has made a custom session that  
stores this.

Thanks,
John

Also - Does anyone know why seasidehosting.st is down?

From renggli at gmail.com  Sun Dec 13 11:13:08 2009
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 13 Dec 2009 11:13:08 +0100
Subject: IP address from Session
In-Reply-To: <AB25EC35-4801-4654-9751-91B26A2B7858@mac.com>
References: <AB25EC35-4801-4654-9751-91B26A2B7858@mac.com>
Message-ID: <67628d690912130213y4f9c889exf5fb4b2a192b5f72@mail.gmail.com>

The session doesn't store it (it might change), but you can ask the
current request object:

    self seaside currentRequest nativeRequest remoteAddress

Lukas

2009/12/13 John Borden <jborden23 at mac.com>:
> Pier experts,
> Does anyone know if it is possible to get the user's IP address from the
> Session object? ?Inspecting into it doesn't show anything like this, but I
> didn't know if anyone has made a custom session that stores this.
>
> Thanks,
> John
>
> Also - Does anyone know why seasidehosting.st is down?
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
http://www.lukas-renggli.ch


From nickbrown at fastmail.fm  Fri Dec 18 12:13:28 2009
From: nickbrown at fastmail.fm (Nick Brown)
Date: Fri, 18 Dec 2009 11:13:28 +0000
Subject: Seaside components within Pier, and their state.
Message-ID: <1261134808.24648.1350740723@webmail.messagingengine.com>

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

From renggli at gmail.com  Fri Dec 18 13:58:38 2009
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 18 Dec 2009 13:58:38 +0100
Subject: Seaside components within Pier, and their state.
In-Reply-To: <1261134808.24648.1350740723@webmail.messagingengine.com>
References: <1261134808.24648.1350740723@webmail.messagingengine.com>
Message-ID: <67628d690912180458s55ad4ae6l61ba9daad04a6719@mail.gmail.com>

> 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

From nickbrown at fastmail.fm  Fri Dec 18 14:24:59 2009
From: nickbrown at fastmail.fm (Nick Brown)
Date: Fri, 18 Dec 2009 13:24:59 +0000
Subject: Seaside components within Pier, and their state.
In-Reply-To: <67628d690912180458s55ad4ae6l61ba9daad04a6719@mail.gmail.com>
References: <1261134808.24648.1350740723@webmail.messagingengine.com>
	<67628d690912180458s55ad4ae6l61ba9daad04a6719@mail.gmail.com>
Message-ID: <1261142699.8904.1350755867@webmail.messagingengine.com>

On Fri, 18 Dec 2009 13:58 +0100, "Lukas Renggli" <renggli at 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


From renggli at gmail.com  Fri Dec 18 15:44:01 2009
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 18 Dec 2009 15:44:01 +0100
Subject: Seaside components within Pier, and their state.
In-Reply-To: <1261142699.8904.1350755867@webmail.messagingengine.com>
References: <1261134808.24648.1350740723@webmail.messagingengine.com>
	<67628d690912180458s55ad4ae6l61ba9daad04a6719@mail.gmail.com>
	<1261142699.8904.1350755867@webmail.messagingengine.com>
Message-ID: <67628d690912180644w5970e29ekb7039a69d88d0f62@mail.gmail.com>

> 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

From nickbrown at fastmail.fm  Fri Dec 18 16:21:08 2009
From: nickbrown at fastmail.fm (Nick Brown)
Date: Fri, 18 Dec 2009 15:21:08 +0000
Subject: Seaside components within Pier, and their state.
In-Reply-To: <67628d690912180644w5970e29ekb7039a69d88d0f62@mail.gmail.com>
References: <1261134808.24648.1350740723@webmail.messagingengine.com><67628d690912180458s55ad4ae6l61ba9daad04a6719@mail.gmail.com><1261142699.8904.1350755867@webmail.messagingengine.com>
	<67628d690912180644w5970e29ekb7039a69d88d0f62@mail.gmail.com>
Message-ID: <1261149668.25262.1350773707@webmail.messagingengine.com>

> 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

From renggli at gmail.com  Fri Dec 18 18:45:52 2009
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 18 Dec 2009 18:45:52 +0100
Subject: Seaside components within Pier, and their state.
In-Reply-To: <1261149668.25262.1350773707@webmail.messagingengine.com>
References: <1261134808.24648.1350740723@webmail.messagingengine.com> 
	<67628d690912180458s55ad4ae6l61ba9daad04a6719@mail.gmail.com> 
	<1261142699.8904.1350755867@webmail.messagingengine.com>
	<67628d690912180644w5970e29ekb7039a69d88d0f62@mail.gmail.com> 
	<1261149668.25262.1350773707@webmail.messagingengine.com>
Message-ID: <67628d690912180945h6bf55f6dy61b5aa1b01bea605@mail.gmail.com>

2009/12/18 Nick Brown <nickbrown at 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.
>>
>> 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

From nickbrown at fastmail.fm  Fri Dec 18 19:11:25 2009
From: nickbrown at fastmail.fm (Nick Brown)
Date: Fri, 18 Dec 2009 18:11:25 +0000
Subject: Seaside components within Pier, and their state.
In-Reply-To: <67628d690912180945h6bf55f6dy61b5aa1b01bea605@mail.gmail.com>
References: <1261134808.24648.1350740723@webmail.messagingengine.com>
	<67628d690912180458s55ad4ae6l61ba9daad04a6719@mail.gmail.com>
	<1261142699.8904.1350755867@webmail.messagingengine.com>	<67628d690912180644w5970e29ekb7039a69d88d0f62@mail.gmail.com>
	<1261149668.25262.1350773707@webmail.messagingengine.com>
	<67628d690912180945h6bf55f6dy61b5aa1b01bea605@mail.gmail.com>
Message-ID: <4B2BC5CD.7030307@fastmail.fm>

On 18/12/2009 17:45, Lukas Renggli wrote:
> 2009/12/18 Nick Brown<nickbrown at fastmail.fm>:
>    
>> 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

From renggli at gmail.com  Sat Dec 19 17:25:43 2009
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 19 Dec 2009 17:25:43 +0100
Subject: Seaside components within Pier, and their state.
In-Reply-To: <4B2BC5CD.7030307@fastmail.fm>
References: <1261134808.24648.1350740723@webmail.messagingengine.com> 
	<67628d690912180458s55ad4ae6l61ba9daad04a6719@mail.gmail.com> 
	<1261142699.8904.1350755867@webmail.messagingengine.com>
	<67628d690912180644w5970e29ekb7039a69d88d0f62@mail.gmail.com> 
	<1261149668.25262.1350773707@webmail.messagingengine.com> 
	<67628d690912180945h6bf55f6dy61b5aa1b01bea605@mail.gmail.com> 
	<4B2BC5CD.7030307@fastmail.fm>
Message-ID: <67628d690912190825u451dd7d3v3f63b82ca4885e45@mail.gmail.com>

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 at fastmail.fm>:
> On 18/12/2009 17:45, Lukas Renggli wrote:
>>
>> 2009/12/18 Nick Brown<nickbrown at fastmail.fm>:
>>
>>>
>>> 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