From the homepage of django-mptt
Version 0.2.1 is not compatible with Django 1.0 and above - please use SVN trunk for now
I tend to avoid using trunk for work that is going live any time soon, But I have a rush job.
Does it work with Django 1.2, (beyond "hello world" equivalents) Does anyone have any current experience / odd bugs to share etc.
DJango-mptt on Google Code seems to have been abandoned, but there are a couple of forks on Github.
This one uses subclasses instead of registering the models, which makes in easier to use: http://github.com/bfirsh/django-mptt
However I'd recommend this fork, actively developed by one of the FeinCMS developers, which I've used with Django 1.2:
http://github.com/matthiask/django-mptt/
I'm using the trunk version since Django 1.2 is out and haven't run into any problems with that! Can't promise you that it will work for you; for known issues have a look at their tracker: http://code.google.com/p/django-mptt/issues/list
Related
Is Django-nonrel still active? I am interested on developing an e-commerce website that involves tons of catalogs and it seems like NoSQL is the best approach for this. I have background in Django but from what I found out, vanilla Django does not support NoSQL.
Enter the Django-nonrel as the alternative. However I am a bit concerned on the project continuity and community. Django-nonrel is a forked of Django 1.3, does this mean that it us outdated (since current Django is 1.5), or does it has its own circle and version after the fork?
In short, what is the status of Django-nonrel? Active?
This was recently discussed here:
http://www.reddit.com/r/django/comments/1cdrqs/using_mongodb_with_django_whats_the_status/
where the following stands out:
"It does not exist yet. And I'd strong recommend not using MongoDB unless you have a good use-case for it. Needing lots of reads/writes in some parts isn't enough to justify it IMO. MongoDB's read/write performance falls back down to earth once it's put in a real world scenario.
...
Disclaimer: I'm a dev working on a series of MongoDB apps that service hundreds of thousands of users and wish very much my predecessors just went with Postgres."
Yes it is, I am using for a year now and is working fine, the only downside, at least for me is that you can't do contains search.
If you want to change ideas please let me know.
django-nonrel is not active now, I´m testing the last version, it´s a django 1.6.11 fork
git+https://github.com/django-nonrel/django#nonrel-1.6
working with postgre and mongodb as DB engines simultaneously and it works
I don't know what I was thinking and I don't have any kind of tests on this project. I want to upgrade it to 1.4 to be able to add to it all kind of different tests and have a more rigid project. What tips or recommendations can you guys give me?
Thanks.
I would recommend you to read through the release notes for each release to try to identify any areas that have changed that might break your existing code. Find them here https://docs.djangoproject.com/en/dev/releases/
Since you don't have any tests for your project you just have to roll up your sleeves and run full site tests where you run your app and try to test as many features you can to see if it is working as epxected.
I have just done the 1.1.1 to 1.4 upgrade (but I had some tests to help me) and it was not that bad.
There are 2 aspects of the upgrade. One is just to get your app to run on the new version and one is to change/update your code to utilize the new features in the 1.4 release. I would recommend that you first get it to work properly, release it and then refactor your code as you go along to use any new feature.
We're using django-admin interface for the backoffice of our own apps, but it we do expose it to our clients.
I'm considering going with either django-admin-tools or grappelli, to conveniently add modules and additional interactivity to the dashboard and data views.
What are your experiences?
django-admin-tools seems to be less intrusive. When I checked it, Grappelli broke some of admin-site extensions or widgets. Maybe they fixed it, but I'm alredy using DAT on my projects.
If I had to summarize: DAT is more about functionality; Grappelli is a more about style. So whatever fits you, best, go with it. Being a design-driven company, we ended up going with Grappelli.
My company did this analysis when we decided to use Django admin as a client-facing backend for a CMS Product. DAT offers some interesting functionality, some of which is duplicated in grappelli and some of which is not. Grappelli offers a few interesting additions of its own. In the end, we went with grappelli because of the really nice styling. My recommendation is to try both. Early on, we included both in the project, set up their respective dashboards, and it took about 30 seconds to switch between the two.
The commenter is right about grappelli needing to be in sync with django. I made the mistake of upgrading django without checking with grappelli, and it broke several things. The latest version of grappelli supports Django 1.4 and we'll be upgrading them together.
You will need to keep Django and grappelli in sync... The current version of Django is 1.4, but the current version grappelli supports 1.3. There is a branch that supports 1.4 however. If you are willing to support the minor hassle of managing this, grappelli offers some nice enhancements and a slicker look - starting with being able to set the title to the admin interface without copying and editing the admin template.
Depending on what you are doing, nice DateTime pickers (with "Today" and "Now" buttons) as well as sortable inlines can be very convenient.
Here is a little more up to date answer:
I have been using both but now am slowly moving towards grapelli, especially for new projects. Grapelli has for the most part caught up with django admin tools in terms of creating custom dashboards and menus. I still haven't seen all the features like draggable panels. Grapelli has better support and this can be seen by the repository activity. It was first to support Django 1.7 and at the time of me writing this, DAT did not offer that support yet. The reported bugs also do not get patched very often. I am also liking the way Grapelli looks and it is used in Mezzanine, my favourite cms.
Here are the two repositories if you wish to look:
https://bitbucket.org/izi/django-admin-tools/overview
https://github.com/sehmaschine/django-grappelli
Hope this helps.
Is there any guidance on how to write modular Ember.js apps? I have seen Tom Dale's position on AMD here so I am not going to force fit AMD on to the framework (as some have attempted here). It appears that Ember internally uses bpm/spade. Is that a reasonable approach to modularize Ember apps too? Any samples using this approach?
P.S. The getbpm.org site seems to be down which makes it difficult to learn about it. There is a github page but it refers to the site for install instructions.
BPM in it's current form is no longer supported by the core team, but is community supported. The only build tools they are officially providing support for is rake-pipeline. However, BPM does still work and it works well (I still use it with my projects). For info on how to use it see this: https://github.com/ud3323/bpm/wiki/Using-BPM-with-Ember. You may want to use my fork of bpm too. I've merged in Joe West's support for a proxy middleware.
There is also community build tools for node.js called ember-runner which looks promising as well.
As for using rake-pipeline. Look at the AssetFile on the emberjs projects to see how must be configured using rake-pipeline and rake-pipeline-web-filters. Also, take a look at the answers to this question on StackOverflow (especially Yehuda's). You may also find this gist helpful as well.
Try Ember App Kit - maybe it would help you.
I have played a bit with Rails, so for me, creating a rails 3.2 app was the easiest way to achieve this. So if you don't mind using rails as a back-end, I this might suit you.
Perhaps ember-tools could help:
https://github.com/rpflorence/ember-tools
I am novice still I found yeoman and ember-generator useful. In future you might need to add tests , mock rest calls you can easily npm install sinonjs and npm install ic-ajax
Does anyone here use django-grappelli here ?
I would like to read some experience of developers or users, if there are common mistake to avoid or why you use or do not use grappelli.
Thanks for sharing
I'm using grappelli as well. I'd be content with django's normal admin, but if you need to present the backend to someone else grappelli is much more appealing.
The current grappelli version 2.1 is working quite good with django 1.2. The only problems you(sometimes) run into is that 3rd party apps have sometimes some problems, which you can solve in most cases quite easily with changing the custom templates they are coming with (in most cases it's just other names for css classes etc, sometimes there are some js incompatibilities as well, which you can solve easily!
The actual version of grappelli also has a nicer html/css framework which enables you to easily use their styles/ui elements in your own templates. Have a look at http://grappelliproject.com/ for that (it's not totally valid for the actual version but gives you a small impression on what to expect!)
According to the developers, grappelli should soon work together with the marvellous django-admin-tools,which offer you drop down menus within the admin and a customizable index dashboard! Installation is not quite complicated, just do not forget to pass the adminmedia folder to manage.py! All in all I think it's quite recommendable (also check out django-filebrowser and medman if you dont know them yet, which come from the same developers and work very well together with grappelli)!
I have used Grappelli several places and suggest using it, if you are using admin for anything more than a "database debugging" purpose.
From django 1.1.1 onwards, you can create multiple instances of admin, so generally, I keep the main admin to examine the data as it is, and another instance of it for using purpose, with grappelli.
A minor issue is that,
On the dev server, it is hard to ask django to use a different admin media folder, and the easiest way is to use the command line parameter, as it is documented.
I started using django-grappelli recently and will like to point out 2 cases that newbies like me have a high chance of wasting time on:
For Django==1.6, use grappelli==2.5 and not the current latest 2.6. Also for Django==1.5/1.4 use grappelli==2.4.The official docs clearly mention it but many may overlook it and later wonder why it is not working.
In INSTALLED_APPS setting, if grappelli is not placed above django default apps it will not work. I used to think that order is not of importance for INSTALLED_APPS but this made me change my mind.