[Zope3-Users] Will new release of zope3 include TSL/SSL in zope.sendmail
Hi ALL, When will the next release of zope3 will be? will there be a zope3.4c2? By the way i wish to know whether next release will include the latest release of zope.sendmail which has TSL/SSL feature. I have noticed that last release, zope3.4c01 was on 31 Jan 2008. http://www.zope.org/Products/Zope3/3.4.0c1 And the zope.sendmail has trunked SSL/TLS feature on 19th Aug 2008. http://svn.zope.org/zope.sendmail/trunk/src/zope/sendmail/mailer.py?rev=92747sortby=logview=log So its obvious that zope3.4c01 don't have SSL/TLS feature in its zope.sendmail. And i have seen some other many other fixes in the zope.sendmail that enables it to work well with gmail and similar So i hope we can see new zope.sendmail in the next release. Regards, jayaraj ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Smarter values for values = [] in Choice schema fields?
Hi,
I quite often have Choice schema fields in my applications. In many cases,
these choice fields should have fixed values, thus I do it like this:
color = Choice( title=uColor, values=['red', 'green', 'yellow'])
My application then uses the these values for further processing, e.g.:
if color == 'red': stop_traffic()
The problem is, that often it is more appropriate to have one value for
display, and another for internal processing (e.g. when msgid strings are
involved, when the program needs specific values etc.)
The only way I found is to set up a vocabulary and use
SimpleVocabulary.createTerm(key, n, name), however, that's quite tedious, as
I need to write quite some code, register the vocabulary etc.
So, perhaps there's a simpler solution? I'd favour something like this:
color = Choice(titel=uColor, values = [('red', 0, uRed), ('green', 1,
uGreen)])
Is that possible?
Best Regards,
Hermann
--
[EMAIL PROTECTED]
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Recursive zope.app.container.constraints.contains()
Hi everybody!
total newbie question regarding the behaviour of
zope.app.container.constraints functionality: as it is now, the
containing constraints of an interface (defined by the arguments of
the contains(*types) function) are not inherited from the interface's
parents.
As an example, suppose I have the below in the colligo/test1.py module:
from zope.interface import Interface, implements
from zope.app.container.constraints import contains, containers, checkObject
from zope.app.container.btree import BTreeContainer
class I1(Interface):
contains('colligo.test1.I2')
class I11(I1):
contains('colligo.test1.I3')
class I2(Interface):
containers('colligo.test1.I1')
class I3(Interface):
containers('colligo.test1'colligo.nomisma.interfaces.INomismaBaseDenomination'.I11')
class A1(BTreeContainer):
implements(I1)
class A11(BTreeContainer):
implements(I11)
class A2(object):
implements(I2)
class A3(object):
implements(I3)
In this case, an instance of A11 will only accept A3 objects as
children but not A2 ones as one would expect given the definition of
the parent.
Would it be interesting to have such behaviour implemented?
Thanks,
Dragos.
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Recursive zope.app.container.constraints.contains()
On Thu, Nov 6, 2008 at 8:27 AM, Dragos Petre [EMAIL PROTECTED] wrote: In this case, an instance of A11 will only accept A3 objects as children but not A2 ones as one would expect given the definition of the parent. You've stated in I11 that only objects providing I3 should be accepted; I'm not sure why you'd expect anything different. The contains constraint doesn't mean also allows, it means only allows; if you want a union, you'll need to implement that separately, using a new constraint. Adding that to the existing constraint would cause a backward compatibility issue. I've never had a use for the scenario you describe, and suspect that most needs for something similar are trivially met by simply spelling out the entire set of allowed types in each contains constraint. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Smarter values for values = [ ] in Choice schema fields?
Am Donnerstag 06 November 2008 17:30:27 schrieb Marius Gedminas:
On Thu, Nov 06, 2008 at 02:13:56PM +0100, Hermann Himmelbauer wrote:
I quite often have Choice schema fields in my applications. In many
cases, these choice fields should have fixed values, thus I do it like
this:
color = Choice( title=uColor, values=['red', 'green', 'yellow'])
My application then uses the these values for further processing, e.g.:
if color == 'red': stop_traffic()
The problem is, that often it is more appropriate to have one value for
display, and another for internal processing (e.g. when msgid strings are
involved, when the program needs specific values etc.)
The only way I found is to set up a vocabulary and use
SimpleVocabulary.createTerm(key, n, name), however, that's quite tedious,
as I need to write quite some code, register the vocabulary etc.
Not really.
So, perhaps there's a simpler solution? I'd favour something like this:
color = Choice(titel=uColor, values = [('red', 0, uRed), ('green', 1,
uGreen)])
Is that possible?
Define a helper function
def vocabulary(*terms):
return SimpleVocabulary([SimpleTerm(value, token, title)
for value, token, title in terms])
and use it
color = Choice(title=uColor,
vocabulary=vocabulary(
(0, 'red', u'Red'),
(1, 'green', u'Green'),
))
Ah, that's nice! I did not know that I can actually use a vocabulary object as
parameter! Thanks!
Best Regards,
Hermann
--
[EMAIL PROTECTED]
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Smarter values for values = [] in Choice schema fields?
On Thu, Nov 06, 2008 at 02:13:56PM +0100, Hermann Himmelbauer wrote:
I quite often have Choice schema fields in my applications. In many cases,
these choice fields should have fixed values, thus I do it like this:
color = Choice( title=uColor, values=['red', 'green', 'yellow'])
My application then uses the these values for further processing, e.g.:
if color == 'red': stop_traffic()
The problem is, that often it is more appropriate to have one value for
display, and another for internal processing (e.g. when msgid strings are
involved, when the program needs specific values etc.)
The only way I found is to set up a vocabulary and use
SimpleVocabulary.createTerm(key, n, name), however, that's quite tedious, as
I need to write quite some code, register the vocabulary etc.
Not really.
So, perhaps there's a simpler solution? I'd favour something like this:
color = Choice(titel=uColor, values = [('red', 0, uRed), ('green', 1,
uGreen)])
Is that possible?
Define a helper function
def vocabulary(*terms):
return SimpleVocabulary([SimpleTerm(value, token, title)
for value, token, title in terms])
and use it
color = Choice(title=uColor,
vocabulary=vocabulary(
(0, 'red', u'Red'),
(1, 'green', u'Green'),
))
HTH,
Marius Gedminas
--
Undergraduates owe their happiness chiefly to the fact that they are no
longer at school...The nonsense which was knocked out of them at school is
all gently put back at Oxford or Cambridge
-- Sir Max Beerbohm (1872-1956)
signature.asc
Description: Digital signature
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
