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.
Related
I was looking for a tagging/categorization app for a Django project. In past I have used django-tagging and django-taggit. Looks like they are not being actively maintained. I also saw a few others but they are either unmaintained of don't really reach the functionality of these two.
The kind of project I was working on for past year did not require tagging like functionality therefore I am out of touch in this area.
So before starting on writing my own app I thought, I would ask the mighty Stackoverflow community if there are any maintained forks of these apps or if there others similar to them.
Thanks in advance.
I've used both on different projects, too with different Django versions. There are some forks to. For instance, for django-tagging there is django-tagging-ng that provides multilingual, synonyms and hierarchy.
I would simply refer to opencomparison for package comparisons of django apps here - http://django.opencomparison.org/grids/g/tagging/
And I would go with django-tagging and add in django-tagging-ext optionally.
Is this what you are looking for?
https://github.com/bkjones/django-taxonomy
I want to create a pretty simple site with a few pages using Django. I guess I could use Wordpress. But there is some custom stuff (like a special kind of calendar app) that I rather do in Python than PHP.
I came across simple-pages which seems like a nice middle way between flat-pages and a fullblown Django CMS (which just seems overkill). It can automatically generate menus. But it seems like it hasn't been updated in a long time. Is it deprecated or is it stable? Or do flat-pages have the same functionality these days?
Honestly, It would be super easy to build your own small custom CMS since you know python. It would only take a few models and not a lot of time - the result being something better customized for your needs.
I've used some of these examples before - and they work ok, but I always find myself having to add something more.
One idea is to check out what sub-applications some of these things are using - maybe import only what you really need.
But I almost always find myself spending a LITTLE extra time to build out my own schema/structure for simple pages Then using a nice admin skin like grappelli when handing it over to clients (you get SORT of that wordpress feel (sort of))
Lots of admin customization that can make it easy for clients (and You) to work with static pages.
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.
After reading the Jinja2 documentation, I'm interested in employing it in future Django projects. However, I'm wondering if anyone has encountered any drawbacks or gotchas when using Jinja2 templates with Django? If so, how did you work around them?
I wouldn't mind hearing about positive experiences either, just to get a good cross section of the best and worst of Jinja2.
I use Jinja2 in some of my projects and love the extra expressiveness it gives me. I can keep my presentation logic and application logic separate, but I don't have to bend over backwards to call into a function/method I've designed specifically for my presentation layer.
In addition to what's already been listed by other posters, here are some things that I've found:
The Admin app is tightly coupled to Django templates
The default views and decorators that come with the Auth app (and elsewhere) are coupled to Django templates, so you may have to duplicate the effort if you want to use your Jinja2 templates for login/logout/etc
Behaviorally, Django templates will escape its output by default whereas Jinja2 will not. I think either approach has its own merits, but you have to keep this in mind if you are switching between the two.
I've documented several of the syntax, config, filter, and interoperability considerations for Django -> Jinja2 on my wiki
I haven't used Jinja2 with an actual Django site yet, but I did convert an application using Django templates in standalone mode over to Jinja2 templates. The only (very minor) problem I encountered was lack of the {% spaceless %} template tag.
Extending Jinja2 is much harder than Django template system (I'm talking about templatetags). While most of inclusion tags functionality can be achieved using macros in Jinja (they even seem to be more appropriate), writing bit more complicated tags is really hard in Jinja (see the docs for yourself).
Other than that, the only obstacle are Django-based habits... ;)
There's been some new code added in the Django trunk that lets you write TemplateLoaders and Template classes that can be used to work with different template languages. Docs have been added for it at http://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alternative-template-language, and it will be in the 1.2 release. This should cut out most of the gotchas with things like using custom templates for login, logout, admin etc.
An alternate solution is to use a layer on top of Django, like Chouwa or Djinja2. You will have issues getting Django's builtin views to use your templates, but it works if you don't want to use Django trunk.
Once you've done either of those, the only really major issue is that most of the stuff Django exposes to templates (especially for the comments framework) is exposed in custom tags, which don't translate to Jinja2. Sadly, backwards-compatibility concerns don't see this changing anytime soon.
For me, the most annoying thing from using Jinja2 in Django is that you won't be able to use some Django apps when they come with their own templates or template tags (e.g. django-uni-forms).
This can be frustrating some times, when you find a great app that solves your problems but you can't use it because it's not compatible with Jinja2.
BTW, it seems that Armin Ronacher (the author of Jinja2) will be working on a new template engine backend that will sit behind both Jinja2 and Django, replacing the current infrastructure but preserving backwards-compatibility. https://www.djangoproject.com/weblog/2011/apr/25/gsoc/
re: the lack of {% spaceless %} in jinja2, check out the jinja2htmlcompress module:
# In shell:
fetch -o myapp/jinja2htmlcompress.py https://raw.github.com/mitsuhiko/jinja2-htmlcompress/master/jinja2htmlcompress.py
# In your app:
app = Flask(__name__, static_path='/static')
app.config.from_object('myapp.default_settings')
app.jinja_env.add_extension('myapp.jinja2htmlcompress.HTMLCompress')
As April 2015, Django 1.8 supports rendering templates with multiple engines within the same project, and has built-in support for Jinja2. So it doesn't have to be an all-or-nothing decision anymore.
(While this isn't directly answering the question, since this was previously the case I thought it merited more than just a comment).
I had some issues getting crispy-forms to work with Jinja2. There is a pretty easy way to solve this however.
django crispy forms with jinja2
I think in general downside will most likely be similar often used Django packages that just don't play with Jinja2
First, some background information... I'm coming up on a medium-scale website for a non-profit that will require both English and Korean translations. Feature-set includes: CMS for normal content, a blog, some form submission/handling (including CSV/PDF exports), a job posting board, a directory of related businesses and non-profits (that accepts visitor submissions), and a basic (probably blog-driven) newsroom.
I have a fairly strong development background, and I've done some sites using Drupal, built some basic custom CMSes using frameworks like CodeIgniter, and I've recently started getting into Django. These are the primary options that I am exploring, and I would consider using different tools for different portions of the project, but what I'm mainly interested in, is if anyone has any experience to share with regards to localization/internationalization. I haven't yet put together a site that supports multiple languages, so before I get in trouble by underestimating the task, or making poor assumptions, I'd like to get some input to help guide my decision-making process.
Do you have any recommendations for frameworks (Drupal, Django, CodeIgniter) that handle localization/internationalization/translation well for a CMS? I know they all support it, but I'm looking for real-world experience here (or suggestions for modules/plugins given explanations).
Sorry for the longwinded question, but I wanted to be clear as possible. Thanks in advance!
There is a distinction between "site" translation and content translation. Django handles the site translation great, out of the box. The content translation, however, requires making some decisions (there's no one right way at this point). This probably makes sense, because of the very nature of Django as a lower level framework (when compared to something like Drupal, which is intended to serve as a complete CMS).
There are applications for Django which are meant to add this functionality (in the form of translations configured at the model level):
Django-multilingual
Transmeta
Also, I found this question that is related.
The bottom line though, is that this is still being explored in the Django world, and neither approach has been decided upon for the framework. Also, although I haven't used it, Drupal has module support for this in the form of the i18n module.
I will update with more conclusions as I come to them. If you have anything to add about content translation in Django or in Drupal, feel free to add your own answer as well.
You probably already know that the native i18n support in django is quite good. As for translation, you might try the django-rosetta app which allows you to grant translation rights to a subset of users, who are then able to translate through an admin-like interface.
Zend_Translate is pretty comprehensive. And if you decide to use PHP, I suggest you take a look at it. It provides multiple interfaces (e.g. an Array, CSV, Gettext, etc.) to manage your translations, which makes it IMHO unmatched when it comes to PHP.
I'm not sure how well it plays with Drupal, since Drupal is hardly a framework but more a CMS -- or maybe a CMS framework. I'm pretty sure that Drupal either has a thing build in or that there is a plugin for it.
With CodeIgniter you would start from scratch and Zend_Translate plays well with it.
I liked Drupal over Joomla. You should also look into DotNetNuke, out of the box it has lot of things that will meet your needs.
Checkout django-blocks. Has multi-language Menu, Flatpages and even has a simple Shopping Cart!!