I have this app built with flask and now i'm trying to run it on my phone with phonegap.
Although the way i have it organized originally with flask is something like this:
/project
run-dev.py
config.py
/phonegapfolder
/app
user.py
forms.py
views.py
__init__.py
/templates
index.html
My problem comes from the fact that phonegap demands its main html to be the one in
/phonegapfolder/www/index.html
Of course it's useless to just copy my index.html from one folder from another, because we will not find the python files that lie within the app folder.
You best solution would be to use flask on a backend (remote) server and have the PhoneGap application make server requests to the flask server.
PhoneGap projects require that the index.html be set within the application (www) folder.
This post on Reddit might be able to clarify some of the details.
I've tried to find a concrete answer for this but failed. I'm rather new to openshift, django and git so I hope it's not too trivial and not a duplicate.
The situation is as follows:
1. I'm developing a Django based web application and source control it using git on a private bitbucket repo. I have my regular django application source tree as needed.
2. I wish to deploy my app on openshift which comes with a different directory tree. I've been able to successfully run this quickstart:
git://github.com/rancavil/django-openshift-quickstart.git
Basically what I try to achieve is a wrapper directory (and git project) which is based on the repo specified in #2. Within this wrapper one of the subdirectories (wsgi/my_project) should be based on my private repo specified in #1.
I wish to be able to pull recent changes from the private repo and then push and deploy to openshift these changes.
Any help would be greatly appreciated!
I was also struggling with openshift structure. But there is no need for doing the staff like you have proposed.
You can have any structure of a project you want. Openshift will need just wsgi/application or wsgi.py as an entry point. I think that having one more file in your project is hardly a problem.
My current structure for a project (got it running recently) is following:
|- .openshift (directory for build and deployment hooks like syncdb or collectstatic commands)
|- custom_project (directory that is you django project)
\- templates
|- settings.py
|- urls.py
|- manage.py
|- requirements.txt
|- wsgi.py
There is really no need to have project under wsgi folder. However there are few more pitfalls to be aware of. Like creating static folder or setting .htaccess for static files.
Including my wsgi.py:
#!/usr/bin/python
import os
import logging
try:
virtenv = os.environ['OPENSHIFT_PYTHON_DIR'] + '/virtenv/'
virtualenv = os.path.join(virtenv, 'bin/activate_this.py')
execfile(virtualenv, dict(__file__=virtualenv))
except (IOError, KeyError):
pass
os.environ.setdefault("DJANGO_SETTINGS_MODULE", 'custom_project.settings')
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
I have used a lot of resources to make my project running on openshift so I'm also including them for other.
bitbucket and openshit repos: Can I use my existing git repo with openshift?
Slides with necesary steps: http://appsembler.com/blog/paas-bakeoff-comparing-stackato-openshift-dotcloud-and-heroku-for-django-hosting-and-deployment/
And the most important one, the really well written step-by-step tutorial: http://www.paascheatsheet.com/#Introduction
I know how to add custom commands for django projects. But when I use tastypie, the way to add custom commands just doesn't work. My currently file layout looks like below:
api/
__init__.py
manage.py
api/
models/
resources/
management/
__init__.py
commands/
__init__.py
createapikey.py
I don't know where should I put the management directory. In fact, I have already tried to put the whole management directory in up-level directory and inside the api/api/ folder. Neither way works.
I found the solution by following this link, since my project has no app in it, there is no way to put the management directory. So the solution is just create a core app and put the management directory into that core app. Problem solved : )
I'm trying to set up Pinax and I'm new to everything involved (Django, Pinax, webservers, etc). I'm following http://pinax.readthedocs.org/en/latest/gettingstarted.html
When I generate a project using:
(mysite-env)$ pinax-admin setup_project -b basic mysite
The directory structure I get is:
apps __init__.py manage.py settings.pyc urls.py
dev.db __init__.pyc requirements static urls.pyc
fixtures locale settings.py templates wsgi.py
Which as far as I can tell is missing the deployment folder (when you compare to the directory structure shown here : http://pinax.readthedocs.org/en/latest/starterprojects.html). It doesn't seem to be effecting anything yet, but it makes me nervous. What is going on and is the fact I'm missing the deployment folder going to cause problems in the future?
I'm running Ubuntu and using python 2.7. I had the same behaviour with Windows 7, python 2.6
Thanks!
The new Django versions have made the old pinax pretty much useless. Now Django supports project templates and Pinax is separated into several smaller projects regarding starter projects (such as pinax-project-account) and apps (such as django-user-account).
The current way to use pinax is to choose a starter project, and then running something like:
$ django-admin.py startproject --template=https://github.com/pinax/pinax-project-account/zipball/master <project_name>
and then install requirements:
$ pip install -r requirements.txt
This will create a new Django project using the starter-project as a template, which already includes a few apps (like django-user-account) and templates (with bootstrap!). The project is ready to run, and already includes a bunch of functionality (like user registration, login and management).
Also, Django has changed the project directory structure a bit, so now it doesn't really look like that anymore.
I am new to Django and starting a project, and I would like to do it the right way.
I would like to know what you think is best practice for organizing a project.
Here are some questions I have:
How do I separate the static resources from the Python code so that I don't waste time processing the static content through Django?
As apps are reusable modules, they are not really tight to a project, so should they be located in the project directory, or in another directory that would contain all my "homemade" apps?
Are templates considered to be static or dynamic content?
Here is my current file hierarchy:
webapps/
myproject/
apache/
bin/
lib/
templates/
app1/
app2/
src/
app1/
app2/
__init.py
settings.py
urls.py
manage.py
myproject.wsgi
admin/
static/
css/
img/
What do you think?
What would be better?
Thanks!
Your directory structure could also depend on what version of django that you're using. If you're using django 1.3, handling static content has changed slightly. Your templates could also be arranged separately.
The following only applies for django 1.3.
Within an app directory:
...
app1/
static/
app1/
templates/
app1/
models.py
...
views.py
If you use the new django.contrib.staticfiles application, your settings may look something like this:
MEDIA_ROOT = path.join(ROOT_PATH,'uploaded_media/')
MEDIA_URL = '/uploaded_media/'
# static content is collected here, and served from here, but don't add stuff manually here! add to staticfiles_dirs
STATIC_ROOT = path.join(ROOT_PATH, 'collected_static/')
ADMIN_MEDIA_PREFIX = '/static/admin/'
STATIC_URL = '/static/'
# Additional locations of static files
STATICFILES_DIRS = (
path.join(ROOT_PATH, 'src/extra_static/'),
)
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
)
Similarly, your templates can be loaded directly from an INSTALLED_APP:
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader'
)
TEMPLATE_DIRS = (
path.join(ROOT_PATH,'src/templates/'),
)
The two strategies above mean that templates and static content can live within their specific app directories. In Development, using contrib.staticfiles, static content can be served directly from your application folders. In production, there is a management command to collect all the app directory static content to /path/to/project/collected_static/, and you can point your web server at that directory to serve static content.
For pre-packaged libraries, using virtualenv and pip is a great idea. Otherwise, I like to keep libraries in a lib directory within the project root directory. It makes referencing the source, templates, and static content extremely convenient, rather than installing to site-packages (especially when not using virtualenv).
So, re-arranging your project structure:
webapps/
myproject/
apache/
bin/
lib/
collected_static/
uploaded_media/
myproject.wsgi
src/
templates/ # lib template overrides and site wide templates
base.html
lib_1/
nav.html
extra_static/
lib_1/ # libs that dont support django 1.3 static
js/
css/
settings.py
settingslocal.py # keep developer specific settings here
urls.py
manage.py
app1/
__init.py
static/
app1/
js/
css/
templates/
app1/
My designer doesn't want to go hunting everywhere (all over the python path) for template files. My template layout follows yours in that there is one template folder and all the apps go below that. Each app has its own base.html that extends basebase.html.
Here lately I've started following the pinax model of an apps folder, and all apps go in there. The reason for this is purely aesthetic since Wing shows me a tree, all my apps are clustered together in that part of the tree. What I didn't like was an app that sorted out alphabetically after templates or media or site_media. Scrolling up and down the tree slowed me down. By putting all the apps into one place in the tree, git commit -m "feature notes" apps checkins in the code changes too which is another plus.
webapps/
myvirtenv/
bin/
lib/
myproject/ <- Source control starts here
site_media/
collected_static/
js/
css/
img/
uploaded_media/
deploy/
myproject.wsgi
procmail scripts
apache site files # linked from /etc/apache2/sites-endabled
apps/
app1/
templates/ <- This should be here, but in practice I just leave in templates below
app1/
app2/
templates/ # lib template overrides and site wide templates
basebase.html <- I changed the name to help my designer
app1/
app2/
settings.py
gethostname()_local_settings.py # keep machine specific settings here
urls.py
manage.py
requirements
base.txt
project.txt
There were too many base.html files and talking about it was difficult, so basebase.html was born and we've been happy with that ever since.
I haven't had any static files that didn't work with the staticfiles app. I was using that app with 1.2. I haven't gone back and done the 1.3 static folders yet but I probably will in the next few months as things get worked on.
I got the requirements folder trick from pinax.
Create VirtualENV
git clone url
pip install -r requirements\base.txt -r requirements\project.txt
manage syncdb (if using sqlite, otherwise you have to do db creation tasks first)
symlink from /etc/apache2
reload apache config
Profit!
You've had some good thoughts here. My first reaction is to ask what that admin directory is doing? The admin is part of Django, and doesn't need a separate module - and the app-specific admin.py files need to live within their respective apps.
To answer your questions:
separating static and dynamic: this is done at the level of your web server configuration. In your case, your apache virtualhost conf needs to have an entry for the webapps/static directory, but not for anything else. The documentation has a good example.
If the apps really are completely decoupled from your project, then yes they could live outside it, as long as you put them onto the Pythonpath. One good way is to keep them in separate code repositories, and install them into your project with pip and virtualenv. However, I think you'll find that many of your apps will be project-specific, so live within your project directory.
Templates are very definitely dynamic content. If you serve them directly with Apache, they won't be parsed, so your users will see the code for the variable and block codes rather than the values.