From andrewm at object-craft.com.au  Sun Apr 17 19:16:12 2005
From: andrewm at object-craft.com.au (Andrew McNamara)
Date: Sun, 17 Apr 2005 19:16:12 +1000
Subject: [albatross-users] <alb-form> xhtml 'strict' conformance 
In-Reply-To: <20050328171029.7ffbe57c@vulcan> 
References: <20050328171029.7ffbe57c@vulcan>
Message-ID: <20050417091612.47951794091@longblack.object-craft.com.au>

>I have a suggestion for a slight change of the behaviour of the <alb-form>
>tag. Depending on what Context class one is using, hidden <input>-tags
>containing __albform__ and/or __albstate__ are appended just before
>closing the form.
>
>Since in 'strict' XHTML putting an <input> tag directly inside a <form> is
>illegal,

Sigh - you are quite correct.

>I would suggest enclosing the tag with a <div>. Since the
>contents are not rendered (they are hidden, afterall), the <div> produces
>a box of zero proportions and therefore should not hurt (tested with
>Gecko, KHTML and Opera engines, could anyone check on IE?).
>
>What do you think? At the moment I have patched my albatross copy, but I
>find that a sub-optimal solution (since I have to pin the package on my
>system or it might be overwritten in the future, preventing it from
>getting future bugfixes).

I think your suggestion appropriate. I'll make the change. Thanks for the
heads-up.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/


From sheila at thinkspot.net  Tue Apr 19 17:00:15 2005
From: sheila at thinkspot.net (Sheila King)
Date: Tue, 19 Apr 2005 00:00:15 -0700
Subject: [albatross-users] Python 2.4.1 incompatibility with al-for ?
Message-ID: <861F8B78A7EF59F366549D8F@[192.168.1.102]>

Hello,

I was wondering if anyone has any experience with this situation...

We have an albatross application that we have been running with the latest 
albatross on Python 2.2.2 since December 2004 without event (other than our 
own bugs)

We were preparing to upgrade to Python 2.4.1 and are testing our 
development copy of the code against 2.4.

Most all of it appears to work fine.

However, there is one page where I keep getting an "Internal Server Error" 
and have seen that the file is producing no output for the CGI script (we 
are running albatross as CGI).

I finally tracked it down to the HTML template that accompanies that page. 
The .py page module is fine. However, the HTML template has something in it 
that is causing the error.

In order to try and determine what lines of the HTML file may be causing 
the problem (because the log files produced no useful error messages), I 
was going through and adding one line at a time to the HTML file and 
running it after each addition.

I get the error when I add this line to the file:

<al-for iter="entry" expr="_loglist" pagesize="50" prepare />

the _loglist variable is defined as the result of a MySQL query



c = QA.cursor()
result = c.execute("""SELECT changelog
                      FROM qadb
                      WHERE CID=%s;""" % ctx.locals._account_num)
if result:
    ctx.locals._loglist = c.fetchone()['changelog']

Note that c is a dictionary class cursor from MySQLdb and so it returns a 
tuple of dictionary mappings. In this case there is only one key in the 
dictionary. I don't think that is relevant to this issue, though...

It seems that there is some incompatibility with the <al-for prepare /> 
statement shown above and Python 2.4.1

If anyone has any ideas what could be causing this...well, I hope you'll 
let me know.

Regards,

Sheila




From andrewm at object-craft.com.au  Tue Apr 19 20:22:12 2005
From: andrewm at object-craft.com.au (Andrew McNamara)
Date: Tue, 19 Apr 2005 20:22:12 +1000
Subject: [albatross-users] Python 2.4.1 incompatibility with al-for ? 
In-Reply-To: <861F8B78A7EF59F366549D8F@[192.168.1.102]> 
References: <861F8B78A7EF59F366549D8F@[192.168.1.102]>
Message-ID: <20050419102212.2F350794091@longblack.object-craft.com.au>

>I get the error when I add this line to the file:
>
><al-for iter="entry" expr="_loglist" pagesize="50" prepare />
>
>the _loglist variable is defined as the result of a MySQL query
>
>
>
>c = QA.cursor()
>result = c.execute("""SELECT changelog
>                      FROM qadb
>                      WHERE CID=%s;""" % ctx.locals._account_num)
>if result:
>    ctx.locals._loglist = c.fetchone()['changelog']
>
>Note that c is a dictionary class cursor from MySQLdb and so it returns a 
>tuple of dictionary mappings. In this case there is only one key in the 
>dictionary. I don't think that is relevant to this issue, though...
>
>It seems that there is some incompatibility with the <al-for prepare /> 
>statement shown above and Python 2.4.1

I'm using Python 2.4.1 with Albatross in complex database dependent apps
without trouble. Maybe the mysql library was upgraded when you went
from 2.2 to 2.4? My guess would be that it's returning an iterable,
rather than an array. Currently <al-for> requires an indexable object
such as an array or tuple. I guess you could try something like:

    c = QA.cursor()
    result = c.execute("""SELECT changelog
                          FROM qadb
                          WHERE CID=%s;""" % ctx.locals._account_num)
    if result:
        _loglist = c.fetchone()['changelog']
        for i in range(len(_loglist)):
            print _loglist[i]

This essentially duplicates what Albatross does internally when accessing
the supplied object.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/


From andrewm at object-craft.com.au  Tue Apr 19 20:25:25 2005
From: andrewm at object-craft.com.au (Andrew McNamara)
Date: Tue, 19 Apr 2005 20:25:25 +1000
Subject: [albatross-users] Python 2.4.1 incompatibility with al-for ? 
In-Reply-To: <20050419102212.2F350794091@longblack.object-craft.com.au> 
References: <861F8B78A7EF59F366549D8F@[192.168.1.102]> <20050419102212.2F350794091@longblack.object-craft.com.au>
Message-ID: <20050419102525.45BC3794091@longblack.object-craft.com.au>

>Maybe the mysql library was upgraded when you went
>from 2.2 to 2.4? My guess would be that it's returning an iterable,
>rather than an array. Currently <al-for> requires an indexable object
>such as an array or tuple. I guess you could try something like:

It might also be worth trying to cast the object returned by mysql to a
list explicitly:

    if result:
        ctx.locals._loglist = list(c.fetchone()['changelog'])

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/


From sheila at thinkspot.net  Tue Apr 19 23:59:13 2005
From: sheila at thinkspot.net (Sheila King)
Date: Tue, 19 Apr 2005 06:59:13 -0700
Subject: [albatross-users] Python 2.4.1 incompatibility with al-for ? 
In-Reply-To: <20050419102525.45BC3794091@longblack.object-craft.com.au>
References: <861F8B78A7EF59F366549D8F@[192.168.1.102]>
 <20050419102212.2F350794091@longblack.object-craft.com.au>
 <20050419102525.45BC3794091@longblack.object-craft.com.au>
Message-ID: <2E021C50CD2F7870794AED8E@[192.168.1.102]>

Hello Andrew,

Thanks for the suggestions...

--On Tuesday, April 19, 2005 8:25 PM +1000 Andrew McNamara 
<andrewm at object-craft.com.au> wrote:

>> Maybe the mysql library was upgraded when you went
>> from 2.2 to 2.4?

This is probably true. I will check with the package maintainer for our 
server to be sure...

>> My guess would be that it's returning an iterable,
>> rather than an array.

I will check it out. What's strange is that I use <al-for> tags on a number 
of pages in the app, but most of them work fine.

I've found another page that is throwing an error although it doesn't go to 
500 Internal Server error...probably because I'm catching the error on that 
page. I will have to investigate what the difference is between the pages 
where al-for works and where it doesn't, and it does sound like starting 
with the objects MySQL is returning is the next logical place to look. I 
believe on the pages where it works, I am constructing my own lists and not 
directly using the object returned by MySQLdb.

Thank you again for the pointer on where to look next...

-- 
Sheila King
sheila at thinkspot.net
http://www.thinkspot.net/sheila/


>> Currently <al-for> requires an indexable object
>> such as an array or tuple. I guess you could try something like:
>
> It might also be worth trying to cast the object returned by mysql to a
> list explicitly:
>
>     if result:
>         ctx.locals._loglist = list(c.fetchone()['changelog'])
>
> --
> Andrew McNamara, Senior Developer, Object Craft
> http://www.object-craft.com.au/
>




From sheila at thinkspot.net  Wed Apr 20 16:23:01 2005
From: sheila at thinkspot.net (Sheila King)
Date: Tue, 19 Apr 2005 23:23:01 -0700
Subject: [albatross-users] Python 2.4.1 incompatibility with al-for ? 
In-Reply-To: <2E021C50CD2F7870794AED8E@[192.168.1.102]>
References: <861F8B78A7EF59F366549D8F@[192.168.1.102]>
 <20050419102212.2F350794091@longblack.object-craft.com.au>
 <20050419102525.45BC3794091@longblack.object-craft.com.au>
 <2E021C50CD2F7870794AED8E@[192.168.1.102]>
Message-ID: <30B13DD235245F74B49084BC@[192.168.1.102]>

OK, I am really at my wits end now.

I've broken this down to an extremely simple template...here is the entire 
file:

-------
<html><head><title>Test</title></head>
<body>
Text
<al-for iter="entry" expr="_loglist" pagesize="50" prepare/>

</body>
</html>
-------

My _loglist is as follows:

>>> ctx.locals._loglist
['2005-04-19: Technical Email Address updated<br /><b>From</b>: <br 
/><b>To:</b> root at kserver.org']

It is actually a list with a single string in it (for testing purposes this 
is what I am using, but in actual live use there would probably be a list 
of several strings).

The suggestion to investigate what the MySQLdb module was returning 
(perhaps a different type of object), which sounded like a good lead to 
check, actually turns out to be a non-issue. Both MySQLdb return the exact 
same results and types and objects (all tested from command line).

And as noted previously, the extremely simple template shown above runs 
without error under Python 2.2.2 but under 2.4.1 it repeatedly causes an 
error which is (as far as I can see) failure to produce any output from the 
CGI process, resulting in "premature end of script headers" as the logged 
error message from the web server.

I also ran the same template from the command line, and from command line 
it works just fine under both Pythons. ARRRGH.

Mind you, I'm using SimpleContext when running it from command line. In my 
CGI app I use the Session File context. But when I tried to run that from 
the command line, it had too many missing environment variables and I got 
frustrated with trying to make that work and switched to SimpleContext.

I am so lost as to where to go or what to try next. :/

-- 
Sheila King
sheila at thinkspot.net
http://www.thinkspot.net/sheila/


--On Tuesday, April 19, 2005 6:59 AM -0700 Sheila King 
<sheila at thinkspot.net> wrote:

> Hello Andrew,
>
> Thanks for the suggestions...
>
> --On Tuesday, April 19, 2005 8:25 PM +1000 Andrew McNamara
> <andrewm at object-craft.com.au> wrote:
>
>>> Maybe the mysql library was upgraded when you went
>>> from 2.2 to 2.4?
>
> This is probably true. I will check with the package maintainer for our
> server to be sure...
>
>>> My guess would be that it's returning an iterable,
>>> rather than an array.
>
> I will check it out. What's strange is that I use <al-for> tags on a
> number of pages in the app, but most of them work fine.
>
> I've found another page that is throwing an error although it doesn't go
> to 500 Internal Server error...probably because I'm catching the error on
> that page. I will have to investigate what the difference is between the
> pages where al-for works and where it doesn't, and it does sound like
> starting with the objects MySQL is returning is the next logical place to
> look. I believe on the pages where it works, I am constructing my own
> lists and not directly using the object returned by MySQLdb.
>
> Thank you again for the pointer on where to look next...
>
> --
> Sheila King
> sheila at thinkspot.net
> http://www.thinkspot.net/sheila/
>
>
>>> Currently <al-for> requires an indexable object
>>> such as an array or tuple. I guess you could try something like:
>>
>> It might also be worth trying to cast the object returned by mysql to a
>> list explicitly:
>>
>>     if result:
>>         ctx.locals._loglist = list(c.fetchone()['changelog'])
>>
>> --
>> Andrew McNamara, Senior Developer, Object Craft
>> http://www.object-craft.com.au/
>>
>
>
> _______________________________________________
> Albatross-users mailing list
> Albatross-users at object-craft.com.au
> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users
>




From jeff at drinktomi.com  Fri Apr 22 07:36:44 2005
From: jeff at drinktomi.com (Jeff With The Big Yellow Suit)
Date: Thu, 21 Apr 2005 14:36:44 -0700
Subject: [albatross-users] Authentication, Sessions, and SSL
Message-ID: <9c3fd32a8ab0878d0010636b426be93e@drinktomi.com>

I am attempting to do the following.  I have a login page.  I want 
connections
to this page to transition to SSL.  Once login is complete the 
connections
should transition to non-SSL.   This looks like it's going to be 
something of
a bear.  Has anyone successfully attacked this before?  If so, can you 
post
the code.  If not so, can you describe your approach?

I don't want to dive into the innards of albatross, but I have a 
feeling that I
may have to.

-jeff



From sheila at thinkspot.net  Fri Apr 22 08:25:09 2005
From: sheila at thinkspot.net (Sheila King)
Date: Thu, 21 Apr 2005 15:25:09 -0700
Subject: RESOLVED (was: Re: [albatross-users] Python 2.4.1 incompatibility
 with al-for ? )
In-Reply-To: <30B13DD235245F74B49084BC@[192.168.1.102]>
References: <861F8B78A7EF59F366549D8F@[192.168.1.102]>
 <20050419102212.2F350794091@longblack.object-craft.com.au>
 <20050419102525.45BC3794091@longblack.object-craft.com.au>
 <2E021C50CD2F7870794AED8E@[192.168.1.102]>
 <30B13DD235245F74B49084BC@[192.168.1.102]>
Message-ID: <A9110211CB483248E9542686@[192.168.1.102]>

This issue appears to be resolved.

We were supposed to be using the 2.4.1 Python binary. However, it appears 
that inadvertently the 2.4.0 binary was installed.

Replacing 2.4.0 with 2.4.1 seems to have resolved the issue. I can only 
surmise it was a bug in Python 2.4.0.

-- 
Sheila King
sheila at thinkspot.net
http://www.thinkspot.net/sheila/


--On Tuesday, April 19, 2005 11:23 PM -0700 Sheila King 
<sheila at thinkspot.net> wrote:

> OK, I am really at my wits end now.
>
> I've broken this down to an extremely simple template...here is the
> entire file:
>
> -------
> <html><head><title>Test</title></head>
> <body>
> Text
> <al-for iter="entry" expr="_loglist" pagesize="50" prepare/>
>
> </body>
> </html>
> -------
>
> My _loglist is as follows:
>
>>>> ctx.locals._loglist
> ['2005-04-19: Technical Email Address updated<br /><b>From</b>: <br
> /><b>To:</b> root at kserver.org']
>
> It is actually a list with a single string in it (for testing purposes
> this is what I am using, but in actual live use there would probably be a
> list of several strings).
>
> The suggestion to investigate what the MySQLdb module was returning
> (perhaps a different type of object), which sounded like a good lead to
> check, actually turns out to be a non-issue. Both MySQLdb return the
> exact same results and types and objects (all tested from command line).
>
> And as noted previously, the extremely simple template shown above runs
> without error under Python 2.2.2 but under 2.4.1 it repeatedly causes an
> error which is (as far as I can see) failure to produce any output from
> the CGI process, resulting in "premature end of script headers" as the
> logged error message from the web server.
>
> I also ran the same template from the command line, and from command line
> it works just fine under both Pythons. ARRRGH.
>
> Mind you, I'm using SimpleContext when running it from command line. In
> my CGI app I use the Session File context. But when I tried to run that
> from the command line, it had too many missing environment variables and
> I got frustrated with trying to make that work and switched to
> SimpleContext.
>
> I am so lost as to where to go or what to try next. :/
>
> --
> Sheila King
> sheila at thinkspot.net
> http://www.thinkspot.net/sheila/
>
>
> --On Tuesday, April 19, 2005 6:59 AM -0700 Sheila King
> <sheila at thinkspot.net> wrote:
>
>> Hello Andrew,
>>
>> Thanks for the suggestions...
>>
>> --On Tuesday, April 19, 2005 8:25 PM +1000 Andrew McNamara
>> <andrewm at object-craft.com.au> wrote:
>>
>>>> Maybe the mysql library was upgraded when you went
>>>> from 2.2 to 2.4?
>>
>> This is probably true. I will check with the package maintainer for our
>> server to be sure...
>>
>>>> My guess would be that it's returning an iterable,
>>>> rather than an array.
>>
>> I will check it out. What's strange is that I use <al-for> tags on a
>> number of pages in the app, but most of them work fine.
>>
>> I've found another page that is throwing an error although it doesn't go
>> to 500 Internal Server error...probably because I'm catching the error on
>> that page. I will have to investigate what the difference is between the
>> pages where al-for works and where it doesn't, and it does sound like
>> starting with the objects MySQL is returning is the next logical place to
>> look. I believe on the pages where it works, I am constructing my own
>> lists and not directly using the object returned by MySQLdb.
>>
>> Thank you again for the pointer on where to look next...
>>
>> --
>> Sheila King
>> sheila at thinkspot.net
>> http://www.thinkspot.net/sheila/
>>
>>
>>>> Currently <al-for> requires an indexable object
>>>> such as an array or tuple. I guess you could try something like:
>>>
>>> It might also be worth trying to cast the object returned by mysql to a
>>> list explicitly:
>>>
>>>     if result:
>>>         ctx.locals._loglist = list(c.fetchone()['changelog'])
>>>
>>> --
>>> Andrew McNamara, Senior Developer, Object Craft
>>> http://www.object-craft.com.au/
>>>
>>
>>
>> _______________________________________________
>> Albatross-users mailing list
>> Albatross-users at object-craft.com.au
>> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users
>>
>
>
> _______________________________________________
> Albatross-users mailing list
> Albatross-users at object-craft.com.au
> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users
>




From sheila at thinkspot.net  Fri Apr 22 08:51:27 2005
From: sheila at thinkspot.net (Sheila King)
Date: Thu, 21 Apr 2005 15:51:27 -0700
Subject: [albatross-users] Authentication, Sessions, and SSL
In-Reply-To: <9c3fd32a8ab0878d0010636b426be93e@drinktomi.com>
References: <9c3fd32a8ab0878d0010636b426be93e@drinktomi.com>
Message-ID: <CC0346E6F82830DF18B53145@[192.168.1.102]>

Hello Jeff,

--On Thursday, April 21, 2005 2:36 PM -0700 Jeff With The Big Yellow Suit 
<jeff at drinktomi.com> wrote:

> I am attempting to do the following.  I have a login page.  I want
> connections
> to this page to transition to SSL.  Once login is complete the connections
> should transition to non-SSL.   This looks like it's going to be
> something of
> a bear.  Has anyone successfully attacked this before?  If so, can you
> post
> the code.  If not so, can you describe your approach?

I have something sort of like this running at http://www.mathxy.com

The albatross application initially runs with HTTP protocol. However, 
certain access requires HTTPS (such as login, ability to post comments, 
view grades...it is a support site for my students).

I don't bother with trying to transition back to HTTP after login. I just 
let the app run in HTTPS after that.

It isn't that hard to do, and I'm sure transitioning back to HTTP from 
HTTPS would not be difficult.

I am running this particular app as a CGI script. It is a Random Page app.

The way our server is set up, files in the /cgi-bin directory can run under 
either HTTPS or HTTP. Files in the /cgi-ssl directory can only run under 
HTTPS.

For any page that _must_ be accessed only via HTTPS (such as the login 
page, the page for posting comments, the page for viewing grades or 
configuring preferences), the page module file and accompanying template 
are only in the cgi-ssl directory. Pages that I want to be accessible under 
either protocol are in the cgi-bin directory.

When you view the start page, which you can access just by going to
http://www.mathxy.com
the links in the top blue nav bar under the site logo that are accessible 
under both protocols (such as "Home", "Resources" and "Help Links") are 
coded as follows:

<al-a href="home">Home</al-a>

So that albatross will serve them correctly from either protocol.

The links that can only be accessed by HTTPS are hardcoded as regular HTML 
anchor links pointing directly to the appropriate URL, such as:
<a 
href="https://xmathxy.merchantquest.net/cgi-ssl/classblog.py/login">Login 
?</a>

Hope this gets you started...

-- 
Sheila King
sheila at thinkspot.net
http://www.thinkspot.net/sheila/





> I don't want to dive into the innards of albatross, but I have a feeling
> that I
> may have to.
>
> -jeff
>
> _______________________________________________
> Albatross-users mailing list
> Albatross-users at object-craft.com.au
> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users
>




From tchur at optushome.com.au  Fri Apr 22 11:46:20 2005
From: tchur at optushome.com.au (Tim Churches)
Date: Fri, 22 Apr 2005 11:46:20 +1000
Subject: RESOLVED (was: Re: [albatross-users] Python 2.4.1
    incompatibility with al-for ? )
Message-ID: <200504220146.j3M1kKqt018802@mail26.syd.optusnet.com.au>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://www.object-craft.com.au/pipermail/albatross-users/attachments/20050422/560fab71/attachment.ksh>

From luci at wolfheart.ro  Sat Apr 30 01:15:32 2005
From: luci at wolfheart.ro (Luci Stanescu)
Date: Fri, 29 Apr 2005 18:15:32 +0300
Subject: [albatross-users] pickle problem
Message-ID: <20050429151532.GD3466@odin.wolfheart.ro>

I have a small application that keeps track of different documents. At
times, in any module of the application (ModularSessionApp), this error
is raised;

Template traceback (most recent call last):

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/albatross/app.py", line 284, in run
    self.save_session(ctx)
  File "/usr/lib/python2.3/site-packages/albatross/app.py", line 350, in save_session
    ctx.save_session()
  File "/usr/lib/python2.3/site-packages/albatross/session.py", line 82, in save_session
    text = self.encode_session()
  File "/usr/lib/python2.3/site-packages/albatross/context.py", line 602, in encode_session
    raise ApplicationError('locals "%s": %s' % (name, e))
ApplicationError: locals "user": Can't pickle <class 'Base.User'>: it's not the same object as Base.User


Any idea what the problem is? user of type Base.User is kept in the
session. This happens sometimes and sometimes it works ok.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.object-craft.com.au/pipermail/albatross-users/attachments/20050429/bf7f31f2/attachment.pgp>