Re: [Zope-dev] Greedy except clauses
Jeremy Hylton wrote: I am probably a bit idiosyncratic, but I prefer to avoid bare excepts at all costs. I often use "except Exception:", otherwise I add a Will that catch string exceptions? eg: raise 'Something bad happened' If not, then it's not much use in Zope, which is unfortunately riddled with String exceptions :-S cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ThreadSafeCounter 0.0.1 released
"Morten W. Petersen" wrote: There's a new product available, which enables unique ids in a given context, take a look at url:http://www.zope.org/Members/morphex/ThreadSafeCounter. So would a counter such as: class PersistentCounter(Persistent): # create the counter def __init__(self, value=0): self._value = value # get the value of the counter without incrementing def getValue(self): return self._value # increment the counter when called, and return the new value def __call__(self, number=1): self._value = self._value + number return self._value ...not be thread safe? If not, can anyone explain how it could be made thread safe? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ThreadSafeCounter 0.0.1 released
Chris Withers wrote: "Morten W. Petersen" wrote: There's a new product available, which enables unique ids in a given context, take a look at url:http://www.zope.org/Members/morphex/ThreadSafeCounter. So would a counter such as: class PersistentCounter(Persistent): # create the counter def __init__(self, value=0): self._value = value # get the value of the counter without incrementing def getValue(self): return self._value # increment the counter when called, and return the new value def __call__(self, number=1): self._value = self._value + number return self._value ...not be thread safe? If not, can anyone explain how it could be made thread safe? That's not the issue. Morten's product stores the counter's value in a file on the filesystem, and so it doesn't cause the Data.fs to grow. The trade-off is that it doesn't participate in history or undo. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Programmatic way to get the Zope Version
Hi, I was if do something like: if zope_version = 2.3: # balh else: # blah Where do I get the zope_version bti and what format will it be in? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Thread Safe Counting
Steve Alexander wrote: Chris Withers wrote: So would a counter such as: snip my counter That's not the issue. Does that mean my counter is thread safe? Morten's product stores the counter's value in a file on the filesystem, and so it doesn't cause the Data.fs to grow. Hmmm, well, my counter above wouldn't cause the data.fs to grow all that much, since it subclasses Persistent and so gets its own pickle jar. cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Programmatic way to get the Zope Version
Chris Withers wrote: Hi, I was if do something like: if zope_version = 2.3: # balh else: # blah Where do I get the zope_version bti and what format will it be in? You can get it as version_txt from Control_Panel. For example, from DTML: dtml-with Control_Panel dtml-var version_txt /dtml-with However, this won't do you much good, as when you have a version of Zope from CVS, it gets called "(unreleased version)". The way some Products detect the version is to try to import a module that only exists in one version of Zope, or try to look up an attribute that is only in one version of Zope, and then catch the Exception. Ideally, this will be the attribute or module that has changed that made you want to detect the version in the first place. Make your choices based on whether there is an Exception or not. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Persistence ( was Thread Safe Counting )
Morten's product stores the counter's value in a file on the filesystem, and so it doesn't cause the Data.fs to grow. Hmmm, well, my counter above wouldn't cause the data.fs to grow all that much, since it subclasses Persistent and so gets its own pickle jar. cheers, Chris So subclassing persistent will avoid changes to the object being stored and roll-backable in the ZODB? Nice! Now, if only we could get this sort of store-in-place functionality on a more fine-grained level (like on individual properties) - we could avoid a lot of coding to prevent ZODB bloat with simple features.. Ie, if I were to make a 'persistent porperty' on a DTML method, I could store counter information in that property without worry of ZODB bloat. Hrm... *Jon staes into the distance wondering how much will break if he tries to implement a 'persistent' flag for properties* ~Jon ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] manage_ methods
Hi again, Is it true that you have to have the Manager role to use any methods that start with manage_? If so, that's pretty unhelpful, almost as unhelpful as the DocString limitation :-( cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Persistence ( was Thread Safe Counting )
Jon Franz wrote: So subclassing persistent will avoid changes to the object being stored and roll-backable in the ZODB? NO! read the posting again... Subclassing from persistent is HOW you make things live in the ZODB. However, objects that subclass Persistent get their own pickle jar, and so only make the ZODB grow by the size of themselves and their attributes each time they change. In my counter's case, that's not a lot :-) Now, if only we could get this sort of store-in-place functionality on a more fine-grained level (like on individual properties) - we could avoid a lot of coding to prevent ZODB bloat with simple features.. Ie, if I were to make a 'persistent porperty' on a DTML method, I could store counter information in that property without worry of ZODB bloat. I wouldn't be surprised if something like this happens at some stage ;-) cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] manage_ methods
Nope! the method calling the manage_* method can have proxy roles setup for it so that it can call manage_* methods for users who do not have the capability to call that manage_* method. Also, any user can be assigned access to the manage_* methods needed on a particular document/method/object by giving them the rights do what you need to do, such as the Change Properties and Add properties rights (might also need the manage_properties right, but I dont think so) via the security tab inside Zope... did this help? Hi again, Is it true that you have to have the Manager role to use any methods that start with manage_? If so, that's pretty unhelpful, almost as unhelpful as the DocString limitation :-( cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Persistence ( was Thread Safe Counting )
Ah! this makes more sense, the idea of persistent properties even fits with this idea, though a true write-in-place property might be even better for some applications ;) Next time I'll read the whole thread and not the last post in it! -Original Message- From: Chris Withers [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 11, 2001 1:05 PM To: Jon Franz Cc: '[EMAIL PROTECTED]' Subject: Re: [Zope-dev] Persistence ( was Thread Safe Counting ) Jon Franz wrote: So subclassing persistent will avoid changes to the object being stored and roll-backable in the ZODB? NO! read the posting again... Subclassing from persistent is HOW you make things live in the ZODB. However, objects that subclass Persistent get their own pickle jar, and so only make the ZODB grow by the size of themselves and their attributes each time they change. In my counter's case, that's not a lot :-) Now, if only we could get this sort of store-in-place functionality on a more fine-grained level (like on individual properties) - we could avoid a lot of coding to prevent ZODB bloat with simple features.. Ie, if I were to make a 'persistent porperty' on a DTML method, I could store counter information in that property without worry of ZODB bloat. I wouldn't be surprised if something like this happens at some stage ;-) cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] manage_ methods
Jon Franz wrote: Nope! the method calling the manage_* method can have proxy roles setup for it so that it can call manage_* methods for users who do not have the capability to call that manage_* method. That doesn't help if they want to use the methods directly ;-) Also, any user can be assigned access to the manage_* methods needed on a particular document/method/object by giving them the rights do what you need to do, such as the Change Properties and Add properties rights (might also need the manage_properties right, but I dont think so) via the security tab inside Zope... I was slightly off first time. I think they may need the 'view management screens' perimission, which isnt' quite as bad, but is still a little superfluous... cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Problem with ZODB
Hello, I have a problem with my Data.fs (ZODB). Always, after I change the ZODB (add + delete), I can not pack the database. When I press the "PACK" button in the managment screen, it will return to me that the Database was packed in previous time (and it wasn't). So my database get larger and larger all the time. Best regards, Harry PS: I have the Zope 2.2.2 in this system. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Greedy except clauses
Anthony Baxter wrote: Ok, my last for tonight - I put the output of my horrible script at http://www.zope.org/Members/anthony/BarewordExcepts I'll work over it a bit probably early next week - an obviousish next step is to make it note when the body of the except: contains a 'raise' statement. Great work Anthony :) Richard -- Richard Jones [EMAIL PROTECTED] Senior Software Developer, Bizar Software (www.bizarsoftware.com.au) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ThreadSafeCounter 0.0.1 released
[Chris Withers] | So would a counter such as: | | class PersistentCounter(Persistent): | | # create the counter | def __init__(self, value=0): | self._value = value | | # get the value of the counter without incrementing | def getValue(self): | return self._value | | # increment the counter when called, and return the new value | def __call__(self, number=1): | self._value = self._value + number | return self._value | | ...not be thread safe? I'm not sure whether the code above is thread safe or not. ThreadSafeCounter was made because I don't know enough about Zope internals to determine whether or not the counter would return unique values, nor do I know enough about threads to be completely sure that it would, every time. File locking is a simple concept, and easy to understand. As I've understood it, two threads serving requests have a copy each of the database, and only when changes are committed are they reflected in the database. Therefore, two requests created at the same time could get an identical copy and therefore and identical value. ..so, it basically boils down to the fact that it's simple to use file locking. Cheers, Morten ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] LONGing for normal inetegers...
[Jon Franz] | I had this problem in the past and hacked the mysql DA to fix it, then | dicovered to my dismay I was using an out-of-date mysqlDA and it had already | been fixed... Which DA are you using? Using Python 2.0 could solve this problem, as longs are no longer rendered with the L suffix. HTH. -Morten ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Python Based DataSkins and Propertysheets
Hi,
I am trying to figure out ZPatterns and because I rather work with Python Products
when with Zclasses I am trying to convert the EmployZ product to Python.
So far I got half the way there, the Rack recognizes the DataSkin
And on newItem in the Specialist it a new slot gets created and I can see them and
their ID.
Now the problem is creating a Propertysheet in the DataSkin that gets stored in the
Rack.
I packet my work so far and put it on Zope.org:
http://www.zope.org/Members/johanc/ZPatterns/EmployX/EmployX-0.0.1.tgz
I look at the ZPattern Products that I know are out there, but they don't seem
help me any futher.
Regards,
Johan
Here's my to classes:
EmployX (DataSkin)
__doc__ = """EmployX product module.
See README.txt for more details."""
__version__ = '0.0.1'
from Globals import HTMLFile
from Globals import MessageDialog
from Globals import Persistent
import OFS.SimpleItem
import Acquisition
import AccessControl.Role
from Products.ZPatterns.DataSkins import DataSkin
#from Products.ZPatterns.PropertySheets import VirtualSheets
manage_addEmployXForm = HTMLFile('dtml/EmployXAdd', globals())
def manage_addEmployX(self, id, title='', REQUEST=None):
"""Add a EmployX to a folder."""
self._setObject(id, EmployX(id, title))
if REQUEST is not None:
return self.manage_main(self, REQUEST)
class EmployX(
DataSkin,
#VirtualSheets,
):
"""EmployX object.
"""
meta_type = 'EmployX'
# Necessary?
_isRackMountable = 1
#_properties=(
# {'id':'first', 'type': 'string'},
# {'id':'last', 'type': 'string'},
# {'id':'emp_id', 'type': 'string'},
# {'id':'salary', 'type': 'string'},
#)
manage_options = (
{'label': 'Edit', 'action': 'manage_main' },
{'label':'Debug','action':'debug'},
{'label': 'View', 'action': 'index_html'},
{'label': 'Security', 'action': 'manage_access'},
)
_v_manage_options_label_index =
ExtendedManagmentTabs.createManageIndex(manage_options=manage_options)
__ac_permissions__=(
('View management screens', ('debug','manage_tabs','manage_main')),
('Change permissions', ('manage_access',) ),
('Change EmployX' , ('manage_edit',) ),
('View EmployX',('',)),
)
def __init__(self,id):
"""initialise a new instance of BeingBoring"""
DataSkin.__init__(self,id)
def debug(self):
""" Print object's __dict__ """
result = ""
for k, v in self.__dict__.items():
result = "%s\n%s : %s" % (result, repr(k), repr(v))
return result
manage_main = HTMLFile('dtml/EmployXEdit', globals())
def manage_edit(self, title, REQUEST=None):
"""does this really need a doc string?"""
self.title = title
if REQUEST is not None:
return self.manage_main(self,REQUEST,management_view='Edit')
editInstance = HTMLFile('editInstance', globals())
editInstanceForm = HTMLFile('editInstanceForm', globals())
index_html = HTMLFile('index_html', globals())
def initialize(context):
"""Initialize the EmployX product.
"""
context.registerClass(
EmployX,
constructors = (
manage_addEmployXForm,
manage_addEmployX),
icon = 'www/item.gif'
)
# We need this so that this class will show up in the list of classes
# Customizers can customize. (Thanks Steve)
context.registerBaseClass(EmployX)
EmployXManager(Specialist)
__doc__ = """EmployXManager product module.
See README.txt for more details."""
__version__ = '0.0.1'
from Globals import HTMLFile
#from Globals import MessageDialog
#from Globals import Persistent
from Products.ZPatterns.Specialists import Specialist
manage_addEmployXManagerForm = HTMLFile('EmployXManagerAdd', globals())
def manage_addEmployXManager(self, id, title='', REQUEST=None):
"""Add a EmployXManager to a folder."""
self._setObject(id, EmployXManager(id, title))
if REQUEST is not None:
return self.manage_main(self, REQUEST)
class EmployXManager(Specialist):
"""Thing that manages EmployX"""
meta_type = "EmployXManager"
newItemForm = HTMLFile('newItemForm', globals())
index_html = HTMLFile('index_html_manager', globals())
def addNewItem(self,emp_id,REQUEST=None):
"""ttw"""
ob = self.newItem(emp_id)
#ob.addPropertySheet('Basic')
#ob.propertysheets.Basic.manage_changeProperties(REQUEST=REQUEST)
#if REQUEST.has_key('first'):
Re: [Zope-dev] Greedy except clauses
"CW" == Chris Withers [EMAIL PROTECTED] writes: I am probably a bit idiosyncratic, but I prefer to avoid bare excepts at all costs. I often use "except Exception:", otherwise I add a CW Will that catch string exceptions? eg: raise 'Something bad CW happened' No. CW If not, then it's not much use in Zope, which is unfortunately CW riddled with String exceptions :-S That might be something worth fixing, too. :-) Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
