Up till now I was using ember by including all required vendor files in Django static folders. With the rise of ember-cli more and more ember related files are not available in stand-alone version. They require using npm and/or ember-cli.
Ember-cli uses npm, and it creates and manages its own files, create all project files and manages loading them... so now how can I integrate than withing a Django application. Like:
I want to hook up an ember application on a given page in Django. ember-cli doesn't seems to cover such scenarios?
all vendor files (JS and other) must be served by Django / found by staticfiles finders. npm won't install to Django project staticfiles directory.
and it would be good to be able to collect files/make apps withing separate subfolders so that older apps won't break when newer app pulls newer vendor files etc.
So is that somewhat doable with ember-cli and Django? What is the best way to handle such projects?
You are going to need to set up a build and deployment process in order to deploy the assets built by Ember so that they can be served by your Django application.
I want to hook up an ember application on a given page in Django.
ember-cli doesn't seems to cover such scenarios?
You can most definitely have an Ember application live within a Django page. Set up your appplication outlet within the page served by Django.
all vendor files (JS and other) must be served by Django / found by
staticfiles finders. npm won't install to Django project staticfiles
directory.
Set up a process that copies the dependencies downloaded by npm to the static files
directory as part of your deployment.
and it would be good to be able to collect files/make apps withing
separate subfolders so that older apps won't break when newer app
pulls newer vendor files etc.
It would seem an equaly bad idea to have multiple copies of the same dependency floating around -- especially if a single user will navigate to multiple ember applications hosted on various pages of your Django app which rely on the same libraries. You will have to make a choice of whether to try to maintain the depencies for each of your Ember applications individually or to ugrade depencies across each of them at the same time. This will depend on your needs and how tightly coupled the functionality in each of your apps is.
Related
I've already gotten my fair share of Bootstrap and Django but never tried out other frontend frameworks like Angular, React, etc. and finally wanted to try SvelteKit. So I'm really inexperienced and new with this sort of stuff.
Currently I've already set-up my Django project as well as a SvelteKit project by following the tutorial on their website.
My problem is that I'm confused about how to combine Django and SvelteKit now. Do I just run both servers simultaneously on different ports and get the data from Django JSON APIs into my Svelte frontend or is there some kind of approach to this? I thought that maybe there's a way to get my Django app to render the Svelte files from the Svelte server for me. I just feel really lost at the moment so if anyone could help me or has some resources I could read to get more familiar with the topic, since I didn't find a lot online, that'd be great!
Many thanks in advance!
First, understand the difference between Svelte and SvelteKit. SvelteKit is a front-end + server solution that is a layer above vanilla Svelte. SvelteKit adds things like routing and support for sever(less) functions.
If you want to use Django for all your server-side processing, you should just use (vanilla) Svelte to write independent web components that you call from html served by Django. No need to use SvelteKit if you aren't using any of the extra framework features.
How to write a web component with vanilla Svelte
How to write a web component with SvelteKit.
If you want to just write your API's in Django and do everything else from SvelteKit, I would run both Django and SvelteKit servers from different subdomains and/or ports. Like django.example.com and kit.example.com or example.com:8000 and example.com:3000.
SvelteKit also provides a low-level handle() hook that can bypass SvelteKit, but usually JS/node.js is still used. I think it would be tricky to pass a request from SvelteKit to Django.
I find myself having the same question, it's not perfect but I got it to work with the following:
Create a directory that will contain everything, e.g. my-project
Inside the directory create your Django project, e.g. django-svelte, with django-admin startproject django-svelte
From my-project/django-svelte create an app to contain the svelte app, e.g. frontend, with python manage.py startapp frontend
Inside frontend create two subdirectories templates and static; inside each of them create a frontend directory. (You should have frontend/templates/frontend and frontend/static/frontend in the end)
Inside my-project initialize a svelte-kit project, e.g. client, with npm init svelte client
Inside client install all packages and add #sveltejs/adapter-static with npm install and npm i -D #sveltejs/adapter-static
Replace the content of svelte.config.js with:
import adapter from '#sveltejs/adapter-static';
export default {
kit: {
paths: { base: "/static/frontend" }, // Adjust according to where you collect static files and the name of the Django app
adapter: adapter({
pages: '../django-svelte/frontend/templates/frontend', // Adjust according to the name of the Django app
assets: '../django-svelte/frontend/static/frontend', // Adjust according to the name of the Django app
fallback: null,
precompress: false
}),
prerender: {
// This can be false if you're using a fallback (i.e. SPA mode)
default: true
}
}
};
This will write your HTML, JS and CSS files inside the frontend app.
Create a build with npm run build
Collect static files in Django with python manage.py collectstatic
Run Django with python manage.py runserver or other servers
I'm sure there are simpler ways though :-)
I made a simple template for svelte and django. please check this link: https://github.com/Pei2tech/svelte4django. What you need to add routing to support svelte instead of using sveltekit.
There are plenty of tutorials and helpful posts how to use Django and Vue properly (in various options) all over the Internet.
But I didn't find a single one who describes how to create a Django application which consists of more than one app, each having it's own part of the Vue frontend.
I am creating a Django application with a Vue frontend, and it will have a lot of apps that can be plugged into the main system very easily (using a custom framework). But this only is the backend. I'd like to enable each Django app for having a "plugin" part of the frontend as well: e.g. a set of Vue components that are rendered "dynamically" in the frontend when this app is added in INSTALLED_APPS.
How can I provide "plugin hooks" in Vue to load those components? All the things I have seen (dynamic/lazy component loading with webpack using webpack-loader, etc.) is not what I want. It only describes how to load a component that is predefined later in the http request timeline.
How am I supposed to "merge" all the components? Can I simply create components in static folders and let ./manage.py collectstatic do the magic?
It doesn't matter if the application is a SPA or maybe I have to use Django templates (with Vue components included) - both would be a viable method.
Maybe this even is a webpack question and should be: How do I bring Vue (or React, etc) to collect its sources from different subdirectories like foo_app/static/, blah_app/static/, bar_app/static - is there a way to tell Vue/Webpack/etc to search in myproject/*/static for Vue components to merge?
And can I include "all components" (dynamical amount) than in another component, which is needed for such a system?
Can anyone enlighten me here - is that completely impossible? Or am I thinking in the wrong direction?
Thanks.
I have a couple of VueJS apps in my django site and I'm planning to add more.
I bundle them with webpack with the help of django-webpack-loader.
https://github.com/owais/django-webpack-loader
Currently I'm working on a project which uses Ember and requirejs. My plan is to migrate the project to ember-cli, but I'm facing some problems.
My app consists of multiple apps and one shared folder in which I put shared code of all other apps (like models, adapters, serializers, helpers, routes etc.). Not all of this code is used by every app, they only require what they need.
My plan is to create multiple ember apps of the apps mentioned above and move the shared code to an ember addon. Now I am wondering if it is possible to only include a part of this ember addon into the applications (only what they need). I did not find any relevant information in the docs for this use case.
Any ideas would be appreciated.
I ended up using the addon folder within my addon to share most of the files. This files can be imported from all apps and when building only the imported files are included into the final build file.
I have created an ember application (prior to the arrival of Ember CLI) which follows a file hierarchy as given below:
Modules
Controllers
Views
Models
Routes
App.js
I would like to know that is there any way to deploy these files by compiling as a single javascript and html file, like now we are doing in ember cli. Since my application is using offline APP Cache, I terribly need this feature to avoid save numberous files and downloading it from cache manifest file.
After some research I have decided to update application with Ember CLI. This seems to be the best option to build and deploy Ember Application.
In Java world, a common way to distribute a web app is to package it along with Apache Tomcat.
What is the appropriate way to achieve something like that with Django (or any WSGI application for that matter)?
There are two camps for distributing apps in django. It also depends on what you mean by apps.
If you mean an apps is in django terms as in 'pluggable apps' that is separated from the project, then it would be best to use setuptools to package those 'pluggable apps'. Many django 'pluggable apps' are distributed like this. For example:
django-tagging
django-registration
etc.
But if you mean an apps is a full-blown apps (the whole war file) as in Java EE terms, then you would have all off your apps inside a your project, and you would just distribute the project in any forms. Normally you would just zip it. You don't need to install it with setuptools or what so ever, as you would run your project from the project folder. Examples in this camps are:
Pinax
Satchmo
The first way is convenient if you already have django project running and you want to re-use those pluggable apps in many other projects. This is really good if you are building non-monolithic web application or an in-house application/websites or a reusable application . It's also convenient if you are managing your project and those pluggable apps by yourself. It's sort of inconvenient (to some extent) if you want to sell an apps to a customer with this kind of approach because your project and your pluggable apps lives in a different directories. Some people said that they don't have any issues with this approach.
The second way would be more convenient if you are selling your apps to a client because all of the apps is inside your project and you would only extract your project when you are at the client side. This style is more often called the monolithic style. Java EE and Ruby on Rails have a monolithic deployment style. You wouldn't need to install your 'pluggable apps' one by one (assuming you don't use any external pluggable apps in your project) when you are at the client side. But again, you would have some issues if you want to reuse those small apps inside the projects. If you don't have any plan to re-use those small apps, then this way is good enough.
setuptools is a common way to distribute any Python packages, Django apps included, and many of the more substantial Django apps (Pinax comes to mind) will either distribute through the cheeseshop or as tarballs or zips with setuptools-produced setup.py files.
Less substantial reusable apps will just distribute as compressed files, which works fine as they should be highly portable.
A django app is not much different from a python module, which you can package using python's setuptools.