I'm want to try remaking my the software I build at work which is a java/jython/python 2.5 personal hellscape of my everyday existence to a single page app (if possible) using Flask.
I'm pretty familiar with flask in terms of routing, posting forms to databases and reading from databases to template a page. But so far every time I've made a blueprint it seems to have been mostly done for separation of concern concerns, I've never reused a blueprint with a different suffix, but now I think it might appropriate for this context.
I have multiple business entities that all just have to follow a CRUD cycle. Invoices, sales orders, quotes, etc. Each of these should have exactly four routes
<entity name>/create would have a GET to return the appropriate HTML web page, and a POST that would send the form fields to the appropriate columns of the appropriate database table.
<entity name>/read/<id> would only have a GET to return the HTML page with the entity form already filled out with info from the database.
<entity name>/update/<id> would only have a POST, to update the page served in the read route if the action is take.
<entity name>/delete/<id> would only have a POST route.
With these 4 routes being the only ones required for every entity, would it be 1) recommended to use one general blue print for all these entities? If so, 2) how would I set up database table names/the folder structure to best utilize the generic blueprint?
It's worth noting too that some of the entities need not only to update the database table that shares their name, but also some multi-key tables, while others do not. I know this is somewhat a generic question so I tried adding detail, I can add further detail where requested.
Best way to set up for Blueprints:
Put all python files for routes, forms, background utils, and a templates folder for applicable html templates into separate folders for each of the CRUD sections you mention above.
For each folder (e.g. 'folder_name'), its init.py contains:
from flask import Blueprint
from flask_breadcrumbs import default_breadcrumb_root
bp = Blueprint('folder_name', __name__, template_folder='templates')
default_breadcrumb_root(bp, '.')
from app.folder_name import routes
The various routes.py should contain routings such as:
#bp.route('/read', methods=['GET'], strict_slashes=False)
#register_breadcrumb(bp, '.this.that', 'My Breadcrumb')
One folder up at 'app', the create_app function in 'init.py' should contain:
from app.folder_name import bp as one_bp
app.register_blueprint(one_bp, url_prefix='/<entity_name>')
# etc, for each app/<folder>
I've included Breadcrumbs into this app structure. Menu can be similarly included.
Related
I am currently working on designing a web application to be used by researchers to conduct reviews. In this application there are two groups of users - participants and administrators.
Only administrators can start a review and can assign any user or administrator to participate in the review as an admin or a screener. The general workflow for each review will be:
Search medical databases and import thousands of references.
Screen references based on title (number of reviewers/admins Screening can be 1 or multiple). Each reviewer will screen all references. Mark each reference as included or excluded.
Screen included references based on abstract. Same as above applies.
Source full-text as PDF and store for included references.
Screen included references based on full text. Same as above applies.
Create custom forms.
Extract data from included references.
Export data
Throughout the progress of the review machine learning on all of the references will be done. We will also require comprehensive logging throughout the review.
My question is this, how can I best split these sections into django apps and how should I structure the required databases.
Provisionally, I've thought about having these databases:
Users. Stores info on screeners and reviewers and which projects a tenner and admin in.
Project. Stores basic info on each project including data extraction form. One to many relationship with references table.
References. Stores info about each reference including inclusion status and data extraction.
I don't know how to deal with the logging. How can I do this?
Is this a sensible split and if so how should I accordingly split the steps into apps.
The best thing about Django is apps that you create with manage.py startapp <myapp> . Apps gives good control of modularising the code. You are on the right track in modularising the code.
Regarding your tables users, projects and references sounds reasonable from your explanation.
If I were you, I would structure apps into something like this.
apps/
userprofile/ (users table )
project/ (projects and references tables)
activity/ (activity and notifications tables)
Regarding logging
Each activity like user edits , project edits or deletes can be captured via a post_ or pre_ signals https://docs.djangoproject.com/en/1.10/topics/signals/. User them to create an activity and based on the activity you can publish the single activity to multiple users as notifications ie., a single activity will trigger each notification to multiple users who are participants in the event.
In each app
I prefer to use following structure inside each app :
userprofile/
__init__
views.py
tests.py
signals.py # write the post_save pre_save post_delete pre_delete logics here
managers.py # take full leverage of managers, and custom querysets
forms.py
models.py
urls.py
admin.py
tasks.py # for celery or tasks which will be used by queuing systems
apps.py
Regarding version the data
Try the one which suites your requirement from here https://djangopackages.org/grids/g/model-audit/
I want some clarity. I want to learn more about django and use it as replacement for php/laravel. But the default structure and convention of django confuses me a bit.
My PHP/Laravel project has 3 parts:
- Administration
- Core (Web app for regular users)
- API Service (REST-API for mobile apps)
However all of controllers, models and views are contained in a single Laravel application. I separated Auth, Admin, Api controllers into their own folders/namespaces.
One thing that confuses me is the default Django structure 1 view 1 model file. How should i go about reworking this application in Django should each of my controllers be a separate app in my django project or should I have same approach as in Laravel. 3 Django apps in one project one for admin one for core and one for api ? Where should I keep my models than since in Laravel all models are used by all 3 parts ?
My current structure:
./
./controllers/
./auth/
LoginController.php
RegistrationController.php
...
./admin/
ReportsController.php
UserController.php (Admins overview of all users)
...
./api/
HealthController.php (API CRUD for Health resource)
ExerciseController.php
HomeController.php
UserController.php (Regular users profile page CRUD)
...
./models/
User.php
Health.php
Exercise.php
...
One thing to remember about Django is that an app in Laravel doens't necessary translate to an app in Django. In Django, there are projects, and each project can have any number of apps. For example, I have a "Backup Admin" project where I manage a lot of the day-to-day issues of managing a tape backup environment. I have an app for media (that has 3 models, one for regular media, one for cleaning media, and one for media that we want to exclude from tape ejections). I have an app that represents the backup images, and another for backup jobs (to check status codes). Each sub-piece of my project goes into another app.
If I wanted to do another Django project that had nothing to do with backups, I'd make that a completely separate project, which would have a separate directory structure from my backup project. It'd have it's own urls.py, settings.py, etc.
Regarding the models piece, I put all of one app's models in the same file. For example, in my media app, I have models.py, which contains all three models that I mentioned above. This is completely optional, but I do it just so while importing these models into other parts of the project, I don't have to remember what the file names are, instead I can just do this:
from media.models import CleaningMedia,Media,EjectExclusions
Otherwise I'd have to have 3 different import statements if they were in different files. It's completely possible, but based on your preferences.
Regarding the controller, Django lets you do it either way. You have a project-wide urls.py file that you can use to control all of the traffic, or you can have separate urls.py files in each app to control that app's traffic. I prefer a single file, but that's just me. Personally if you have a lot of controller entries, you should probably split them up into app-specific urls.py files, just to keep it clean, but again, either method would work. I think of maintainability (especially with respect to teammates having to support it) when I make these types of decisions.
The admin interface is built-in, so there's not really an app for that, but you can decide which models and which apps have entries on the admin interface quite easily. Each app has an admin.py file that controls this.
A side note, for a RESTful API, you also might want to consider Django Rest Framework. It's a great piece of software, and the documentation (and tutorials) are very helpful.
Edit:
The 1 view/1 model thing again is just preference. You can have as many files as you want. The only trade off is when you import them into other files, you have to specify the file you're importing it from. That's really all there is to it. I know people who have a views/ directory, and inside there, have separate files for each view, keeping each class/function separate. Totally a matter of preference.
I am developing a business directory website, and it has
Home page
Search Result page
Listing page
I am currently at the design stage and someone suggested to separate the pages/functions into different apps, eg.
home
search_result
listing
Is this the best practise in the Django community? Or what would you do?
No. These sound like different views within a single business app.
You definitely don't want a new app per DetailView, ListView, or SearchView. That would quickly become confusing...
Think of what the app structure actually does: it adds database database table prefixes (appname_), splits models.py files and encourages its own views.py file and tests.py file.
The differences between the home, search_result, and listing views don't justify the above in my opinion.
If you want a directory/file structure that separates your distinct views, you could build a views directory in your app which contains individual search_result.py views... if they are long.
I am new to django and python and am trying to figure out how to modify an existing app to run multiple shops through a single domain.
Django's sites middleware seems inappropriate in this particular case because it manages different domains, not sites run through the same domain, e.g. : domain.com/uk domain.com/us domain.com/es etc.
Each site will need translated content - and minor template changes. The solution needs to be flexible enough to allow for easy modification of templates.
The forms will also need to vary a bit, e.g minor variances in fields and validation for each country specific shop.
I am thinking along the lines of the following as a solution and would love some feedback from experienced django-ers:
In short: same codebase, but separate country specific urls files, separate templates and separate database
Create a middleware class that does IP localisation, determines the country based on the URL and creates a database connection, e.g. /au/ will point to the au specific database and so on.
in root urls.py have routes that point to a separate country specific routing file, e..g
(r'^au/',include('urls_au')),
(r'^es/',include('urls_es')),
use a single template directory but in that directory have a localised directory structure, e.g. /base.html and /uk/base.html and write a custom template loader that looks for local templates first. (or have a separate directory for each shop and set the template directory path in middleware)
use the django internationalisation to manage translation strings throughout
slight variances in forms and models (e.g. ZA has an ID field, France has 'door code' and 'floor' etc.) I am unsure how to handle these variations but I suspect the tables will contain all fields but allowing nulls and the model will have all fields but allowing nulls. The forms will to be modified slightly for each shop.
Anyway, I am keen to get feedback on the best way to go about achieving this multi site solution. It seems like it would work, but feels a bit "hackish" and I wonder if there's a more elegant way of getting this solution to work.
Thanks,
imanc
There's no reason you can't the sites framework with multiple Django installations served from different subdirectories under the same domain.
OK I have done some further digging and it seems that the Django sites framework is not suitable for the same domain but with different paths:
www.mydomain.com/uk
www.mydomain.com/au
etc.
The two other options are an apache/wsgi set up where a separate wsgi and settings.py is referenced for each subdirectory. This seems a bit cumbersome; I don't really want to have to be reconfiguring apache each time I deploy a new shop. Also it'd make maintaining the local dev, online dev, staging and live versions of the site more hassle.
I think given this situation the best solution is to look at a middleware class that keeps track of country code and somehow changes database settings and root urls.py. Then each app is going to have to be aware of its current base url for things like form actions and links and so on.
What would be the best way to port an existing Drupal site to a Django application?
I have around 500 pages (mostly books module) and around 50 blog posts. I'm not using any 3rd party modules.
I would like to keep the current URLS (for SEO purposes) and migrate database to Django. I will create a simple blog application, so migrating blog posts should be ok. What would be the best way to serve 500+ pages with Django? I would like to use Admin to edit/add new pages.
All Django development is similar, and yours will fit the pattern.
Define the Django model for your books and blog posts.
Unit test that model using Django's built-in testing capabilities.
Write some small utilities to load your legacy data into Django. At this point, you'll realize that your Django model isn't perfect. Good. Fix it. Fix the tests. Redo the loads.
Configure the default admin interface to your model. At this point, you'll spend time tweaking the admin interface. You'll realize your data model is wrong. Which is a good thing. Fix your model. Fix your tests. Fix your loads.
Now that your data is correct, you can create templates from your legacy pages.
Create URL mappings and view functions to populate the templates from the data model.
Take the time to get the data model right. It really matters, because everything else is very simple if your data model is solid.
It may be possible to write Django models which work with the legacy database (I've done this in the past; see docs on manage.py inspectdb).
However, I'd follow advice above and design a clean database using Django conventions, and then migrate the data over. I usually write migration scripts which write to the new database through Django and read the old one using the raw Python DB APIs (while it is possible to tie Django to multiple databases simultaneously, too).
I also suggest taking a look at the available blogging apps for Django. If the one included in Pinax suits your need, go ahead and use Pinax as a starting point.
S.Lott answer is still valid after years, I try to complete the analysis with the tools and format to do the job.
There are many Drupal export tools out of there by now but with the very same request I go for Views Datasource choosing JSON as format. This module is very solid and available for the last version of Drupal. The JSON format is very fast in both parsing and encoding and it's easy to read and very Python-friendly (import json).
Using Views Datasource you can create a node view sorted by node id (nid), show a limited number of elements per page, configure a view path, add to it a filter identifier and pass to it the nid to read all elements until you get an empty JSON response.
When importing in Django you have a wide set of tools as well, starting from loaddata to load fixtures. Views Datasource exported JSON but it's not formatted as Django expects fixtures: you can write a custom admin command to do the import, where you can have the full control of the import flow.
You can start your command passing a nid=0 as argument and then let the procedure read, import and then fetch data from the next page passing simply the last nid read in the previous HTTP request. You can even restrict access to the path on view but you need additional configuration on the import side.
Regarding performance, just for example I parsed and imported 15.000+ nodes in less than 10 minutes via a Django 1.8 custom admin command on an 8 core / 8 GB Linux virtual machine and PostgreSQL as DBMS, logging success and error information into a custom model for each node.
These are the basics for import/export between these two platform, for detailed information I described all the major steps for export from Drupal and then import to Django in this guide.