[albatross-users] New release?

[Sheila King]

--On Saturday, September 20, 2003 4:18 PM +0100 Matt Goodall 
<matt at pollenation.net> wrote:

> On Sat, 2003-09-20 at 15:21, Sheila King wrote:
>> --On Saturday, September 20, 2003 10:57 PM +1000 Dave Cole
>> > I have spent most of today getting everything ready for a 1.20pre1
>> > release.
>>
>> Sound exciting. And time consuming.
>
> Absolutely! Thanks for spending your weekend (again!) on this.
>
>> > I want to include your new PageModuleMixin as I think it is the right
>> > way to go.  It will break some code - probably a good thing though.  I
>> > want Andrew to have a look at the new code before a final decision is
>> > made.
>>
>> Somehow I'm thinking the above remark doesn't apply to Matt's latest
>> cookie-path patch?
>
> You're right, it's not. It's about the way page modules are located and
> loaded. Basically, the 1.10 way can make a mess of sys.modules (the list
> of loaded modules). I sent a patch to Dave and Andrew that used
> execfile() to load the page module code rather than actually importing
> it. The big advantage is that execfile() does not touch sys.modules.
>
> I raised the page module loading problem in the list but, for some
> reason, Dave and I discussed much of the problem off list. IIRC, it was
> a quick "how are you" chat that turned into a "how to fix the page
> module loading" chat. If I find the time, I'll summarise the discussion
> and post it to the list so everyone else can see it too.
>
>> I've been meaning to post that I've been using it and it
>> seems to have solved the problems I had been reporting regarding
>> duplicate  cookies and corrupted sessions that I could not re-establish.
>>
>> Thanks again, Matt!
>
> Great stuff and no problem - it was incorrect for me too, I just hadn't
> noticed.
>
>> > Rather than import the page module you execfile() it.  This means that
>> > all classes defined in the page module look like they are defined in
>> > the __builtin__ module.  This causes problems if you ever place
>> > instances of these classes into the session...
>>
>> The above is over my head, as I am not that intimate with the Albatross
>> source and that level of development is beyond where I am personally
>> comfortable. However, for me, the last Albatross upgrade set me back two
>> weeks of trying to fix code that "broke" for me and allowed me to make
>> no  progress in my actual task at hand, just trying to scramble to get
>> my code  functioning again due to upgrading Albatross.
>>
>> Certainly gives me pause in considering to upgrade Albatross further if
>> it  is going to break stuff each time. Especially since for me, I have
>> no way  to install an upgrade without overwriting my current install. I
>> wish it  were possible to do an alt-install switch, like one can do with
>> Python, so  that you can easily have more than one version installed.
>
> I agree that it's bad that the code breaks but can you not use a staging
> server of some sort to test new releases?

No. Some of us just have little shared hosting accounts and no similar set 
up on our home systems, and no feasible way to do so. I would be in that 
group.

>> > As we are trying to promote the use of an MVC approach, it might be a
>> > good idea to discourage people from placing more than the most basic
>> > glue code (no class definitions) in page modules.
>>
>> I understand the reference to MVC approach, but I'm not sure what
>> exactly  is meant by trying to "discourage people from placing more than
>> the most  basic glue code (no class definitions) in page modules."
>>
>> Are you referring to classes I might write myself? Or page classes? or
>> what? How are the suggested changes expected to break code?
>
> The problem is classes you write yourself that are defined in the page
> module and whose instances are stored in the session.

Hmmm. Doesn't sound like anything I've done. I have written some of my own 
classes, but I've put them in separate files, because I wanted to be able 
to access them for multiple pages, and I'm not storing any instances of 
classes in sessions. Makes me feel a little better.

> The bottom line is that instances of a class **defined in a page
> module** cannot be pickled and so cannot be put in the session. This
> includes any TreeNode
> (http://www.object-craft.com.au/projects/albatross/albatross/tag-treenode
> .html) classes.
>
> The solution (if Dave and Andrew decide to go ahead with the change) is
> to move any page support classes into a proper package/module hierarchy,
> leaving _only_ the code immediately responsible for working with pages
> in the page module.
>
> Hope that provides a better understanding of code that might be
> affected.
>
> Cheers, Matt
>

Indeed, it does. I appreciate it. :)

-- 
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org