[albatross-users] New release?

[Matt Goodall]

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?

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

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


-- 
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenationinternet.com
e: matt at pollenation.net
t: +44 (0)113 2252500