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

Reply via email to