I'm creating a basic Ember application. I am trying to set up a backend that stores posts. I would like to have a system where I can go to some admin site that has a form that has all the fields for a post that allows me to add, update, and delete posts. For example, if I have a Post model with attributes like Title, Contents, Date_created, and Image, I would like to have these fields in a form in some kind of admin site.
One example from a past tutorial I have done is the Django admin site. Is it possible to set up a Django backend for my Ember app? The Django admin is here: (scroll to bottom)
https://docs.djangoproject.com/en/1.10/intro/tutorial02/
I know that asking how to set up a backend for my Ember application is a very general question, but I am confused as to where to start. I have already created a Post model with various attributes. I can create an Ember route that is a form to add a post, but then there comes authentication for that which I'm not really sure how to deal with either. That's why I came to Django because I remember they had a very nice admin site.
If it is not feasible to use Django to accomplish this, what are some other routes I can take to be able to get to some admin page where I can manipulate records and add new data to my website?
This is a pretty big question, but I feel your pain. Most tutorials are all, "so... just build out a rails app... or use all this long lost stubbing stuff... or here's a super outdated node server on github to use."
I would suggest breaking it down into pieces. Ember is really great, but–Yes–you need a backend. You could make a backend with Django(python), Rails(ruby), WordPress(PHP) + ember-wordpress, express or hapi(node), phoenix(elixir)- or really anything that will generate an API. You could also build an admin with Ember and then use that to send data to a service like parse or firebase. Those could get you an MVP while you learn more about how to build out a traditional back-end.
Django + http://www.django-rest-framework.org has a pretty great admin setup that builds out the admin and fields from your API specifications. I can see why people like it.
I would also mention, that ember-cli-mirage is great when you aren't sure what backend you'll have, but you need to have a mock-server to build off of.
If you can, choose something that will spit out an API with jsonAPI.
I would split this into 2 parts.
build out an Ember app with Mirage or some other temporary data.
build a back-end somehow.
Then you can connect them ~ without being stuck beforehand.
Good luck!
So pretty much a blog site where only person can create/delete/edit posts? If so then all you have to do is create a user with a predefined username and password in your Django app. You login through your Ember app. For this protected view you will need to use ember-simple-auth, which is the simplest way to implement something like this. Google ember-simple-auth and run its dummy app to see what they are doing.
Related
I'm trying some Django + React stuff and I'm a bit confused with the particular role of Django model in this scheme.
As I can understand Django model provide smooth way to create some typical forms by users of the site (please correct me). And I can't feel the edge of what should be hardcoded and what I need to store in model.
In case of React (I'm trying to connect react with django through api via djangorestframework) should I create a model for Header? And store bg image with it and my slogans. I feel it's should be purely in frontend. But next section with 3 typical screens (they will be listed horizontally and swap each other). They are just copy of each other with different data (title, bg, fg, text, link), for me it seems closer to model usage. But model initially empty and if I want to get this data from model I firstly need to somehow store this data to model.
So in general my question is what the right cases for using Django models and when it's no needed. And if it possible with applying to my example to better understanding for me )
ofc I searched this info widely but so far can't create clear understanding by myself.
Thanks )
You might actually be in search of a headless CMS.
To combine React and Django and still use a CMS to allow administrating text blocks and images, Django Wagtail's StreamField is a good choice.
https://docs.wagtail.io/en/v2.0/topics/streamfield.html
See for example our company's homepage: https://www.blu-beyond.com. It runs on Django Wagtail, having JS animated text blocks that are administered in the CMS (just jQuery and other JS libs, no React, in this case).
Django Wagtail offers a JSON API, as well, that can be used in React:
https://docs.wagtail.io/en/v2.8/advanced_topics/api/v2/usage.html#fetching-content
It also offers a GraphQL API.
Im really confused about what is all i need to consider for creating a django aplication with almost similar functionality to it's own admin.
The index page should deploy the list of models the user has access to modify or create...almost the same as when you put admin.site.register(MyModel) but with permission restriction. Im not sure how should i ckeck permissions, and show 1 ,2 or many "ModelAdmis" on my main page.
btw admin users are redirected to the admin index page, non-admins go to my page
Before you consider creating a django admin from scratch, you should read the answers to this question Django Admin app or roll my own?
I couldn't find any resource on how to create a django admin from scratch, but here's what you should do if this is your first time overriding a framework's functionality (in my humble opinion):
Understand and make sure you are comfortable with the django admin app
start from the docs https://docs.djangoproject.com/en/1.7/#the-admin
Head over to the django admin app source code so you can start reading the internals of the functionality you want to implement/override in your new admin app.
source code can be found here https://github.com/django/django/tree/master/django/contrib/admin
(this may involve reading other apps source code too)
After those two steps you should have an idea on how the admin app is implemented and it's dependencies, then you can start creating your custom admin app.
an example on how this may go can be found in this qestion:
How to override Django admin's views?
If you are building something new, try to separate the UI from the backend. You can build your UI using react, angular or whatever and interact with django using the API. To build the API you can use the Django Rest Framework.
Don't use the Django Admin as a public interface. Use that only for the admins!
If you start to use the Django Admin as interface for your public site, you'll fight with the package to tailor and secure the views to avoid destructive actions. What happen if you forget a readonly field? What if the user deleted something ON_CASCADE?
Building the UI you are totally free and you can customise easily everything without fighting the django admin package (it's awesome package but is not provided for public use)
I have a medium sized Drupal 6 site running (around 5 million page views per month and more than 30K registered users) and I need to integrate OSQA, a Django application, with it. I already have many users, roles and permissions in my Drupal database and I'd like to point the Django app to use the sign up and login pages I already have in Drupal to give my users a single point on entrance.
I want to keep the Django authentication part because I think OSQA would work better. I also have performance reasons in mind, the Drupal site already gets a lot of traffic and has a very busy database and I think that using a separate database for Django would help.
After some research I think I could make the Drupal sign up and login pages call Django in the background to sign up or login to the Django app. I plan to do this writing a couple of views in Django, one for sign up and another for login, and Drupal would post the username and password to those views. Of course I'd need to disable CSRF in Django for those views and probably also post some secret key that only my Drupal and Django applications know about to avoid external sites trying to use this "unprotected" Django views.
I know that my Django application may need some user data from Drupal at some points and I'm planning on using the Drupal services module for that.
Would this be a good approach? Any suggestions?
Thanks a lot!
Are there any plugins for OSQA to expose an authentication service that Drupal can talk to? (OpenID or similar).
Alternatively, check out Drupal's ldap_integration module for an example of a module that uses an external authentication service. Consider that you will need to create Drupal user accounts for each login.
Finally, why not just build the essential parts of OSQA's functionality with Drupal? Seems like the key functionality could be replicated quite easily using Taxonomy, Vote Up and Userpoints/User Badges... potentially easier to do than shared authentication, especially on a large site.
I once created a very simple [sql_authentication][1] module, which you can probably simply re-create for a more recent version of Drupal.
The idea is simple: provide Drupal with an alternative authentication callback.
In that callback-function, just check against the Django database, and return TRUE if you think the user is correct.
You could look at how openid.module (in core) extends the user-authentication for a simple example.
If you can post to the Django form, you may be able to use drupal_http_request to handle the call to Django. After using the ldap_integration module for a while, I worked on a custom authentication module that calls a Java-based REST authentication API using drupal_http_request. If you're interested in the code, let me know.
Im still fairly new to Django, so please explain things with that in
mind.
I'm trying to create three websites using 2 subdomains and 1 domain:
for the blog, blog.mysite.com
for the forums, forums.mysite.com
for the custom web app, mysite.com
When building the custom web app, I used contrib.auth to make use of
the built-in django provided user models and functionality.
For the forums, I am planning on using SNAPboard (http://
code.google.com/p/snapboard/) with minimal, if any, modifications. On
initial inspection, it looks like it also uses contrib.auth users.
For the blog, I will probably be rolling my own lightweight blogging
app (since that seems to be the Django way and, also, b/c as Bennet
mentions, there is no killer Django Blog app)
Currently, I am considering two features that require some integration
between the three sites. First, I want to have the users of the custom
web app to use the same account to also log into the forums. Second, I
also (but I haven't figured out how I'm going to do this yet) would
like my blog posts to automatically become a topic for discussion in
the forums (this is just an idea I had, I might end up dropping it).
Ok, so to my questions:
1) Again, I'm new to Django, but this integration leads me to believe
the three websites need to be all under one project. Is this correct?
2) How would I accomplish the url structure for the websites that I
described above (blog.mysite.com, etc)? In the project's urls.py, I
don't know how to filter off of subdomains. If it was mysite.com/
forums/, that would be easy, but I don't know how to to catch
forums.mysite.com and forward it to the appropriate Django app.
3) Would I have to make use of the django.contrib.sites framework? I
don't understand that framework fully, but it seems like it's used
when two different websites are using the same django app in the
background. Whereas my three websites are all using different django
apps, but I want them to share a little bit of data.
Thanks for your help.
1) Yes, it's only true way for that
2) Use middleware
3) No, you don't need it.
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.