User Reply Functionality

[karlmoritz]

Hi Maraujop,

thanks for your work on persistent-messages! I think as far as django messaging goes, this is one of the most promising approaches out here.

I would like to gradually extend the system to offer a fully fledged messaging system for both site notices as well as user messaging. The changes attached add two fields "parent_msg" and "replied" to the message model, allowing messages to have a parent message and to check whether or not a message has been replied to. This should make it easy to thread messages etc.

I've also added some initial templates (adopted from django-messages) for the inbox and compose page.

Please let me know if you're interested in taking the app into that direction, it'd be nice to do this together and on your fork rather than creating yet another fork of the project.

Karl Moritz

[maraujop]

Hi Karl,

Sorry to take so long to answer your pull request.

As you know, this is my work on a fork of the original project. I'm not using this application in any current projects. But there are some things you need to know.

When I started extending the functionality behind django-persistent-messages, I thought that the fact that it was tied to contrib.messages was a good thing. I thought that meant coding less and using more of Django's code, well coded and tested. But the truth is that with the time, the fact that this implements a messages Backend, makes it rigid. contrib.messages was thought for volatile system messages, nothing fancier, so this rigid architecture doesn't really match and doesn't boost any extra power. In the end it constrains you and makes you do some ugly hacks.

I've always thought that Django is missing a good inter-user messaging application, with threaded messages, system messages, private messages, some nice templates, some nice built-in views, good test coverage. But in the end, no one out there has all of this. This one could with a lot of work, but I honestly think detaching this from contrib.messages would be a good first step. After that, adding an initial test suite would be probably the smart second step. Then I would go for better docs and extra functionality, with south for model migrations, etc.

I honestly think that should live in a separate repository, more visible in Github and more visible to the Django community, with a brand new name. I'm not sure what to do with this fork at the moment, probably in the future I will have to face this problem again in another project. Time constraints always force you to reuse things you would like to polish.

I would really like to know what you think about what I'm saying. Maybe we can work together on it.

Cheers,
Miguel

[karlmoritz]

Hi Miguel,

thanks for getting back to me.

For my current project I've ended up hacking persistent-messages quite a
bit more, but ended up hacking it in a way that doesn't make it very
reusable for other projects I'm afraid. I agree that Django could use a
standard / well-maintained messaging solution, and would be happy to get
involved in building it.

As far as the integration with contrib.messages goes, I actually quite
appreciate this at the moment - from an API side it's nice if the switch
between a non-permanent (e.g. system) and a permanent (e.g. private)
message is quite simple, and also the possibility of interlacing the
display of both types of messages.

That said, we could still detach from contrib.messages and subsequently add
non-permanent messaging to our module. I agree that this might be a tidier
solution in the long run.

For my current project I have some pretty tight deadlines, so will go ahead
with my hack for now. That said, if you're keen to get working on messaging
again, let me know and we could bootstrap a new app, independent of
contrib.messages. I think this would definitely be a good contribution to
Django generally (and surely I'll find use for it in future projects).

Cheers,
Karl Moritz

On 12 February 2012 16:49, Miguel Araujo <
[email protected]

wrote:

Hi Karl,

Sorry to take so long to answer your pull request.

As you know, this is my work on a fork of the original project. I'm not
using this application in any current projects. But there are some things
you need to know.

When I started extending the functionality behind
django-persistent-messages, I thought that the fact that it was tied to
contrib.messages was a good thing. I thought that meant coding less and
using more of Django's code, well coded and tested. But the truth is that
with the time, the fact that this implements a messages Backend, makes it
rigid. contrib.messages was thought for volatile system messages, nothing
fancier, so this rigid architecture doesn't really match and doesn't boost
any extra power. In the end it constrains you and makes you do some ugly
hacks.

I've always thought that Django is missing a good inter-user messaging
application, with threaded messages, system messages, private messages,
some nice templates, some nice built-in views, good test coverage. But in
the end, no one out there has all of this. This one could with a lot of
work, but I honestly think detaching this from contrib.messages would be
a good first step. After that, adding an initial test suite would be
probably the smart second step. Then I would go for better docs and extra
functionality, with south for model migrations, etc.

I honestly think that should live in a separate repository, more visible
in Github and more visible to the Django community, with a brand new name.
I'm not sure what to do with this fork at the moment, probably in the
future I will have to face this problem again in another project. Time
constraints always force you to reuse things you would like to polish.

I would really like to know what you think about what I'm saying. Maybe we
can work together on it.

Cheers,
Miguel

---

Reply to this email directly or view it on GitHub:

#2 (comment)