We Keep Coding

Best way to use a PyQt5 Model within a PyQt5 TreeModel

I have a code structure already using SQLAlchemy to make declarative models.
Example Tables/Models:
Repository
repository_id
name
owner
Endpoint
repository_id
endpoint_id
name
method
Contexts
context_id
endpoint_id
parent_context_id
config
created_on
created_by
I'd like to make a QtTree to select a Repository > Endpoint > Context > Nested Context.
Similar to how an IDE may have a browser view that shows both folders/packages/files and give different right-click menus to each.
I'm trying to understand what the "proper" way of implementing this would be.
I've looked at GitHub to see what other people have done, but most of small open source apps just use a TreeWidget and have more or less hard-coded views or large projects like "Eric" which are doing things like Lazy Loading... and I'm not sure if it's total overkill for what I'm looking to do -- the 1700+ lines of custom implementation code in Eric has seemed to give more feedback than anything else I've seen... but I still have the issue that my model issue is already semi-defined once...
Since I'm primarily using SQLAlchemy for the rest of the application, should I first create/use a "SqlAlchemyTableModel" to scaffold each model, then create a "BrowserModel" that performs the logic to create these?
Should the RepositoryModel/EndpointModel/ContextModel be a subclass, or is it sufficient to just create them through a generic class?
Ideally I'd like the Repository/Endpoint/Etc to have different icons in the list and different ContextMenus. Should these be set in their model? Through the parent model? Through a decorator proxy? Through view delegates?
I feel like I have a million hammers but I have no clue if what I'm looking at is a nail or a screw.
Reference:
https://github.com/davy39/eric/blob/master/UI/BrowserModel.py

Highly customized admin - Create an app or hack the source code?

I have been facing a big challenge with django since I was assigned the task to rebuild the admin page of our platform. I started unsure of what to do and now that I am half way on, I am even more unsure.
Here is my question:
If I want to build a highly customized admin, should I do a giant hack on the source code or create a new app?
1) Giant Hack
That is how I started and got stuck. A couple of problems appeared on the way, for instance:
I had to extend the AdminSite and override every view I wanted to change
Django's admin is very modular (I mean, very very modular) and a screen might be the sum of tons of other templates
Creating a simple navbar is a pain in the ass (at least it has been for a newbie like me). This is due to the fact that app_list (the variable that contains the mapped models to show in admin's first page) not being accessible when other templates rather than base.html are injected. Thus, I would have to create a context processor, replace every TemplateResponse() by render() (technically, since I tried to do it and it didn't work as well)
The problems go on and on. Given my lack of experience with django, I might be doing crap, but it does feel like I am on the wrong way.
this guy's answer motivated me to post this.
2) Building a brand new app
Of course it will take a little while to implement this, but it seems like a robust and maintainable way of getting it done. One of the points is that I will need to give the same flexibility as the default admin site gives when adding models and promptly having their cruds and tables (I am not really sure how to accomplish this behavior).
I am pretty new to django and any guidelines will be highly appreciated. Give me your thoughts on how to make it.

There is no need to overwrite admin views. The easiest way is to overwrite the templates and add your own css & javascripts.
I have added my own navbar, sidebars and bottom. It is really easy if you overwrite the admin base templates.
If needed you can provide custom data to the template by using own templatetags.

Django Flowchart Model

Is anyone aware of a Django app for designing and storing flowcharts in a database? After searching for variations of "Django flowcharts", I've only found flowcharts of Django's internal design, not anything about authoring or storing flowcharts in a Django webapp.
As asked in a similar question, I've found several impressive Javascript and JQuery based libraries for browser-based flowchart design, but nothing for persisting these server-side.

I wrote an app that stores and controls state machines in Django 1.2:
https://bitbucket.org/canassa/zinaflow
It uses a per-object permission model for controlling the transitions and GenericForeignKeys for attaching the state machine to any model in your application. With the per-object permissions you can assign a Django user for each transition.
Depending on what you need to do, this app might be a overkill for you. But reading the source code can give you some ideias on how to implement an app yourself.

Why couldn't you do it yourself? The behavior and presentation is already implemented in the several truly impressive JavaScript libraries you've referenced, now all that's left to be done is to store the models in the database for your favorite pick you'd like to persist through Django.
There is a library that implements Modified Preorder Tree Traversal on the model level that I'm sure would be of great use to you to store the logical relations between the flowchart elements and other presentation data, such as the coordinates, shape, it's transformations and other visual properties can be easily stored alongside.
I'm sure that if you'd give it some thought you could quickly execute it; hell it's even probable that there are many people who need the same thing, which would make it even more useful if you weren't developing it just for yourself. This seems like a good candidate for an OS Django app.

I am not aware of an existing app that does this, but if you want to start developing your own a good place to start would be exploring the code for GraphModels, a command from the excellent django-command-extensions project. It is a django manage.py extension that creates database diagrams from models using graphviz.

Linking google-appengine native model to Django model

I've ported my GAE project to django-nonrel, and now I would like to have link from my object to Django User object:
class Opinion(google.appengine.ext.db.Model):
...
author = db.ReferenceProperty(django.contrib.auth.User)
Unfortunately, that's not possible, since you only can link GAE models this way.
Question - what's the best way to solve this? Is it possible or should I work it around somehow?
I don't want to migrate my old GAE model since I already have a bunch of data there.

My initial googling and searching brought me nothing good:
On django-nonrel list I read:
You cannot use appengine model into django-nonrel. You need alter all
your models to django proper. That is, use original
django-registration app not the appengine-patch provided registration.
Another question, exactly like mine, was left unanswered.
... and I've found another place where people recommend switching to Django models.
I guess that's that then, there is no way of doing what I need, one needs to migrate.

How do you manage your Django applications?

I just wanted to try to build a project with django. Therefore I have a (basic) question on how to manage such a project. Since I cannot find any guidelines or so on how to split a project into applications.
Let's take a kind of SO as an example. Which applications would you use?
I'd say there should be the applications "users" and "questions". But what if there was a topic system with static articles, too. Maybe they also could receive votes.
How to build the apps structure then? One app for "questions", "votes" and "topics" or just one app "content"?
I have no idea what to do. Maybe it's because I know not very much about Django yet, but I'm interested either...

There aren't hard-and-fast rules, but I would say it's better to err on the side of more specialized applications. Ideally an application should handle just one functional concern: i.e. "tagging" or "commenting" or "auth/auth" or "posts." This type of design will also help you reuse available open source applications instead of reinventing the wheel (i.e. Django comes with auth and comments apps, django-tagging or django-taggable can almost certainly do what you need, etc).
Generic foreign keys can help you decouple applications such as tagging or commenting that might be applied to models from several other applications.

You should try and separate the project in as much applications as possible. For most projects an application will not contain more than 5 models. For example a project like SO would have separate applications for UsersProfiles, Questions, Tags (there's a ready one in django for this), etc. If there was a system with static pages that'd be a separate application too (there are ready ones for this purpose). You should also try and make your applications as generic as possible, so you may reuse them in other projects. There's a good presentation on reusable apps.

Just like any set of dependencies... try to find the most useful stand-alone aspects of the project and make those stand-alone apps. Other Django Apps will have higher level functionality, and reuse the parts of the lowest level apps that you have set up.
In my project, I have a calendar app with its own Event object in its models. I also have a carpool database set up, and for the departure time and the duration I use the calendar's Event object right in my RideShare tables. The carpooling database is calendar-aware, and gets all the nice .ics export and calendar views from the calendar app for 'free.'
There are some tricks to getting the Apps reusable, like naming the templates directory: project/app2/templates/app2/index.html. This lets you refer to app2/index.html from any other app, and get the right template. I picked that one up looking at the built-in reusable apps in Django itself. Pinax is a bit of a monster size-wise but it also demonstrates a nice reusable App structure.
If in doubt, forget about reusable apps for now. Put all your messages and polls in one app and get through one rev. You'll discover during the process what steps feel unnecessary, and could be broken out as something stand-alone in the future.

A good question to ask yourself when deciding whether or not to write an app is "could I use this in another project?". If you think you could, then consider what it would take to make the application as independent as possible; How can you reduce the dependancies so that the app doesn't rely on anything specific to a particular project.
Some of the ways you can do this are:
Giving each app its own urls.py
Allowing model types to be passed in as parameters rather than explicitly declaring what models are used in your views. Generic views use this principle.
Make your templates easily overridden by having some sort of template_name parameter passed in your urls.py
Make sure you can do reverse url lookups with your objects and views. This means naming your views in the urls.py and creating get_absolute_url methods on your models.
In some cases like Tagging, GenericForeignKeys can be used to associate a model in your app to any other model, regardless of whether it has ForeignKeys "looking back" at it.

I'll tell you how I am approaching such question: I usually sit with a sheet of paper and draw the boxes (functionalities) and arrows (interdependencies between functionalities). I am sure there are methodologies or other things that could help you, but my approach usually works for me (YMMV, of course).
Knowing what a site is supposed to be is basic, though. ;)