Here is a link to the Github project.
As you can see, I’ve forked it from the latest known / best boostrap-studio-to-django-template repository by someone else. I’ve fixed a few bugs and have defeatured the .sh script because I never could get that to run on Windows.
Right now, under releases, there is a Windows EXE that you pass into BSS under Export Settings > Advanced. It currently works.
In configuration.json I’ve created a boolean field such that “True” means do include the folder containing settings.py (that is the default project app created when you create a Django project) as a regular app (ie. run the export process as if that folder were any other Django app you’ve added in).
I noticed with my personal usage, that I don’t want to generate the forms by hand using BSS, but instead want to use Django’s built-in automatic form generation. In that case I’m going to make it so that you create a <form id="ReplaceWithDjango-sign_up> Some comment </form> placeholder stub on the BSS side, and the export script will search the current templates/<app_name> directory for sign_up.html and either do a Jinja2 include or simply insert the whole file’s content in place into the BSS to Django template. That is what I’m working on next, because I need to make a sign up / sign in system (i.e. using Django forms) at the moment.
If you’d like any features added, please make a post in the issues forum on the above-linked Github page.
A usage rule is you don’t hand edit the BSS-exported output, that will get continually rewritten as you develop your UX / UI in BSS, which is the optimal way to edit those things of course 
3 Likes
I saw this project some time ago after doing it the manual way. I have two projects coming up in the upcoming year I may give this a spin on.
On another note I have been looking for some projects to contribute on.
2 Likes
@apowell656 That’s awesome! I’m working on a math website. There’s a lot that can be done for the exporter script. Wouldn’t it be nice, for example, if it knew about the Django templating system and the output of it imported parts of the output in an optimal way… Would be non-trivial to implement, but perhaps it’s not even necessary. I do know that it would be difficult to recreate all the fancy Django form mechanics in BSS, so the first thing I’m going to do is put in that #ReplaceWithDjango-form_name ID thing. The export script uses BeautifulSoup library to parse and modify the HTML tree.
Here’s the latest (working) release. Let me know if you want to set it up soon, and we could write the setup instructions together (the github Readme is outdated currently).
Also, you would need to use strictly Windows for now (this is a Windows PE format EXE). Later once we’re confident of our project enough and have time, we can generate scripts for Linux / Apple desktops as well.
That is the final result I’m getting (as running on a Django instance). So as you can see it’s putting things in the correct Django folders, etc, and it’s also loading a handwritten Django sign_up.html using a Jinja2 include line. Looks bad though, I’m thinking I’m going to now put that sign-up stuff in a pop-up Modal box
Cool. I will take it for a spin this weekend.
Getting this working cross-platform will be important. I spend more of my time in Apple and Linux enviroments for my own sanity and to my wife’s annoyance 
1 Like
Hi
Here is the new setup:
My BSS ideas post
I have it almost functional (without code-generation capabilities) just as in the archived fork of the original code on Github.
The only thing from the original author’s code that still exists in the app is TagConverter class, though I’m gradually making modifications to it.
Right now I’m designing a code injection system so that you can drive boilerplate code from the BSS design itself.
You will be able to edit in and around the boiler plate, but if you edit any part of the non-whitespace in the template, you take over ownership of that injection site. So if the user wants to change the logic of the template, they should just create a new boilerplate.
Okay, decided against in-depth code generation and injection. I will however have it generate a default view function if it doesn’t exist that simply returns the rendered page. I have it rendering just the home page now (no JS console errors!), on the Django side.
Here is the current state-of-the-art:
I’m working on the two bugs listed in the issues forum there.
