I'm building a personal website that I need to apply modularity to it for purpose of learning. What it means is that there is a model that contains x number of classes with variations, as an example a button is a module that you can modify as much depending on provided attributes. I also have a pages model that need to select any of created modules and render it. I can't find any documentation of how to access multiple classes from one field to reference to.
Model structure is as below:
Modules, contains module A and module B
Pages should be able to select any of module A and order its structure.
Please let me know if not clear, this is the simplest form I could describe. Am I confusing this with meta classes? How one to achieve what I'm trying to achieve?
I ended up using Proxy models but will also try polymorphic approach. This is exactly what is designed to do, inherit models from a parent model in both one to many and many to many relationships.
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
I'd like to know where to put code that doesn't belong to a view, I mean, the logic.
I've been reading a few similar posts, but couldn't arrive to a conclusion.
What I could understand is:
A View is like a controller, and lot of logic should not put in the controller.
Models should not have a lot of logic either.
So where is all the logic based stuff supposed to be?
I'm coming from Groovy/Grails and for example if we need to access the DB or if we have a complex logic, we use services, and then those services are injected into the controllers.
Is it a good practice to have .py files containing things other than Views and Models in Django?
PS: I've read that some people use a services.py, but then other people say this is a bad practice, so I'm a little confused...
I don't know why you say
we can't put a lot of logic in the controller, and we cannot have the models with a lot of logic either
You can certainly put logic in either of those places. It depends to a great extent what that logic is: if it's specifically related to a single model class, it should go in the model. If however it's more related to a specific page, it can go in a view.
Alternatively, if it's more general logic that's used in multiple views, you could put it in a separate utility module. Or, you could use class-based views with a superclass that defines the logic, and subclasses which inherit from it.
Having a java background I can relate with this question.
I have been working on python for quite some time. Even though I do my best to treat Java as Java and Python as Python, some times I mix them both so that I can get a good deal out of both.
In short
Put all model related stuff in models app, it could be from simply models definition to custom save , pre save hooks .....
Put any request/ response related stuff in views, and some logic like verifying Jon schema, validation request body ... handling exceptions and so on ....
Put your business logic in separate folder/ app or module per views directory/ app. Meaning have separate middle module between your models and views.
There isn't strict rule to organise your code as long as you are consistent.
Project : Ci
Models: ci/model/device.py
Views: ci/views/list_device.py
Business logic:
(1) ci/business_logic/discover_device.py
Or
(2) ci/views/discover_device.py
Short answer: Django is more of a MTV or MVT (Model / Template / View), as described in the official FAQ : https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names
The business logic has its place in your views, but nothing prevents you from putting it inside a "utils.py", "services.py" or anything to your liking.
If the functionality fits well as a method of some model instance, put it there. After all, models are just classes.
Otherwise, just write a Python module (some .py file) and put the code there, just like in any other Python library.
Don't put it in the views. Views should be the only part of your code that is aware of HTTP, and they should stay as small as possible.
Please help me how to solve following task in "pythonic" way:
There are several model classes, which are mapped to the DB with the help of SQLAlchemy.
There is a Flask view, which handles the "POST" request.
The business logic of this method contains complex logic which includes:
Getting input parameters from input JSON
Validation
Creation of several different models and the saving to database.
Is it a good idea to leave this logic in the "View"? Or it would be much better to separate this this logic into different modules or classes, for instance by introducing business logic class?
If you need to unit test the code separate from the View then you should defiantly separate it into another module or class.
As there seems to be three parts to your business logic then I would say starting by splitting the view into three functions of a module seems a good place to start.
excuse me in advance if this is not the right title for the problem but here it is:
You have application that works with pre defined model. What happens if you want to
use this application one more time in your project but pointing to different model (same structure but differen name).
For example - you have a "News" application that is fully working but you want to have also and articles the do the same job but you want it in different table.
I'm pretty sure that copying the whole application and renaming the Model isn`t the "pythonic" way so if someone knows how this is done please share your knowledge.
thanks in advance,
Ilian Iliev
This is what abstract models are for. Define once, and all children will acquire the fields in the abstract model, plus be able to define additional fields.