I need to evaluate the usage of django in implementing a back-office application. It should be able to do CRUD of about 150-200 different object types. As it's a back-office application it will contain a lot of grids/tables.
Many objects can have a bunch of associated properties. There are properties of the following types
simple text
one or several values chosen from a static list
one or several values chosen from a dynamic list with a possibility of search
custom types
These properties are defined in multiple languages.
This application should be highly customizable. All properties and the list of languages should be somehow defined in the model and then the application automatically creates a grid to show/edit them.
Currently we have a java application which displays them like that
Is django a good choice to implement this kind of application?
Do you know good references of django open-source back-office applications of similar type?
Will it be difficult to implement such dynamic property panels using django?
Related
TL;DR: I'd like to have a tool that receives an RESTful schema as input and provides a pyqt dialog/UI as output. Preferably with automatic submission/validation.
I'm working on a PyQt5 application that interacts with a remote Django server using django-rest-framework.
I find that I define most of my models/views/serializers quite quickly as they neatly extend one another. After writing a proper model, generating serializer and view is very easy and I end up with fully functioning server-side fast.
The client/GUI side is a different matter. I have to define the available fields again, their type and order. I have to define widgets for viewing a single object and a list of objects. I have to define edit interfaces and handle permissions.
This all seems like it could use some sort of automation.
Ideally, I could point a smart widget or form to a REST endpoint, and it'll automatically fetch the schema and allowed actions. Automatically create a GUI and the necessary error handling.
Ideally, this shouldn't depend on server side technology, and simply use a schema.
I've googled and couldn't find anything like that. Can someone point me at something similar? Is there a deeper issue with creating such a tool I'm missing?
Thanks!
Edit 1: Rewrote question, including more relevant information
I've been reading a lot on creating django applications that do a single thing and can be easily reused in different projects separately from one another.
Essentially I have an administrative tracking project that manages both projects and placements. Both project management and placement management use similar data and therefor share a model. However both are independent of each other and may have uses in one project but not another. What would be the best way to organize these into different apps?
I've created an image with more details about the specific project in general including a simplified EER diagram, data types, and initial thoughts which can be found here: http://pasteboard.co/1weejc3V.jpg
Edit 2: Another thought...
Would creating a single management app which contains two sub-applications be a good way to do this? I.e. The management app hold the model which consists of the data that both placements and projects use. One sub application contains the functionality for placements, the other contains the functionality for projects. Is there any flaws with this idea, or simply better ways to go around it?
I'm having trouble determining how I should split up the functions of my project into different apps.
Simple example: We have members, and members can have one more more services. Services can be upgraded, downgraded, other services added on, and can also be cancelled. (This is extremely simplfied, were it that simple in reality I'd use a pre-made solution)
My first thought was to make this into a 'member' application, and then a 'services' app that takes care of renewals, up/downgrades and cancellations.
I then thought I should probably make a renewal app, an up/downgrade app, and a cancellation app. But, these apps would all depend on the same table(s) in the DB (members and services). I thought applications were supposed to be independent from one another. Is it ok to make applications that are heavily dependent on other apps models?
Along the same lines, which application should I use to store the models to create the services table if so many apps use it?
I think you first thought was right: you don't get so many benefits of splitting everythin into multiple apps, and on the contrary it could become messy and hard to mantain.
The Django way of doing things depends a lot of the models. Each object is mapped to an entity on the data model. Your apps are mostly organised in relation to such data model. So, if you have an entity (service) that has different pieces, it is better to understand such pieces as parts of the same thing. The other entity (member) should be another one since it is a different thing.
There is no penalty of importing models from different apps. The most important thing is anyway building data model to be consistent.
The point of apps is to allow code which is intended to be reused as an addon by third parties. You probably won't want to split your projects up much, if at all into apps.
In the project there are two data sources: one is project's own database, another is (semi-)legacy web service. The problem is that admin part has to keep them in sync and manage both so that user doesn't have to know they're separate (or, do know, but they do not care).
Here's an example: there's list of languages. Both apps - project and legacy - need to use them. However, they both add their own meaning. For example, project may need active/inactive, and legacy will need language code.
But admin part has to manage everything - language name, active/inactive, language code. When loading, data from both systems has to be merged and presented, and when saved, data has to be updated in both systems.
Thus, what's the best way to represent this separated data (to be used in the admin page)? Notice that I use ASP.NET MVC / NHibernate.
How do I manage legacy data?
Do I connect admin part to legacy web service external interface - where it currently only has GetXXX() methods - and add the missed C[R]UD methods?
Or, do I connect directly to legacy database - which is possible since I do control it.
Where do I do split/merge of data - in the controller/service layer, or in the repository/data layer?
In the controller layer I'll do "var viewmodel = new ViewModel { MyData = ..., LegacyData = ... }; The problem - code cluttered with legacy issues.
In the data layer, I'll do "var model = repository.Get(id)" and model will contain data from both worlds, and when I do "repository.Save(entity)" it will update both data sources - in local db only project specific fields will be stored. The problems: a) possible leaky abstraction b) getting data from web service always while it is only need sometimes and usually for admin part only
a modification, use ICombinedRepository<Language> which will provide additional split/merge. Problems: still need either new model or IWithLegacy<Language, LegacyLanguage>...
Have a single "sync" method; this will remove legacy items not present in the project item list, update those that are present, create legacy items that are missed, etc...
Well, to summarize the main issues:
do I develop CRUD interface on web service or connect directly to its database (which is under my complete control, so that I may even later decide to move that web service part into the main app or make it use the main db)?
do I have separate classes for project's and legacy entities, thus managed separately, or have project's entities have all the legacy fields, managed transparently when saved/loaded?
Anyway, are there any useful tips on managing mostly duplicated data from different sources? What are the best practices?
In the non-admin part, I'd like to completely hide the notion of the legacy data. Which is what I do now, behind the repository interfaces. But for admin part it's not that clear or easy...
What you are describing here seems to warrant the need for an Anti-Corruption Layer. You can find solutions related to this topic here: DDD, Anti Corruption layer, how-to?
When you have two conceptual Bounded Contexts, but you're only using DDD for one of them, the Anti-Corruption layer comes into play. When reading from your data source (performing a get operation [R]), the anti-corruption layer will translate your legacy data into usable objects for your project. When writing to your data source (performing a set operation [CUD]), the anti-corruption layer will translate your DDD objects into objects understood by your legacy code.
Whether or not to use the existing Web Service depends on whether or not you're willing to change existing code. Sticking with DRY practices, you don't want to duplicate what you already have. If you want to keep the Web Service, you can add CUD methods inside the anti-corruption layer without impacting your legacy application.
In the anti-corruption layer, you will want to make use of adapters and facades to bring together separate classes for your DDD project and the legacy application.
The anti-corruption layer is exactly where you handle splitting and merging.
Let me know if you have any questions on this, as it can be a somewhat advanced topic. I'll try to answer as best I can.
Good luck!
I need to create a customized graphical flowchart builder. There are only three classes of connectable components, and two kinds of connectors from which the flowchart is constructed. Each component and connector class, though, needs to have a tailored set of properties associated with the instances of their class.
So I'm looking for a "flowchart builder" builder that lets me configure the types of components, the associated properties, and has all the plumbing already in place to handle drag/drop, resizing, drawing, connecting, load/save, and so on.
Ideally the resulting application would save diagrams in an XML-based format, but anything parsable would be fine.
Dia has the capabilities I'm looking for, however, customizing it for a new type of diagram requires coding up the specifics of the component set. I'm looking for something that on a much shorter timeframe constructs a flowchart application ideally based on the content of component and connector configuration definitions.
If you want to use Dia: It might not be necessary to "code" your components. Maybe you can simply "draw" them:
http://dia-installer.de/howto/create_shape/index.html.en
Such shapes can also be equipped with attributes (you'll have to do some XML-Editing for this):
http://git.gnome.org/browse/dia/tree/doc/custom-shapes#n260
I'm not sure if you were aware of this information.