I wonder if i can use another templating engine besides django's on django project, to be exact, it's chameleon, and there are any performance issues? Just curious, because i'm more familiar with chameleon
The easier part to replace in Django is the template engine, and it is not famous for the astonishing performance.
I'm pleased with the results from mixing Django and Jinja2, unfortunately I can't comment on chamaleon.
Related
I have been using Django for many years (since Django 1.2). and in the past, I used different type of web frameworks (such as CakePHP, Rails, ASP.NET MVC, and some other full-stack framework). Django wasn't my first framework.
Different frameworks have differences in their approaches and benefits. There are certain part of those framework I like and I don't. In this context, I'd like to look at the design of Django Framework in more specific.
After transition to Django, I like how it design its framework. When learning a new language (such as Go, Scala, Ruby, Haskell), I try to looks for a framework that has some similarity in its design especially those I mentioned later.
The following are the 2 Django framework design decision that is very different:
it encourage pluggable apps or apps reusability.
Hence:
moving away from monolithic design by Jacob Kaplan-Moss
using multiple apps to create a full feature site, without any model or logic
writing a Project-less Django mentioned in Practical Django Projects by James Bennett
it uses Model View Template instead of classical MVC:
mentioned in FAQ.
view describes which data is presented
template describes how the data is presented
a view normally delegates to a template
controller is probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.
I would not believe that Django pioneer such features. I believed this pattern is very common in Framework Design. Just that I have no idea, what is this (design) pattern called? This concept is very useful to be applied in other framework. I believed knowing the name of the pattern could help me understand or even build a new framework on different language with the same concept.
Currently there are tons of web framework, most of them are following the classic MVC pattern. Some use the concept of plugin to add certain capability. Plugin however solve the reusability in different approach depending on the context.
So I did tried to learn as many framework I could in order to find an alternative framework in different languages. Hoping that I could find out the pattern that Django use. However, it is very difficult for me to learn all of them. In fact, I haven't found one so far.
I have been searching for:
Django like framework in 'ruby'
Django like framework in 'Java'
Django like framework in 'Haskell'
Django like framework in 'Go-Lang'
Django like framework in 'Scala'
Unfortunately, none of them really, highlight the concept that I'm interested in.
In this Q&A, I would like to know what do people call such framework? (Or What pattern is Django use?) Would be good if you could give a references in this design which other framework might have been using it too?
Looking at Django design philosophies
I think they use/combine a lot of different design patterns trying to fulfill the philosophies. It's difficult to map to a single concept.
Tip is to look at Software Design Pattern and it should be possible to identify many patterns are used in django. Many patterns are of course common in other frameworks as well.
For example (patterns more or less used):
modelform_factory maps to "Builder"
QuerySet can be mapped to "Lazy initialization"
The ORM/database mapped to "Adapter"
What is it about django that you cannot do in other languages?
is it the access to the database, or the models? - no, python also has SQLAlchemy; ruby has Active Record...
is it the views, or web framework? - no, you can provide views with Flask, Pyramid, rails, php ...
it is the templating system? - no, you also have Jinja; mustache, Liquid...
is it the admin contrib packages? - no, you have phpmyadmin, workbench ...
is it a set of libraries to make your development easy? a toolkit?
django has great tooling, many packages you can use; it is a platform, meaning it has enough of a core to be the starting point of many projects, and enough community behind it to have many packages to make integration into a turn-key solution a breeze.
django uses the DRY (Don't Repeat Yourself) principle as a design philosophy. From the point of reusability, keeping clear responsibilities for each piece / app makes it easy to reuse components. But that doesn't take a well-designed platform; the emphasis should be on the components that are written in a way to be reused. E.g. generic tagging, configuration / data-driven components...
Django is MVC.
MVC is a pattern not a strict rule frameworks have to apply. The pattern tries to give a commonly accepted solution to a frequent problem. The problem is "How to properly organize a web framework" and the solution is "by separating data, logic and UI" in meaningful modules.
Therefore Django is MVC. Django logically separates those concepts (and many others) in modules. That's what matters IMO. Django view is not the same as MVC view, but... poteto potato...
About app reusability:
Django is The web framework for perfectionists(...) and perfectionists (or simply good developers) write reusable code. This is expressed by Django DRY philosophy and materializes in Django apps.
I'm pretty sure you can design app-like components with other web frameworks. Of course, since apps are in Django's nature since many years, it has much better support!
I'm trying to find any information if official django is going to support any noSQL DBMS, especially MongoDB. I found a fork of django 1.3 the django-nonrel (a fork of official django) and some other not very reliable projects (failures occur often, according to comments I found on the web). Is django going to support noSQL officially at all?
Perhaps, there are other ways to achieve your goals, besides going noSQL.
In short, if you just need dynamic fields, you have other options. I have an extensive writeup about them in another answer:
Entity–attribute–value model (Django-eav)
PostgreSQL hstore (Django-hstore)
Dynamic models based on migrations (Django-mutant)
Yes, that's not exactly what you've asked for, but that's all that we've currently got.
As you said, forked code is never the best alternative: changes take longer to get into the fork, it might break things... And even with django-nonrel, is not really Django as you loose things like model inheritance, M2M... basically anything that will need to do a JOIN query behind the scenes.
Is Django going to support NoSQL? As far as I know, there's no plans on the roadmap for doing so in the short run. According to Russell Keith-Magee on his talk on PyCon Russia 2013, "NoSQL" is on the roadmap but in the long term, as well as SQLAlchemy. So if you wanna wait, is going to take a long time, I'm afraid.
Anyway, even if it's not ideal, you still can use Django but use something else as a ORM. Nothing stops you from use vanilla Django and something like MongoDB instead of Django ORM.
What is a good django open source app that I can learn from? Something that follows best practices, and covers the majority of features and isn't overly complicated?
This would depend on your current level of knowledge of python and django.
If you are just starting to use django, I suggest you take a look in django documentation. It is well specified and clear. If you have some project in mind, start working on it while looking up for best practices about specific parts. For python coding style try to follow the pep 8 style guide.
If you already have done some work with django there are many sites lie these:
http://djangopackages.com/categories/apps/
http://www.django-apps.com/
What I do nowdays is look into django contrib apps (admin, auth, comments, flatpages), which are built based on the rest of django. This gives the best ways on how to write my apps.
Following the django comments framework (object independent), I am working on an app django-valuate (object independent attachment of ratings, likebuttons etc. through template tags)
These are some of my views. I have also starred this question, as I would like to know about some different perspectives and if mine are sound.
I've found djangobb (www.djangobb.org) to be a complete application, production quality and relatively simple. I use it as a base for my application which has nothing to do with forums and bb.
cloc output: only 3000 lines of python code in 30 files, another 2900 lines of templates html
I do not think there would be any one specific app that would cover all/most features of Django since the concept of the Django app itself is to perform specific/related functionality.
Having said that, a popular Django app is django-registration. Its popularity stems from the obvious requirement of most webapps to have User authentication and also its extremely easy to integrate with a Django project.
The best approach perhaps would be to keep trying the tons of open source Django apps available on the net. You can browse through http://www.djangopackages.com/ and http://www.django-apps.com/ to start getting your hands dirty.
snipt.net, a code sharing site:
https://github.com/lionburger/snipt
Review Board, a code review web app
https://github.com/reviewboard/reviewboard/tree/master/reviewboard
rietveld, another code review on app engine, by GVR himself. You need to know a bit of Django before digging into this source code since the Django models don't work on App Engine, GAE db model is used instead.
http://code.google.com/p/rietveld/source/browse/#svn%2Ftrunk
I had this idea of creating desktop apps using django. The principe being:
- Write the django app, and use something like cherrypy to serve it.
- Write a Qt app in C++ to access it and this by using QtWebview (webkit)
I'd like to "bundle" this in a single app. The lighter, the better :)
So here are my questions and if you have better ideas and suggestions, please
share them :)
Is it possible to serve a django app with a c++ one? (a c++ server embedding python)?
anyone did this before? Do you have some articles, blog posts?
Thanks a lot!
Django has it's own server. Why involve CherryPy?
You're creating a hellaciously complex architecture for no recognizable purpose. Your comments are almost impossible to parse in the context of your question. Please consider rewriting the question to address your actual concerns with an actual thing you actually wrote.
"I ... used pywxiwdgets in the past and it was SLOW"
There are many of desktop frameworks. Use another one.
Don't introduce Django -- it's for web applications, not desktop applications. The overhead of messing with Django and CherryPy is silly.
Find the original reason for SLOW. I'll bet it was database slowness from using SQLite. If not that, I'll bet it was a poor data model. If not that I'll be it was poor use of the pywxwidgets. If not that, I'll bet your desktop app made internet connections that were slow. Indeed, I'd bet that almost any part of your app was the culprit and making a super-complex architecture will not make things faster, just more complex.
Until you identify -- and measure -- the original cause for slowness, you're not actually solving the actual problem you actually had.
Look at http://www.python-camelot.com/
It says "A python GUI framework on top of Sqlalchemy and PyQt, inspired by the Django admin interface."
Pyjamas Desktop can probably be integrated with Django. And there's no need for C++. It currently uses pywebkitgtk, but I don't think there's any real reason why it couldn't use PyQt4 instead with a bit of work.
Use PyQt or PySide instead of C++.
you can use electron-api-demos this opensource
and Now this technology is considered the bright generation, so one of the most famous people who used it is YouTube and Visual Studio Code
https://github.com/electron/electron-api-demos
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