I'm discovering django-activity-stream, I would like to use it on our website for showing a news feed based on follow relationships (like Twitter) and a profile feed. It seems perfect for doing this.
However, it doesn't seem really great for notifications feed. So :
Should I use django-notifications which is dedicated for this use case ? (Maybe both framework are meant to work as a pair, is there specific configuration for that ?)
Or should I just tweak django-activity-stream(considering that both framework are based on the same structure) and how ?
FYI : I don't need template features as I'm building a REST API (with django-rest-framework).
You just need to use both packages for their own purpose. Just follow their docs and you will get many thing answered.
django-notification is based on django-activity-stream and can be used for github-like notifications. you can serialize the django motifications models with django rest framework.
Related
I would like to build a REST Service which exchanges JSON messages with instances of a mobile app for registering patron traffic in physical locations of (public and academic) libraries.
I plan on using Django Rest Framework, and using Django and DRF for the first time, have some questions (rather, recommendation requests). I have read the tutorials and followed some of them, and it looks very promising indeed.
As I am quite confident with Object oriented coding in Python, I will be using class based views. Any reason not to?
The intended usage of the system will include many different libraries with their own ids, users and properties. The data model behind is thus fairly complex, and implemented with MySQL. I feel I will have better control on the data exchange, updates inserts and selects, with custom SQL queries, and would like the DRF to handle mostly authentication and the routing of messages to and from the instances of the mobile app. Is this a misconception on my part, and would it be better to let DRF handle all database-involved aspects?
Given that I follow the custom SQL approach:
As (authenticated) user IDs are interwoven with the rest of the activities (e.g. we would like to know which of the authenticated users stands behind a certain registration of activity), it would seem "simple" to use a single database for both the business model itself and the DRF-controlled aspects. Is it recommended ? Are there any aspects that need to be considered here?
I have not found similar projects to be learning from. Anybody knows a similar project?
I know it is not very concrete, but hope to elevate my understanding a bit while endeavoring on the task.
Michael
I have tried to keep this as unopinionated as possible. Mostly reffering from Django's and DRF's documentation to make sure.
Class based views have some implicit code flows, need method overrides at some places. But since you are quite comfortable with Class based views, it is far more superior in the following ways: cleaner code, much more DRY compliant than function based, easier to extend, keeps your code base more maintainable as it grows.
Django's ORM is pretty powerful and if used correctly it can provide a vareity of capabilities.
Unless your authentication system is very complex and needs to scale independently, having everything in the same DB makes sense. The chatter reduces and you will be able to utilise powerful Django and DRF's features.
I'm creating a django app which needs some document management functionality - users will upload documents, they'll be viewing lists of the documents and selecting them in fairly simple ways (Primarily, they'll be shown a set of documents in specific categories shared by others in their organisation).
Because I want to integrate this with my app, I don't need a very feature rich user interface (in fact, the app or library could be entirely unusable without further coding without that being a problem). It does have to be usable with django.
So - what are some good apps or libraries for django that provide appropriate models and UI elements suitable for integration into a larger app.?
I've looked at the django packages page, and none of the items on there are, as far as I can, see especially suitable. In particular, Mayan does not appear to have been created with integration in mind.
I haven't personally used these apps, but Django Packages is always a good starting place. Have you looked at under Document Management?
Mayan (rtd, github, homepage) looks to be actively maintained and pretty mature.
The other two listed are django-treenav and django-file-picker, though they do not seem to be as robust or as actively maintained, but they may be a good fit given your basic needs.
Of course if your needs are simple it may be just as easy to implement it yourself, django model's FileField is straightforward to use and they have great documentation on how to handle file uploads from forms - https://docs.djangoproject.com/en/dev/topics/http/file-uploads/.
Following this post (I was looking for a library allowing me to declare Django models on a ldap backend), I have decided to use ldapdb. After having played a while with this library, I figured out that it doesn't reach the level of control I need, and I am therefore looking for other solutions. What I am thinking of now is implementing a Django db backend based on python-ldap.
EDIT
I need this because I am currently implementing a user/group management system on a ldap directory (it requires to be able to manipulate not only users, but different classes of ldap objects as well). So basically, I would like to be able to use (nearly) full Django orm, but with a ldap backend.
Because I love Django (and would be rather motivated in learning the dirty low-level details of db.backends), and because there's already a lot of things implemented in this project, I would like to stick to Django (unless somebody has a very good reason why I shouldn't, and a very good alternative !).
Do some of you have a simpler solution to this problem ?
Do some of you know about an implementation of such a thing (ldap db backend) ?
Do some of you know some good reads to get started on "implementing a Django db backend"?
Are some of you interested in helping with this project ?
You make a lot of bold statements such as "lots of things broken because of the way it is implemented" and "the subclassing is very very far from being complete", would you care to elaborate on them? As the author of django-ldapdb I would welcome your suggestions as to what you would like changed/fixed, that's what the django-ldapdb mailing list is for!
FYI, I took the approach of subclassing the Model class because you will usually want to have just a couple of models using the LDAP backend, not all the models in your application, and django 1.1 did not support multiple databases. Also, LDAP is very different from existing SQL backends:
is not a relational database
it is not "flat", it is a tree-like
the true "primary key" for an entry is the Distinguished Name (DN), which is not an actual field, but a value computed from other fields
fields can be multi-valued
For all these reasons, I have serious doubts as to what can be achieved by writing a true LDAP backend. I think you will always have some LDAP-specific quirks, and subclassing Model allows just that.
Your best bet is probably to write an authentication backend for the application. Here is some documentation about it:
http://docs.djangoproject.com/en/dev/topics/auth/?from=olddocs#writing-an-authentication-backend
And here is an article that explains how to extend the User model to enable you to use this authentication backend seamlessly:
http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/
Seems like there's no really good solution. And doing everything without Django's ORM is no good solution either.
I'll make new attempt at solving that problem soon, with a django-orm-based solution.
Im still fairly new to Django, so please explain things with that in
mind.
I'm trying to create three websites using 2 subdomains and 1 domain:
for the blog, blog.mysite.com
for the forums, forums.mysite.com
for the custom web app, mysite.com
When building the custom web app, I used contrib.auth to make use of
the built-in django provided user models and functionality.
For the forums, I am planning on using SNAPboard (http://
code.google.com/p/snapboard/) with minimal, if any, modifications. On
initial inspection, it looks like it also uses contrib.auth users.
For the blog, I will probably be rolling my own lightweight blogging
app (since that seems to be the Django way and, also, b/c as Bennet
mentions, there is no killer Django Blog app)
Currently, I am considering two features that require some integration
between the three sites. First, I want to have the users of the custom
web app to use the same account to also log into the forums. Second, I
also (but I haven't figured out how I'm going to do this yet) would
like my blog posts to automatically become a topic for discussion in
the forums (this is just an idea I had, I might end up dropping it).
Ok, so to my questions:
1) Again, I'm new to Django, but this integration leads me to believe
the three websites need to be all under one project. Is this correct?
2) How would I accomplish the url structure for the websites that I
described above (blog.mysite.com, etc)? In the project's urls.py, I
don't know how to filter off of subdomains. If it was mysite.com/
forums/, that would be easy, but I don't know how to to catch
forums.mysite.com and forward it to the appropriate Django app.
3) Would I have to make use of the django.contrib.sites framework? I
don't understand that framework fully, but it seems like it's used
when two different websites are using the same django app in the
background. Whereas my three websites are all using different django
apps, but I want them to share a little bit of data.
Thanks for your help.
1) Yes, it's only true way for that
2) Use middleware
3) No, you don't need it.
I have been struggling with choosing a methodology for creating a RESTful API with Django. None of the approaches I've tried seem to be the "silver" bullet. WAPI from http://fi.am is probably the closest to what I would like to accomplish, however I am not sure if it is acceptable in a true RESTful API to have parameters that are resource identifiers be in the querystring instead of in a "clean" URL format. Any suggestions for modifying WAPIs RestBinding.PATTERN to "clean" up the URLs? Another option I've explored is Django-Rest-Interface. However this framework seems to violate one of the most important pieces I need, and that is to include the full resource URL for references to other resources (see http://jacobian.org/writing/rest-worst-practices/ Improper Use of Links). The final option is to use django-multiresponse and basically do it the long way.
Please offer me your best advice, especially people that have dealt with this decision.
For Django, besides tastypie and piston, django-rest-framework is a promising one worth mentioning. I've already migrated one of my projects on it smoothly.
Django REST framework is a lightweight REST framework for Django, that
aims to make it easy to build well-connected, self-describing RESTful
Web APIs.
Quick example:
from django.conf.urls.defaults import patterns, url
from djangorestframework.resources import ModelResource
from djangorestframework.views import ListOrCreateModelView, InstanceModelView
from myapp.models import MyModel
class MyResource(ModelResource):
model = MyModel
urlpatterns = patterns('',
url(r'^$', ListOrCreateModelView.as_view(resource=MyResource)),
url(r'^(?P<pk>[^/]+)/$', InstanceModelView.as_view(resource=MyResource)),
)
Take the example from the official site, all above codes provide api, self explained documentation (like soap based webservice) and even sandboxing for testing. Very convenient.
Links:
http://django-rest-framework.org/
I believe the recently released django-piston is now the best solution for creating a proper REST interface in Django. django-piston
Note: django-piston seems to no longer be maintained (see comments below)
django-tastypie is a good way to do it, their slogan: "Creating delicious APIs for Django apps since 2010" is pretty comforting ;)
You could take look at django-dynamicresponse, which is a lightweight framework for adding REST API with JSON to your Django applications.
It requires minimal changes to add API support to existing Django apps, and makes it straight-forward to build-in API from the start in new projects.
Basically, it includes middleware support for parsing JSON into request.POST, in addition to serializing the returned context to JSON or rendering a template/redirecting conditionally based on the request type.
This approach differs from other frameworks (such as django-piston) in that you do not need to create separate handlers for API requests. You can also reuse your existing view logic, and keep using form validation etc. like normal views.
I don't know if this project can be useful for you, but sending a link can hardly hurt. Take a look at django-apibuilder , available from http://opensource.washingtontimes.com/projects/django-apibuilder/ . Perhaps it can be useful?
/Jesper
Have a look at this RestifyDjango.
Somewhat related are Django XML-RPC and JSON-RPC.
https://github.com/RueLaLa/savory-pie
Savory Pie is a REST framework that supports django.
I would suggest you look into Django Rest Framework (DRF), play around with this and see if it suits your requirements. The reason I recommend DRF is because it makes making the API views really simple with the use of GenericAPIView classes, Mixin Classes and Mixed in Generic views. You can easily make use of tried and tested design patterns for making your API endpoints as well as keeping your code base neat and concise. You also DRY when writing your code which is always great. Your API views are literally 2-3 lines long.
You can checkout this tutorial http://programmathics.com/programming/python/django-rest-framework-setup/ that begins from setting up your environment to going through the different ways to make your RESTful API using the django rest framework.
Disclaimer: I am the creator of that website.