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.
Related
My team and I are having a hard time defining the architecture for my backend environment using Django.
To contextualize a little, we built an application similar to an App Store, for all our developments to be displayed, with the difference that it also launches the apps.
To maintain all the information about this apps, we built this backend in Django that is basically a database accessed through an API from the App Store, and a Django Admin website to register the informations to be delivered in the API (the one Django automatically generates).
The thing is, today, we have only one technology involved and therefore only one database and one Django Admin. But, other areas in our company want to use this architecture we built, with other apps and therefore other informations, not related to our environment.
The question is, should we deploy several Djangos in different ports of our server? Or should we try to create a dependency in our models to a "Technology" related to it? (For this option it is important to note that our architecture is complex and highly nested). Or maybe should we use the multiple databases provided from Django?
Has anyone had a situation similar to this one?
Thank you in advance!
The problem for me with creating a dependency in our models to a "Technology" is has to do with what OP means with other informations which are not related to OP's environment. Is OP able to create a database model that works, whose system is not overly complex and that can accommodate for all of the cases OP wants? If that's the case, I don't see why not.
There's an interesting Q&A talking about having multiple instances of Django in the same server. Personally I have already deployed in virtual shared hosts whose logic was essentially that, with the limitation that OP is sharing with other people too. OP can see in that thread that there are various cases where it was a viable option. Personally I find such shared hosts only viable in initial stages as they weren't as performant... but a great way to save resources if one is working with tight budgets. IMO this can be one of the best options for OP's case... which is considered single-tenant.
In regards to multiple databases, this automatically leads me to an approach to multi-tenant applications (within the multi-tenant applications there are approaches where one only needs one database as well). OP wants to go for this case if OP's application can serve all of the users from the same host, which doesn't seem the case for OP, unless OP is able to create a dependency in OP's models to a "Technology" (as addressed in the first paragraph).
I am reading Django documentation (https://docs.djangoproject.com/en/3.0/ref/contrib/contenttypes/#module-django.contrib.contenttypes).
I did not understand content type app, the Django docs describe it as below
Django includes a contenttypes application that can track all of the models installed in your Django-powered project, providing a high-level, generic interface for working with your models.
Can someone explain this from beginner perspective ?
I have experience in developing websites in Django but never touched in this app.
Example: you want to make user-related logging, something like an audit module in user profile. You have dozen of models that could be logged. User, Order, Task, Product, etc.
So your main model will be something like AuditEntity.
How to make it general for all possible current (and future models) that could be logged here? Which type of field do you need?
The answer is Django contenttypes.
If you want - try to implement such a model's structure to understand how it works.
I think that what is trying to tell you is that you can have different content (in blocks, as it is organized in "blocks" and it is very "module friendly", I hope to give the idea), this content is made up of different things, especially models, let's just say that they are like big classes of things needed in your application (don't judge this expression, I know it is not professional but is the more beginner friendly I can write now), hope this makes more clear!
I am new to Flask and have noticed that there are two plugins that enable CRUD views and authorized login, Flask-Admin and Flask-AppBuilder.
These two features interest me along with nice Master-Detail views for my model, where I can see both the rows of the master table and the relevant details on the same screen.
Any idea which one to prefer? I see that Flask-AppBuilder has far more commits in Github, while Flask-Admin many more stars.
How to tell the difference, without spending too much time with the wrong choice?
I am the developer of Flask-AppBuilder, so maybe a strong bias here. I will try to give you my most honest view. I do not know Flask-Admin that much, so i will probably make some mistakes.
Flask-Admin and Flask-AppBuilder:
Will both give you an admin interface for Flask with bootstrap.
Will both make their best to get out of your way.
Will both help you develop Flask more Object Oriented style.
Will both let you override almost everything on the admin templates.
Will both support Babel.
Both inspired on Django-Admin.
Pros for Flask-AppBuilder:
Has a nicer look and feel (bias? maybe...).
Security has been taken care of for you, and supports out of the box, database, LDAP, OpenID, Web server integrated (REMOTE_USER), and in the near future OAuth too. Will let you extend the user model and security views.
Granular permissions, creates one permission for each web exposed method and action (you have to try it).
You can easily render Google graphs.
Smaller project, it's easier to request new features, and get your pull requests merged.
MasterDetail views and multiple views can be setup easily.
Backends: supports SQLAlchemy, MongoEngine, GenericInterface (you can integrate with your own builtin data still a bit beta).
Pros for Flask-Admin:
You have to assemble your own security (models, views, auth etc), it's ready though to integrate nicely with flask-security. This can be a pro or a con depending on what you want.
Builtin File Admin.
Bigger project with bigger community.
Backends: supports SQLAlchemy, GeoAlchemy, MongoEngine, Pewee and PyMongo.
Better support for MongoEngine (EmbeddedDocument, ListFields etc..).
On the overall i think Flask-Admin makes no assumptions at all like Flask, you have to code more, but this will let you be more free. Flask-AppBuilder makes some assumptions (on security), you will have to code much less, but some things can get on your way if your building very specific security models.
Hope this helps you and others, i tried my best to keep the bias out.
For me, master/detail is the major feature. That led me to use Flask AppBuilder to create ApiLogicServer:
With 1 command, create a database API, to unblock UI development. Also, a multi-page web app, to engage Business Users - early in the project. Declare logic with spreadsheet-like rules - 40X more concise than code, extensible with Python - for remarkable business agility.
I have a Django web front-end that consumes data from a REST API backend.
Even the users are made and created on the backend.
My Problem :
How to use 3rd party apps within this system, that heavily depend on django models/ORM ?
Is there something that can provide some bridge between the REST API resources and the ORM?
How can this problem be dealt with ?
Update
DRY principal seems to be failing in this situation.
Probably things have changed since this question has been originally posted. Now there are a couple of interesting related questions on StackOverflow about this topic.
To code yourself a solution as explained in this answer, you can create an external service layer (aka services.py) and write there the logic to access the external resources. Your views will consume this layer, and make the proper actions. There are other questions that provide help on how to pass information from the original request received by the django-view to the external service like this or this
There is also a django app that takes this situation into account as explained in this answer. django-roa uses the Resource Oriented Architecture paradigm to solve this.
I'm facing a similar obstacle with a new ecommerce project.
The project is a front end to a full-fledged store management software (CMS+ERP+CRM). It needs to use the master product database, but have its own entries for product reviews, ratings and so on.
The initial thought was to make a cached copy of the master database. The website will benefit from fast loading times for the cached items, but the implementation is not trivial.
After some considerations, the selected approach was updating the website's DB from the management program. This way the website's copy will always be correct, and most of the implementation doesn't need to worry about REST services (it'll still be used for user registration, shipment tracking etc.)
In your case, where you can't have the service update your own database remotely, you need to come up with a mechanism that allows you to refer to REST recourses like regular models, and that caches them in the background.
Important note: research for a way to make sure the cache is always correct (non-dirty)...
I'm not sure I completely understand your question or requirements. The way I am reading it, you have a primary back-end which is basically a black-box, and you want to use some 3rd-party apps in your project which use the Django ORM.
I am unclear as to why there would be a need for being able to have a two-way synchronization between the two data-stores. The users of your project would be returned data from your primary back-end, and from the project's ORM.
Since you are concerned about saving the "ORM" data in your primary back-end, maybe you would consider creating a Transaction Middleware that would fire any time ORM data gets updated, which could serialize the structure being saved and transmit it to your REST API. This REST API, I assume, is able to accept arbitrary data structures?
You'll probably at least want to use some form of middleware, and maybe a utility module/class to help form the "bridge".
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. ;)