-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
idm med tktitler #127
idm med tktitler #127
Conversation
Navnet |
@@ -236,6 +96,9 @@ class Title(models.Model): | |||
root = models.CharField(max_length=10, verbose_name='Titel') | |||
kind = models.CharField(max_length=10, choices=KIND, verbose_name='Slags') | |||
|
|||
def titletupel(self): | |||
return (self.root, self.period) | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Tupel" er ikke engelsk. Jeg synes det bør hedde "title_tuple".
@@ -14,3 +14,4 @@ django-macros>=0.4.0 | |||
unidecode>=0.04.19 | |||
mysqlclient>=1.3.7 | |||
django-multiupload==0.5.2 | |||
git+git://github.com/TK-IT/tktitler.git@v0.2.1#egg=tktitler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Da prodekanus er firewalled bør vi bruge git+https i requirements.
Måske er jeg on a limb: Hvis vi gør class Title(models.Model):
#[…]
def __iter__(self):
return iter((self.root, self.period))
someTitle = Title.objects.all()[0]
tktitler.postfix(someTitle) # "FUØP16" Jeg ved ikke om der er nogle problemer i at gøre en Django model iterabel. Eller om det overhovedet giver mening. |
Jeg synes det er dårligt at gøre Title iterabel, fordi Explicit is better than implicit. Jeg vil hellere have at tktitler tjekker for en titel_tuple metode på inputtet - og eventuelt kan tktitler erklære en abstrakt baseklasse som et objekt skal abstrakt nedarve fra før den tjekker om objektet har en titel_tuple(). Se collections.ABCMeta. |
Hvis jeg forstår ABC og metaklasser korrekt, så kunne en løsning være: # tktitler.py
#[…]
class Title(metaclass=ABCMeta):
@abstractmethod
def title_tuple(self):
pass
# idm/models.py
#[…]
class Title(models.Model, tk.Title):
#[…]
def title_tuple(self):
return (self.root, self.period) Det virker dog ikke fordi Django selv bruger metaklasser og det er ikke entydigt hvilken metaklasse der skal bruges:
En 'løsning' er måske: class MyMeta(ABCMeta, models.base.ModelBase):
pass
class MyTitle(metaclass = MyMeta):
pass
class Title(MyTitle, models.Model, tk.Title): men jeg er ude på dybt vand. Desuden bliver det for kompleks til at det giver mening. Er der noget jeg har overset? |
Beklager jeg ikke linkede præcist nok. Jeg mener at vi kan bruge ABCMeta.register. https://docs.python.org/3.6/library/abc.html#abc.ABCMeta.register Så behøver vi ikke ændre på hvilke klasser Title rent faktisk nedarver fra. |
Med Den eneste fordel er vel så at man kan bruge |
Ja, det er kun issubclass der ændres når man registrerer en ny subklasse. Forskellen på hasattr og issubclass er at issubclass (EDIT: hasattr) ikke har nogen forståelse for navnerum, hvorimod register/issubclass har. Derfor er register bedre. Hvis et andet interface i verden bruger metodenavnet titel_tuple, og vi blot tjekker efter metodenavnet, så kan det være at vi accepterer objekter der ikke burde accepteres. Med register skriver forfatteren bag klassen eksplicit, at de understøtter vores interface. Det er mere kompliceret at bruge register og issubclass end at bruge hasattr, så hasattr er bedre i dén anseende. Hvad synes du er bedst? |
|
Jeg er tilfreds sålænge vi giver en meningsfyldt fejlmelding når argumentet ikke implementerer klassen. Hvis argumentet implementerer det, men ikke har den rigtige metode, så er det (efter min mening) i orden at give en fejlmelding der ikke giver mening. |
Jeg har implementeret en tk.title_class decorator i tktitler/#20. |
Hvad med at sætte tktitler gfyear i en middleware? Så kan vi gå fra et sted mellem 0 og 100 kald til config.GFYEAR pr. view til (næsten) altid ét kald pr. view, og vi kan slippe for at henvise til constance de fleste steder. Ulemperne er 1) vi tilgår databasen selv på views der ikke bruger config.GFYEAR til noget, og 2) det fremgår ikke af koden at året hentes via constance. |
Et første bud på hvordan idm kan bruge tktitler.
Jeg vil mene at de fleste funktioner under
Title
-classen skal fjernes. Ideen var at flytte valget af præsentationen af en titel længere op. Måske erTitle.titletupel
ogTitle.parse
nok. Jeg er dog ikke sikker på hvordan regnskab afhænger af det endnu.