OK, so my calender component is only a little entrenched in my app. I
think it can still be rescued, but I'm gonna let it sit for now while
I try a 2nd component: user to user messages. yeah, basic email.
Only later it will get hooked into the calender and stuff. so forgive
me for implementing postfix.
*the plan*
Implement the following as abstract classes that are not a django
app. a django app will create subclasses of them, possibly with no
additional functionality. templates aren't classes, but they do have
class like behavior, hopefully enough for what I am doing.
models:
existing django user
message: to, from, date, subject, body. maybe tread id.
views:
send, list of subjects, view message, reply (extension of send)
templates:
same as views? I need some web2.0ness for the 'to' entry.
am I missing anything ?
I think it's an excellent candidate for the HCoF.
As to the completeness of the high-level design, CarlFK: I'd add a
message status to the model (to capture read/unread) and distinguish
views for "inbox" versus "sent messages". By expanding the values of
the message status field, you could also add views for "kept
messages" and "trash".
James
yes. and making it portable to other peoples work, but keeping the
files/dirs separate so that they can be maintained as a project.
(think svn update.)
>
> I think it's an excellent candidate for the HCoF.
What is HCoF?
Here is what I am currently working with.
# msg/model.py
from django.db import models
from django.contrib.auth.models import User
class Message(models.Model):
to = models.ForeignKey(User, related_name = "messages_received")
sender = models.ForeignKey(User, related_name = "messages_sent")
subject = models.CharField(maxlength=50)
sent = models.DateTimeField(auto_now_add=True)
recieved = models.DateTimeField(null=True)
read = models.BooleanField(default=False)
body = models.TextField()
def __str__(self):
return self.subject
# class Admin:
# list_display = ('sent', 'to', 'sender', 'subject')
class Meta:
db_table = 'message'
# core/models.py
from django.contrib.auth.models import User
import msg.models
class Message(msg.models.Message):
status = models.CharField(maxlength=1, blank=True)
class Admin:
list_display = ('sent', 'to', 'sender', 'subject')
class Meta:
db_table = 'message'
One thing makes me extra nervous: class Message(x.Message) Is naming
the class the same as its parent a thing good or bad?
Carl K
ps, why am I not seeing these posts in my normal email like I do with
the other 2 d-lists?