Django simple-pages stable or not? - django

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.

Related

Django, REST, and Web Development

I'm new to web development, but have recently been getting going with it pretty fast, using Django (which I'm falling in love with). However, while Django is easy to get going with and pick up quite fast, I'm afraid there are concepts I don't know much about, particularly REST and RESTful web services. I hear those terms thrown around a lot, and I'm assuming are important to modern web apps, and I want to know basically what they mean, when I should use them, and how I should use them (package, plugin, etc.).
My web app consists of the following functionality:
Discussion Board which I've implemented so far only using the model layer
Messaging which I've implemented so far only using the model layer
Payments (not yet implemented)
Calendar (not yet implemented)
And that's about it for now. When should I be thinking about REST within these functionalities?
You could get really in depth with the subject, but when I think of it, I think of the URLs your site will be providing. That, for me at least, is the simple way to think of a RESTful service. I also think it's a good way to get to grips with Django & it's generic views.
Taken your example there of a calendar. A RESTful approach to a calendar app, with django's generic views, might implement URLs like;
# ListView
/calendar
# DetailView for a given item in the calendar
/calendar/<id>
# UpdateView for an item
/calendar/<id>/update
# DeleteView for an item
/calendar/<id>/delete
Beyond that, REST requires you consider the HTTP methods in use, so you should then define what methods your URLs will accept in order to better control the interaction. Furthermore, if you were enforcing the HTTP method on each action, you could write a more generic view which didn't expose the /update or /delete URLs. But I'd consider that a more advanced approach & you may wish to start from a more explicit design.
Once you start to write a consistent structure for your apps then you can easily make generic functions, and expand.
There is a whole load of things you could read on this subject, depending on where you see it going.
If you're thinking of building something that can provide an API then there's already a Django framework for this; http://www.django-rest-framework.org/
But if you're getting started & just want to know more about the concepts, Wikipedia is always a good place to look, and finally this looks like a great example for this subject using Django which should hopefully help you on your way.
To understand the idea of a resource, take a look at this answer

Use django-contrib-comments (the app) in new Django projects?

From the documentation: "Django’s comment framework has been deprecated and is no longer supported. Most users will be better served with a custom solution, or a hosted product like Disqus. The code formerly known as django.contrib.comments is still available in an external repository."
Is the move to django-contrib-comments only a fallback for existing projects that use django.contrib.comments? Should I use django-contrib-comments in new projects and why (not)?
I have been developing comments for our site using django.contrib.comments and found it to be quite a simple module and nothing else. If you are building a "just" commenting app to engage people, disqus might be a nice option. For instance, if you are building something like what stackoverflow is doing, you need to do by yourself.
For that, you can pretty well use django.contrib.comments and built your rest of the code on the top of it. I have been doing this and the following are points I would like to note
Very good chance that you are going to write all Views again for Ajax support or any other custom support
The app does not authenticate users. So, you might need to tweak this too
Add some special fields in comments, remove some provided
You might want to provide users to delete comments.. The built-in delete is just a flag where its marked "deleted" but not deleted exactly..
Regarding administration of commments, there might be lot you are going to improve.
It goes on, when you start doing it, you continue to tweak almost everything and make fit for your site. Probably if your tweaks seems to look too huge, I guess, start from scratch or take only parts of that django.contrib.comments where ever needed..
The Google Groups Django developers has the proposal:
"... if you don't really care much about how comments work but just want something easy, then Disqus (and its competitors) are easier to use and have much better features (spam prevents, moderation, etc.). If you want something complex and specific, on the other hand, you're better off writing something from scratch."
And the django-contrib-comments (the new home) is intended as a boneyard.

CMS+blog+e-commerce: django or web2py [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
At the moment we are running few smaller PHP sites (small company, private, non-profit org, friends...) and would like to migrate them to Python in order to be able to tweak them more easily and/or extend their functionality due to being familiar with Python although without real experience using some of the Python frameworks.
In order not to write everything from the scratch, we'd need decent CMS, blog and some e-commerce module.
We did some research, installed and tried few apps in Django world and so far have arrived to the two possibilities:
Django-CMS as CMS, Zinnia as blog engine and Django shop as e-commerce or
Mezzanine which integrates CMS+blog and Cartridge as shopping cart application.
Both combinations are nice, although not perfect...At the moment there is problem integrating released versions of django-cms & zinnia due to their usage of non-compatible versions of django-mptt or e.g. Mezzanine is missing some features like linkback support in blog etc.
While playing with the above two sets of apps, we heard about Web2py and must say that we like lot of things there...
We are aware it's younger project with smaller community, less apps etc., but wonder if there is some set of web2py applications which can compare with the two above-mentioned Django sets so that we can choose to start with Web2py, learn it and in that process replace PHP sites with it?
So, we would like to have some capable CMS+blog with the following features:
tag cloud, categories
spam protection
RSS feeds
multiple authors
threaded comments (optional)
linkback (pingback/trackback) support
(easily) theme-able
markdown/reST markup for writing content/posting
multi-lingual support
As far as e-commerce is concerned, besides easy integration with CMS+blog apps we do not need anything spectacular - our 'company' is selling 'services', so no need for thousands of products (only 10s of them), no complicated shipping options so something like:
multi-lingual support
basic infrastructure for payment methods (e.g.) PayPal and we would need to write a custom module for form-based API
simple shopping cart able to handle simple product descriptions
tax calculations and
(optional) PDF support
would be everything what we would need.
Considering the features we would like to have, our (non)experience working with any framework, which one - Django or Web2py - you consider is more suitable in terms of ease of learning, ease of use, application support etc. ?
I've sent two posts to web2py list and (maybe) because my query was not specific-enough (or some other reason) I did not receive any reply there and I saw there are some apps like KPAX CMS which looks old/non-maintained. Otoh, there is Powerpack which incorporates Instant Press but I'm not sure about availability of e-commerce component. Finally, I've found out about plugin_wiki which seems to be new/young app, but, considering we found* out about possibilities in Django-world, we would like to learn about the situation on the Web2py scene in order to be able to evaluate both options better.
p.s. it would be nice if Appliances list would be organized a bit better so that it's easy to find out what is maintained, where is project page etc.
I've had a lot of success with Django-CMS. It's very, very easy to write custom content-type plugins, extend menu nodes with custom nav elements, such as a list of product categories, etc. It's dead-simple to hook custom application code to any page in the navigation hierarchy.
As you mentioned in your question, Zinnia also plugs into Django-CMS for a nice blogging solution that is also extensible. Adding a cart app, whether it's from the DIVIO team or not should be an easy task.
Django, DjangoCMS and Python in general, have very low learning curves in my opinion. In 14 years of development, Django is the only web framework that hasn't gotten in my way, and Python is an absolute pleasure to work with on a daily basis.
I think you'll find that the Django ecosystem is much more holistic than any of the other Python frameworks, it's also very, very well documented and there are literally hundreds of 3rd party apps. Plus, Django admin can potentially save you many weeks of dev time, and you can override, skin and extend it to do just about anything.
My $0.02 :)
-- EDIT --+
Yeah, right after I posted I realized I was heavy on comparison of frameworks but light on suggested solutions to your problem (i.e. existing appliances). I think that Django probably has more matured addins/apps. That being said, crafting your own blog in web2py (a simple blog) is probably only a little harder than configuring one for another framework.
There is the wordpressclone appliance: http://web2py.com/appliances/default/show/36
(you can extract existing wordpress data and get it in here, i'm pretty sure there's a WP export and an import function on this appliance)
There is an e-store (haven't used it): http://web2py.com/appliances/default/show/24
There is KPax CMS, as you said, but i think this one might be out of date, unless it was updated recently. The integration between these should be possible, you can share sessions across apps and I think if you have the same auth_user db, it should work.
I would try installing these and see if they are close to meeting your needs -- especially KPax since I'm not sure the state it's in.
-- END EDIT --
Both Django and Web2py are very good frameworks in my opinion. I think you would be happy with either. That being said, having not used frameworks I would say to with web2py, unless you NEED certain modules that only exist in the django world. Web2py probably has a little more gradual learning curve. Also, it can do RSS out of the box, there's a screencast somewhere showing how to create a blog app in about 5 minutes (including comments), and the community is (usually) very responsive. I don't think there is anything that web2py can do that django can't (except DB migrations -- but i think you can make django do them with some 3rd party code), or vice versa.
Django favors a "explicit is better than implicit" development methodology, which requires to you import various modules and doesn't have all the "magic" of web2py. Using django, you will be more aware of exactly what is going on under the hood. The django templating language is easy to learn and provides a lot of functionality for common markup tasks. Their is a LOT of documentation, a larger user-base and tons of 3rd party modules/plugins/whatever.
Web2py favors a "everything should have a default" approach, and enables to to focus on the big picture without getting bogged down by the minutia of web development. I'm not saying this is in contrast to django, but rather that web2py is very strong on this point. It allows you to rapidly develop applications, and takes the headache out of things like updating a table schema (i.e. it does database migrations). I also prefer web2py's templating language to django's, as it allows pure python and does not require one to learn a separate templating language at all.
I think both frameworks have decent internationalization/localization features. I'm not sure if Django's is still under development or not? Web2py's is easy to use, but I think you might have to provide a lot of the translations yourself.
As for the lack of replies on the web2py list, maybe it's because this topic is becoming more and more frequent? I'm not sure. You could ask people on the web2py freenode channel.
Also, definitely check out this link:
Django vs web2py for a beginner developer
The first response is from the lead developer of web2py, but I think he makes a fairly balanced comparison.
Also, the previous thread includes a link to here (the good and bad of web2py):
http://www.mengu.net/post/django-vs-web2py
web2py is a great framework, but currently light on reusable CMS, blog, and particularly e-commerce applications. It sounds like you have already stumbled upon the main options -- plugin_wiki, Powerpack, and Instant Press.
I don't think there is a mature and currently maintained e-commerce application, but you may be able to make use of web2py-estore. There are also some options for accepting credit card payments (see also).
plugin_wiki includes comment functionality, and there is also plugin_comments. For PDFs, pyfpdf comes with web2py, and there is also web2py_appreport. web2py also includes RSS support.
EDIT: Also, another web2py CMS under development, to be released soon: SimplrCMS

Django or Zope?

I want to create a website and I am confused which web framework to use. Please recommend me which framework is better: Django or Zope. I am using Python.
If you mean plain Zope2 by zope then I'd go for Django. Most interesting stuff in the Zope world takes place with either Plone or Grok (which is Zope3, which is actually quite different from Zope2).
Grok works nice with relational databases, Plone doesn't really, so if you depend on an RDBMS, either go with Grok or Django.
Zope and Plone have a rather steep learning curve so you'll get started more quickly with Django.
The largest downside about Django is, in my opinion, that it tries do do everything by itself (templating, object publishing, ORM, and so on) while there are many excellent existing components out there. If you want to be able to use your code / knowledge outside of the web framework you're using, consider Pylons or BFG
Many options, no clear answer, sorry :)
I have no idea what sort of website you're trying to create, so it's hard to recommend a specific framework.
I'd recommend getting through some tutorials to see which one you like best (There's also pylons and TurboGears to pick from).
Django seems to be the most popular starting kit these days though.
If your website is very hierarchical and needs fine grained permissions, I'd use Zope. (Don't use Zope if you intend to store your data almost exclusively in an SQL database.)
If you have large datasets that can be put into (sql)tables and need many forms, I'd use Django. (Don't use Django if you need very fine grained access control, and hierarchical data)
You see: both have their weaknesses and strengths (although I am only developing in Django these days. The Zope community seems to be a bit in dispute these days about the way it should develop)
Zope is dead. As is TurboGears, Pylons, BFG, Repoze, CherryPy etc.
Active and popular Python web frameworks include:
* django
* flask
* bottle
Big, medium and small. Take your pick.
Here is a good comparison of Django and Zope (and Rails)
http://cd-docdb.fnal.gov/cgi-bin/RetrieveFile?docid=2715;filename=Comparison.html;version=3
They preferred Django. I, personally, use Django too, so I don't know much about Zope.
Another good thing about Django is that they have very good documentation (though I don't know that of Zope). Many people praise that very much.
Also I found Django quite easy to use, and also they have a ready 'administrator panel', which allows quick web-oriented site management from the first steps. More important for me, however, is its fine integration with python and the simple organisation (in the link above they complained that Zope uses very much of its own features, while Django is closer to pure Python).
If you are starting from scratch I will suggest you should go for Django. You will get lots of features and suppost from django. Easy to debug and best suited for rapid developement. In the other hand, You should only choose Zope, if you have experienced developers familiar with Zope or have existing projects based on Zope and the cost of switching is too high for the potential value gain.
In zope's website it self it is written, It is no longer recommended to start new projects based on it, unless you are intimately familiar with the technology stack.

Django grappelli

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.