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
--------------------------------------------------------------------
Previous message:
Hey Marty,
I don't claim to fully understand what your problem is, but...
I think you're on the right track for putting the properties in the __init__
method for your class. I'm not sure why you're worried about the overhead,
though, since it seems to be something like:
if currentUser.perms == godlike:
self.deletable = True
self.editable = True
but maybe there's more to it then that. Perhaps a quick check to see if the
object is coming from the database, and then doing the various logic branches
would be appropriate? I usually use the existence/value of a primary key
field as a check:
if hasattr(self, 'pk') == True:
if curentUser.perms == godlike...
else:
self.deletable = True...
Otherwise... more information, please? :)
-G
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
