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 |
> 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 |
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 |
> 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 |
> 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 |
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 |
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 > > adapting my classes along these lines on Monday. Cheers, Nick _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
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 |
Free forum by Nabble | Edit this page |