I just discovered that the approach I had planned for my __init__-constructor does not work. When SA calls the __init__ method of my class, it does not pass any parameters and the attributes defined for this class/object do not exist yet.
Is there a way to access attributes in the __init__ -method? (I mean, when SA reads the rows from the DB and creates the objects). I would like to do something as follows: def __init__(self, ownerId = None, prepForView = True): if prepForView: self.editable = (self.ownerId == session['userId']) But I do not know how to do this, since ownerId is a mapped attribute and is not available in the __init__-call. Thanks, Martin > Actually, it might get a little bit more complicated than that, because I > would like to allow the users to choose who can comment on their posts, for > example: all people, only logged in people, only friends, ... > So, for the posts the overhead probably gets big because it depends on the > identity of the viewer, on the blog and on the user-settings for this blog. > That's why I only want to do these checks when the blog entries and > comments are passed to the view. > You suggest to check for the existence of the primary key ('id' in my > case), because all the new objects that I create do not yet have a primary > key since it will be assigned from the database later? Right? Hmm, that > would solve most of my problems. But when somebody edits a post and then > commits the changes, then it is unnecessary to prepare the > permission-attributes for the view, but the primary key exists already. > In the meantime, I came up with a slightly different solution. Don't know > if it is good, but maybe it helps other people in similar situations to > read this. I extended the constructor call with a parameter "prepForView" > like this: > __init__(self, firstAttribute, secondAttribute, ..., prepForView = True): > so I can check at the end of the constructor: > if prepForView: > do all the permission assignments > So, when I get an object from the DB, prepForView has its default=True, and > when I create a new object, I can create it with: > newPost = model.Post(prepForView = False) > and thus avoid the overhead of the permission assignments. > Totally different question: > I have a class Post that inherits from a more general class Item. In my > assignment of the Item.mapper, I overrode some of the column names, with > the properties = { > 'contextId' : item.c.context_id > .. > } > But I just discovered (after 3 hours of looking for the problem), that when > I assign a mapper to the Post-class and inherit from the Item.mapper, I > have to override all the column names again! When I didn't override them in > Post.mapper at first, the inheritance-mapper used "context_id" as attribute > name instead of "contextId". Did I miss some kind of flag like > "useParentProperties" so I don't have to repeat all assignments (code > duplication)? > Anyway, thanks Gambit for your input! > Cheers, Martin Schnell und einfach ohne Anschlusswechsel zur Lycos DSL Flatrate wechseln und 3 Monate kostenlos ab effektiven 5,21 EUR pro Monat im ersten Jahr surfen. http://www.lycos.de/startseite/online/dsl/index.html?prod=DSL&trackingID=email_footertxt