Andreas/evennia
1
0
Fork 0
mirror of https://github.com/evennia/evennia.git synced 2026-03-16 21:06:30 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Refactor of class_setting from init in typeclass so we can just call it from django admin, and avoid weirdness of calling init twice, which seemed to mess things up

Browse source
This commit is contained in:
Tehom 2016-12-05 07:53:06 -05:00
parent 560def1f2b
commit ae0b4bad55
2 changed files with 38 additions and 34 deletions
Download patch file Download diff file Expand all files Collapse all files

2
evennia/objects/admin.py
View file

@ -148,7 +148,7 @@ class ObjectDBAdmin(admin.ModelAdmin):
if not change:
# adding a new object
# have to call init with typeclass passed to it
obj.__init__(typeclass=obj.db_typeclass_path)
obj.set_class_from_typeclass(typeclass_path=obj.db_typeclass_path)
obj.basetype_setup()
obj.basetype_posthook_setup()
obj.at_object_creation()

70
evennia/typeclasses/models.py
View file

@ -195,39 +195,7 @@ class TypedObject(SharedMemoryModel):
# typeclass mechanism
def __init__(self, *args, **kwargs):
"""
The `__init__` method of typeclasses is the core operational
code of the typeclass system, where it dynamically re-applies
a class based on the db_typeclass_path database field rather
than use the one in the model.
Args:
Passed through to parent.
Kwargs:
Passed through to parent.
Notes:
The loading mechanism will attempt the following steps:
1. Attempt to load typeclass given on command line
2. Attempt to load typeclass stored in db_typeclass_path
3. Attempt to load `__settingsclasspath__`, which is by the
default classes defined to be the respective user-set
base typeclass settings, like `BASE_OBJECT_TYPECLASS`.
4. Attempt to load `__defaultclasspath__`, which is the
base classes in the library, like DefaultObject etc.
5. If everything else fails, use the database model.
Normal operation is to load successfully at either step 1
or 2 depending on how the class was called. Tracebacks
will be logged for every step the loader must take beyond
2.
"""
typeclass_path = kwargs.pop("typeclass", None)
super(TypedObject, self).__init__(*args, **kwargs)
def set_class_from_typeclass(self, typeclass_path=None):
if typeclass_path:
try:
self.__class__ = class_from_module(typeclass_path, defaultpaths=settings.TYPECLASS_PATHS)
@ -266,6 +234,42 @@ class TypedObject(SharedMemoryModel):
self.db_typeclass_path = "evennia.objects.objects.DefaultObject"
log_trace("Critical: Class %s of %s is not a valid typeclass!\nTemporarily falling back to %s." % (err_class, self, self.__class__))
def __init__(self, *args, **kwargs):
"""
The `__init__` method of typeclasses is the core operational
code of the typeclass system, where it dynamically re-applies
a class based on the db_typeclass_path database field rather
than use the one in the model.
Args:
Passed through to parent.
Kwargs:
Passed through to parent.
Notes:
The loading mechanism will attempt the following steps:
1. Attempt to load typeclass given on command line
2. Attempt to load typeclass stored in db_typeclass_path
3. Attempt to load `__settingsclasspath__`, which is by the
default classes defined to be the respective user-set
base typeclass settings, like `BASE_OBJECT_TYPECLASS`.
4. Attempt to load `__defaultclasspath__`, which is the
base classes in the library, like DefaultObject etc.
5. If everything else fails, use the database model.
Normal operation is to load successfully at either step 1
or 2 depending on how the class was called. Tracebacks
will be logged for every step the loader must take beyond
2.
"""
typeclass_path = kwargs.pop("typeclass", None)
super(TypedObject, self).__init__(*args, **kwargs)
self.set_class_from_typeclass(typeclass_path=typeclass_path)
# initialize all handlers in a lazy fashion
@lazy_property
def attributes(self):