django.forms is very nice, and does almost exactly what I want to do on my current project, but unfortunately, Google App Engine makes most of the rest of Django unusable, and so packing it along with the app seems kind of silly.
I've also discovered FormAlchemy, which is an SQLAlchemy analog to Django forms, and I intend to explore that fully, but it's relationship with SQLAlchemy suggests that it may also give me some trouble.
Is there any HTML Forms processing library for python that I haven't considered?
I've grown to love WTForms, it's simple, straightforward, and very flexible. It's part of my django-free web stack.
It's completely standalone, and carries over the good parts of django's form libraries, while imho having some things much better.
I'm not sure what you mean by "making most of the rest of Django unusable" and especially by "packing it along with the app". Are you familiar with the docs? If you just do as they suggest, i.e.
import os
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
from google.appengine.dist import use_library
use_library('django', '1.1')
don't django.forms and the rest of Django work for you (once you upload your app to Google)?
As the docs also explain,
Django versions 1.0 are later are not
included in the SDK. To test your app
with a newer version of Django on your
computer, you must download and
install Django from the Django
website.
but
You do not need to add the newer
Django library to your application
directory.
i.e. you don't have to "pack it along"; it's already made available on Google's servers by Google to your app engine application. (A few third-party apps that depend on relational features, admin especially, don't work -- but your own Django app, written using he App Engine data modeling libraries, will be fine!-).
You can also have a look at formencode, it is generic enough so that you may fit it in GAE.
Is there a more specific reason you don't want to use django.forms? I've quite successfully used bits and pieces of django all by themselves without trouble in several projects.
As an aside, there are several patches that make django sortof work in app-engine, though I assume you've considered and discarded them.
Related
In a school project, my team and I have to create a shopping website with a very specific server-side architecture. We agreed to use python and turned ourselves towards Django since it seemed to offer more functionalities than other possible frameworks. Be aware that none of us ever used Django in the past. We aren't masters at deploying application on the web either (we are all learning).
Here's my problem: two weeks in the project, our teacher told us that we were not allowed to use any ORM. To me, this meant bye bye to Django models and that we have to create everything on our own.
Here are my questions: as we already have created all our python classes, is there any way for us to use them alongside our Django app? I have not seen any example online of people using their own python classes within a Django app. If it were possible, where should we instantiate all our objects? Would it be easier to just go with another framework (I am thinking about Flask). Am I just missing important information about how Django works and asking a dumb question?
We have 4 weeks completed and 6 more to go before finishing our project. I often see online "use Flask before using Django" since it is simpler to use. We decided on Django because in the project description, Django was recommended but not Flask.
Thanks for the help.
Without being an absolute Django expert, here is my opinion.
The Django ORM is far from being the only feature this Framework has to offer (URLs routing, test client, user sessions variables, etc.), but surely it is one the main component you want to use while working with Django since it is often directly linked to other core features of Django.
If using the ORM is completely forbidden, a lot of features out of the box won't be available for you. One of the main features I can think about is the admin interface. You won't be able to use it if the ORM is not an option for you.
So, in my opinion, you should go for another Framework like Flask. Mainly because without using the ORM, some of the Django value is gone.
Hope it helps!
I am using MongoDB as my primary(and only till now) database and because of google and the links it provided me i am confused between Django or Pyramid.
I am comfortable with python but never done web development in python(i have done in PHP). Now because i will be using Mongo so i wont use Django ORM will that take away the ease of development people associate with Django?
I am new to Django(just a few hours) so i am not sure what parts of the framework the ORM affects.
Or should i go with the django fork django-norel with django mongodb engine (they are not actively maintained though) or should i use Pyramid because i plan to use jinja2 as my template layer so that makes 2 parts of django useless to me.
After removing these batteries from django does it still remain true that it a framework for people with deadlines?
Advice?
A year or two ago I was also deciding between django and pyramid w/ mongodb to build a high performance web application. I ultimately chose Pyramid :
Pros:
Pyramid is very light weight for a full stack framework. There is a minmal amount of 'magic' going on under the hood. I was able to wrap my head around all the pieces.
It is not as opinionated as Django. You can plug and play whatever templating engines or databases you need relatively easily.
I was impressed by the performance benchmarks between Pyramid over other full stack frameworks.
The Pylons/Pyramid culture of 100% code coverage and "only pay for what you eat" was appealing to my own development style.
Cons:
The community is growing, but still not as mature as Django
There's a lot of documentation, but it's not as robust as some of the Django docs out there
The lack of 'magic' and beginner friendly documentation make for a steeper learning curve.
As for using an ORM with MongoDB; I recommend you try building without one at first. After trying a few mongodb ORMs, I've ended up going back to plain pymongo with Colander or Validictory for validation. Pymongo is already very ORM-like, fast, and flexible. I felt the extra layers of abstraction took away from that flexibility, and caused me to write more code than was needed.
I'm going to suggest an alternative that has not been mentioned: Flask. Flask has a really great (albeit smaller than Django) community and there are a lot of extensions available for common web-app extensions, in the extensions directory.
There are several MongoDB extensions for Flask, which help to integrate MongoDB into the framework, but I would also highly recommend the mongoengine ORM. One of the people working on mongoengine has release an extension for Flask integration, Flask-MongoEngine.
Try it all (Django, Pyramid, Flask), read the docs, and you done.
If you will select Django, you will not use some parts of it (orm, formlib), and that is all.
ALso see this video:
https://www.10gen.com/presentations/mongosf-2011/mongodb-with-python-pylons-pyramid
I am impressed with django.Am am currenty a java developer.I want to make some cool websites for myself but i want to host it in some third pary environmet.
Now the question is can i host the django application on appengine?If yes , how??
Are there any site built using django which are already hosted on appengine?
Django-nonrel is the best and "official" way to run django on appengine. You can run django apps unmodified on AppEngine (as long as there are no complex joins or ManyToMany relationships)
You also now have access to the full django admin which really is the best part of django.
http://code.google.com/appengine/articles/django.html
http://www.allbuttonspressed.com/projects/django-nonrel
http://code.google.com/appengine/articles/django.html
http://www.42topics.com/dumps/django/docs.html
http://thomas.broxrost.com/2008/04/08/django-on-google-app-engine/
Yes, its quite possible. The only difference is, instead of using django's models and database api you simply need to use appengine's datastore api and models. Look at the above links for reference
Appengine comes with built in Django, if you look under your (google_appengine/lib/django_1_3) lib dir you will see a few versions. You can define what version you want to be used in your app.yaml
It isn't a full release of Django and if you do want to have full admin functionality of Django you might have to use something like nonrel but personally I would say its not necessary and you stand to gain more by getting to understand the underlying nosql structure of appengine, in particular the NDB model is very useful
I'm developing a web application and considering Django, Google App Engine, and several other options. I wondered what kind of "penalty" I will incur if I develop a complete Django application assuming it runs on a dedicated server, and then later want to migrate it to Google App Engine.
I have a basic understanding of Google's data store, so please assume I will choose a column based database for my "stand-alone" Django application rather than a relational database, so that the schema could remain mostly the same and will not be a major factor.
Also, please assume my application does not maintain a huge amount of data, so that migration of tens of gigabytes is not required. I'm mainly interested in the effects on the code and software architecture.
Thanks
Most (all?) of Django is available in GAE, so your main task is to avoid basing your designs around a reliance on anything from Django or the Python standard libraries which is not available on GAE.
You've identified the glaring difference, which is the database, so I'll assume you're on top of that. Another difference is the tie-in to Google Accounts and hence that if you want, you can do a fair amount of access control through the app.yaml file rather than in code. You don't have to use any of that, though, so if you don't envisage switching to Google Accounts when you switch to GAE, no problem.
I think the differences in the standard libraries can mostly be deduced from the fact that GAE has no I/O and no C-accelerated libraries unless explicitly stated, and my experience so far is that things I've expected to be there, have been there. I don't know Django and haven't used it on GAE (apart from templates), so I can't comment on that.
Personally I probably wouldn't target LAMP (where P = Django) with the intention of migrating to GAE later. I'd develop for both together, and try to ensure if possible that the differences are kept to the very top (configuration) and the very bottom (data model). The GAE version doesn't necessarily have to be perfect, as long as you know how to make it perfect should you need it.
It's not guaranteed that this is faster than writing and then porting, but my guess is it normally will be. The easiest way to spot any differences is to run the code, rather than relying on not missing anything in the GAE docs, so you'll likely save some mistakes that need to be unpicked. The Python SDK is a fairly good approximation to the real App Engine, so all or most of your tests can be run locally most of the time.
Of course if you eventually decide not to port then you've done unnecessary work, so you have to think about the probability of that happening, and whether you'd consider the GAE development to be a waste of your time if it's not needed.
Basically, you will change the data model base class and some APIs if you use them (PIL, urllib2, etc).
If your goal is app-engine, I would use the app engine helper http://code.google.com/appengine/articles/appengine_helper_for_django.html. It can run it on your server with a file based DB and then push it to app-engine with no changes.
It sounds like you have awareness of the major limitation in building/migrating your app -- that AppEngine doesn't support Django's ORM.
Keep in mind that this doesn't just affect the code you write yourself -- it also limits your ability to use a lot of existing Django code. That includes other applications (such as the built-in admin and auth apps) and ORM-based features such as generic views.
There are a few things that you can't do on the App Engine that you can do on your own server like uploading of files. On the App Engine you kinda have to upload it and store the datastore which can cause a few problems.
Other than that it should be fine from the Presentation part. There are a number of other little things that are better on your own dedicated server but I think eventually a lot of those things will be in the App Engine
Is there a well maintained package available in Python for creating and validating HTML forms? I will deploying it finally on Google Appengine.
You can use Django form validation on GAE storage via db.djangoforms.ModelForm.
To smoothly integrate client-side Dojo functionality with Django server-side web apps, I'd look at dojango, which does work fine with GAE (as well as without). However, dojango (currently at release 0.3.1) does not yet automatically provide client-side validation of Django forms -- that's on the roadmap for the forthcoming release 0.4 of dojango, but I have no idea about the timeframe in which you could expect it.
For client-side validation, check http://plugins.jquery.com/search/node/form+validate;
for server-side, actually ALMOST every web framework (web.py, django, etc.) has its own form generation as well as validation lib for you to use.
AppEngine includes Django's form framework (or a variation thereof), which I find very nice. It also plays well with your ORM (i.e. getting forms for models is very DRY). The only potential problem is the lack of client-side validation.