[Zope3-dev] Re: Page Template oddity
Stephan Richter wrote: On Saturday 23 July 2005 02:42, Andreas Reuleaux wrote: ul is not allowed within a p tag, not even in HTML 4.01 Transitional Thanks a lot! I did not know this! Even though I find this restriction stupid. I often have bullet list like this as part of my paragraph, even when I non-technical documents. But that's beside the point. Thank god nothing is broken in PT. ;-) Me thinks the error message is pretty broken! Or is that now considered a PT feature? ;) Suresh ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] translate() default value
Hi Everyone, In the most cases users of the translate() expect untranslated string will be returned if no translation is performed. See for example Issue #298 (http://www.zope.org/Collectors/Zope3-dev/298). Is this reasonable to change the translate() to return untranslated string by default instead of None? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: translate() default value
Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Hi Everyone, In the most cases users of the translate() expect untranslated string will be returned if no translation is performed. See for example Issue #298 (http://www.zope.org/Collectors/Zope3-dev/298). Is this reasonable to change the translate() to return untranslated string by default instead of None? I think so. I also don't agree with myself anymore regarding the fixing of issue 298; your proposal sounds a lot better. So, +1 to the change. The question remains what to do on X3.0 branch. Changing the semantics of zope.i18n.translate could already jeopardize backward compatability between X3.0 and 3.1; such a change between X3.0.0 and X3.0.1 could be even be worse... Thoughts? The simplest solution is to change all translate(text) calls to translate(text, default=text). I think we need to do it for 3.1 also. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: translate() default value
Dmitry Vasiliev wrote:
The simplest solution is to change all translate(text) calls to
translate(text, default=text). I think we need to do it for 3.1 also.
So we'd either have to duplicate the message text, or place all text in
a variable first, and pass it as both arguments?
translate('my message text', text='my message text')
Perhaps a switch would be more appropriate. Something like (with a
better parameter name):
translate('my message text', text_is_default=True)
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: translate() default value
Benji York wrote:
Dmitry Vasiliev wrote:
The simplest solution is to change all translate(text) calls to
translate(text, default=text). I think we need to do it for 3.1 also.
So we'd either have to duplicate the message text, or place all text in
a variable first, and pass it as both arguments?
translate('my message text', text='my message text')
Perhaps a switch would be more appropriate. Something like (with a
better parameter name):
translate('my message text', text_is_default=True)
Well, I understood Dmitry's original posting (the start of the thread), that
translate('my message text')
would be made equivalent to
translate('my message text', default='my message text')
Right now, it's equivalent to
translate('my message text', default=None)
which causes lots of problems because you would really expect to always
get a (unicode) string back from translate(). (see the issue Dmitry's
mentioning).
Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] mechtest-based README.txt
Hi all,
FYI, Benji and I are discussing putting mechanize and mechtest into the Zope 3
trunk (we can do this, since it is not in the release). Attached you can find
a README.txt based on mechtest I wrote for some SchoolTool development I am
doing.
I hope you are getting as excited about this as I am by looking at the
demo. :-)
mechtest URL: svn+ssh://svnzope/repos/main/Sandbox/zc/mechtest
Regards,
Stephan
--
Stephan Richter
CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
=
Level Management and Academic Workflow via the Web UI
=
This document presents the management of levels and the academic career of a
student via a promotion workflow from the perspective of the Web UI.
from zc.mechtest.testing import Browser
browser = Browser()
browser.addHeader('Authorization', 'Basic mgr:mgrpw')
browser.open(
... 'http://localhost/contents.html?'
... 'type_name=BrowserAdd__schooltool.app.SchoolToolApplication'
... 'new_value=test')
test in browser.contents
True
browser.click('test')
Level Management
First we create a couple of levels.
browser.click('Levels')
browser.click('New Level')
browser.controls['field.title'] = u'1st Grade'
browser.controls['field.isInitial'] = True
browser.controls['add_input_name'] = u'level1'
browser.click('Add')
'1st Grade' in browser.contents
True
browser.click('New Level')
browser.controls['field.title'] = u'2nd Grade'
browser.controls['field.isInitial'] = False
browser.controls['add_input_name'] = u'level2'
browser.click('Add')
'2nd Grade' in browser.contents
True
Since we did not connect the two levels, validation should fail:
browser.click('Validate Levels')
browser.click('Validate')
One or more disconnected levels detected. in browser.contents
True
2nd Grade in browser.contents
True
If we connect `level1` to `level2` and also `level2` to `level1`, we get a
loop validation error:
browser.click('Levels')
browser.click('1st Grade')
browser.click('Edit Info')
browser.controls['field.nextLevel'] = ['level2']
browser.click('Apply')
browser.click('Levels')
browser.click('2nd Grade')
browser.click('Edit Info')
browser.controls['field.nextLevel'] = ['level1']
browser.click('Apply')
browser.click('Levels')
browser.click('Validate Levels')
browser.click('Validate')
A Level Loop Error was detected. in browser.contents
True
print browser.contents
BLANKLINE
...
Simply do not specify level
em1st Grade/em
...
Okay, so let's do what the error tells us and remove the link in `level2` to
`level1`:
browser.click('Levels')
browser.click('2nd Grade')
browser.click('Edit Info')
browser.controls['field.nextLevel'] = []
browser.click('Apply')
browser.click('Levels')
browser.click('Validate Levels')
browser.click('Validate')
print browser.contents
BLANKLINE
...
No errors were detected.
...
The Academic Career of a Student
Before we can do anything, we have to create a student:
import StringIO
browser.click('Persons')
browser.click('New Person')
browser.controls['field.title'] = 'Stephan Richter'
browser.controls['field.username'] = 'srichter'
browser.controls['field.password'] = 'foobar'
browser.controls['field.verify_password'] = 'foobar'
browser.controls['field.photo'] = StringIO.StringIO()
browser.click('Add')
'Stephan Richter' in browser.contents
True
Now we go to the manager group, and walk the student through the academic
career:
browser.click('Groups')
browser.click('Manager')
browser.click('Student Management')
We now select the student which we want to enroll in the school.
form = browser.forms['enroll']
ctrl = browser.getControl('ids:list', form=form.mech_form)
ctrl.mech_control.value = ['srichter']
browser.click('Enroll')
print browser.contents
BLANKLINE
...
div id=messageStudents successfully enrolled./div
...
option value=level11st Grade/option
option value=level22nd Grade/option
...
Now that the student is enrolled, we can initialize him at a particular
level. Our student will enter the first grade:
form = browser.forms['initialize']
ctrl = browser.getControl('ids:list', form=form.mech_form)
id = ctrl.options[0]
ctrl.mech_control.value = [id]
browser.controls[id+'.level'] = ['level1']
browser.click('Apply')
print browser.contents
BLANKLINE
...
div id=messageStudent processes successfully updated./div
...
div class=value
select name=...outcome size=1
option selected=selected value=passpass/option
option value=failfail/option
option value=withdrawwithdraw/option
/select
/div
...
The student passes the first grade
form =
Re: [Zope3-dev] Re: translate() default value
Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Hi Everyone, In the most cases users of the translate() expect untranslated string will be returned if no translation is performed. See for example Issue #298 (http://www.zope.org/Collectors/Zope3-dev/298). Is this reasonable to change the translate() to return untranslated string by default instead of None? I think so. I also don't agree with myself anymore regarding the fixing of issue 298; your proposal sounds a lot better. So, +1 to the change. The question remains what to do on X3.0 branch. Changing the semantics of zope.i18n.translate could already jeopardize backward compatability between X3.0 and 3.1; such a change between X3.0.0 and X3.0.1 could be even be worse... Thoughts? The simplest solution is to change all translate(text) calls to translate(text, default=text). Ah, when I wrote my original mail I thought of this solution but scrapped it because I didn't think it would work (e.g. think of explicit message ids). By looking at the code of zope.i18n.translate now and a quick test on the interpreter prompt, I think that it'll be appropriate. I think we need to do it for 3.1 also. Well, I dunno... I think changing the behaviour of zope.i18n.translate regarding the default argument should be enough. Explicit defaults where they're not needed are dead chickens. We need the dead chickens for X3.0 but why introduce them for 3.1 as well? Hmm... You're right. Then I'll fix issue #298 both on the trunk and on the branch. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: translate() default value
Dmitry Vasiliev wrote: Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Hi Everyone, In the most cases users of the translate() expect untranslated string will be returned if no translation is performed. See for example Issue #298 (http://www.zope.org/Collectors/Zope3-dev/298). Is this reasonable to change the translate() to return untranslated string by default instead of None? I think so. I also don't agree with myself anymore regarding the fixing of issue 298; your proposal sounds a lot better. So, +1 to the change. The question remains what to do on X3.0 branch. Changing the semantics of zope.i18n.translate could already jeopardize backward compatability between X3.0 and 3.1; such a change between X3.0.0 and X3.0.1 could be even be worse... Thoughts? The simplest solution is to change all translate(text) calls to translate(text, default=text). Ah, when I wrote my original mail I thought of this solution but scrapped it because I didn't think it would work (e.g. think of explicit message ids). By looking at the code of zope.i18n.translate now and a quick test on the interpreter prompt, I think that it'll be appropriate. I think we need to do it for 3.1 also. Well, I dunno... I think changing the behaviour of zope.i18n.translate regarding the default argument should be enough. Explicit defaults where they're not needed are dead chickens. We need the dead chickens for X3.0 but why introduce them for 3.1 as well? Hmm... You're right. Then I'll fix issue #298 both on the trunk and on the branch. Great! Thank you. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] mysqldbda mysql 4.1 problem
On 7/25/05, Dmitry Vasiliev [EMAIL PROTECTED] wrote: Andy Dustman wrote: On 7/24/05, Jaroslaw Zabiello [EMAIL PROTECTED] wrote: I have mysql 4.1 with database and all tables set to utf8. I have problems with Zope3.1beta/win32. I cannot query the database with mysqldbda adapter because I get an error: unknown encoding: latin1_swedish_ci. http://bugs.mysql.com/bug.php?id=7891 MySQL-4.1, prior to 4.1.9 (and 5.0.3), returns the collation instead of the character set; that's what you're seeing here. What client version are you running? I assume you have at least MySQL-python-1.2.0; older versions probably won't work with MySQL-4.1 (some 1.1 versions will, but 1.0 will not). I've just added the encoding attribute to the ZopeDatabaseAdapter (rev. 37378). Also I've changed psycopg adapter to respect the attribute. Can someone change mysqldbda to use self.getEncoding() instead of connection.character_set_name()? Note that connection.character_set_name() only retrieves the character set name that is in use. To actually set the character set name, you have to do a bit of SQL; for details see: http://dev.mysql.com/doc/mysql/en/charset-connection.html Also note that this is only applicable to MySQL-4.1 and newer. In 4.0, the character set is a server configuration option and cannot be changed by the client. -- Computer interfaces should never be made of meat. http://www.terrybisson.com/meat.html ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Heads up: Zope X3.0.1
Hi there, with Zope X3.0 being integrated in Zope 2.8, a couple of bugfixes that went into Zope 3 after the X3.0.0 release require us to release a X3.0.1. If noone objects, I will tag X3.0.1 tomorrow night (CET). Please get any checkins to the X3.0 branch in before that. Some of the bugfixes since the release of X3.0.0 were backported to the X3.0 branch, some of them weren't. Because of the Zope 2.8 release cycle, we will not have time to investigate all bugfixes to the trunk and backport them, but just focus on some very apparent bugs that we encountered during the Five integration. I hope that we can pull the resources together to backport all the other bugfixes for a X3.0.2 release eventually. Maintaing the X3.0 branch is important because it's actively used in Zope 2.8; that means X3.0's life span will be a lot longer than we had expected. You can help by automatically backporting all bugfixes that you check into the trunk from now on and that would be appropriate for the X3.0 branch as well. Some people also prefer to fix the issue on a release branch first and then forwardport it to the trunk. Either way, it would help us a lot and should only cost you a little more than the time that is required to run the Zope 3 tests another time. With the coming bug day in mind, I would especially like to ask you to follow this practice for bugs that also concern X3.0. Much thanks to everyone who has already done so in the past, by the way. Best regards, Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: translate() default value
Philipp von Weitershausen wrote:
Well, I understood Dmitry's original posting (the start of the thread),
that
translate('my message text')
would be made equivalent to
translate('my message text', default='my message text')
Oh, that makes more sense.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: mechtest-based README.txt
Stephan Richter wrote: Hi all, FYI, Benji and I are discussing putting mechanize and mechtest into the Zope 3 trunk (we can do this, since it is not in the release). Attached you can find a README.txt based on mechtest I wrote for some SchoolTool development I am doing. I hope you are getting as excited about this as I am by looking at the demo. :-) I am super excited!! Tell me how to do this for Zope2 (with Five?). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] mysqldbda mysql 4.1 problem
Andy Dustman wrote: On 7/25/05, Dmitry Vasiliev [EMAIL PROTECTED] wrote: Andy Dustman wrote: On 7/24/05, Jaroslaw Zabiello [EMAIL PROTECTED] wrote: I have mysql 4.1 with database and all tables set to utf8. I have problems with Zope3.1beta/win32. I cannot query the database with mysqldbda adapter because I get an error: unknown encoding: latin1_swedish_ci. http://bugs.mysql.com/bug.php?id=7891 MySQL-4.1, prior to 4.1.9 (and 5.0.3), returns the collation instead of the character set; that's what you're seeing here. What client version are you running? I assume you have at least MySQL-python-1.2.0; older versions probably won't work with MySQL-4.1 (some 1.1 versions will, but 1.0 will not). I've just added the encoding attribute to the ZopeDatabaseAdapter (rev. 37378). Also I've changed psycopg adapter to respect the attribute. Can someone change mysqldbda to use self.getEncoding() instead of connection.character_set_name()? Note that connection.character_set_name() only retrieves the character set name that is in use. To actually set the character set name, you have to do a bit of SQL; for details see: http://dev.mysql.com/doc/mysql/en/charset-connection.html Also note that this is only applicable to MySQL-4.1 and newer. In 4.0, the character set is a server configuration option and cannot be changed by the client. I've added the encoding attribute to the ZopeDatabaseAdapter (previously there has been hardcoded 'utf-8'). Now when you create the adapter instance you can set the encoding. It's more portable way, since the psycopg for example don't allow to retrieve the database encoding, AFAIK. I don't use MySQL so I'm afraid to change anything without testing. :-) So the question is: Can someone change mysqldbda.py:connection.character_set_name() to self.getEncoding() and then test the changes? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Page Template oddity
On 7/26/05, sureshvv [EMAIL PROTECTED] wrote: Me thinks the error message is pretty broken! Or is that now considered a PT feature? ;) I'll grant that it's less than ideal, but not broken by HTML standards. The p in the original source is closed by an implied /p where the ul starts, so while it's not broken as far as compliance with the specification is concerned, it is confusing. Adding logic to separate this case from a more obvious unbalanced tag problem just doesn't seem a high priority to me, but I'll certainly consider patches to the PT compiler to improve the situation. That's a pretty tricky bit of code, unfortunately. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: mechtest-based README.txt
Jim Fulton wrote: Benji York wrote: sureshvv wrote: I am super excited!! I'm glad to hear that. Tell me how to do this for Zope2 (with Five?). I have no idea. I don't have any experience with Five, but I don't think it would take much work for someone to get it to work (perhaps even zero work). Unfortunately, it would take a lot of work, unless someone has ported Zope 3's functional testing framework to Zope 2. Well, there's a functional testing framework in ZopeTestCase and Sidnei even ported doctests (including dochttp tests) to ZopeTestCase. Five 1.1 uses doctests everywhere, even for functional tests. As far as I can see, the only real Zope 3 specific thing in zc.mechtest is this line in testing.py: from zope.app.testing.functional import HTTPCaller Someone should try and see what happens if that line were replaced with from Testing.ZopeTestCase.zopedoctest.functional import http and then below: self.caller = http Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
