I am building an application that will send an API call and save the resulting information after processing the information in a APIRecord(models.Model) class.
1) Should I build a separate class in such a way that the class does the API call, processes the information (including checking against business rules) and then creates an instance of my APIRecord() class?
Or
2) Should I build a separate class with the appropriate methods for processing, and calling the API, and then in my model, override the APIRecord.save() method to call the separate class's API methods and then save the results?
Or
3) Should I build my model class with the appropriate methods for calling the API and processing the response (including checking for certain values and other business rules)?
I tried # 2 and ran into problems with flexibility (but am still open to suggestion). I'm leaning towards # 1, but I'm not sure of all the negatives yet?
it is design decision.
it depends to your design and programming interests.
i used the combination of three methods you said. if i need to some informations that can be build from other fields then i will create an internal function in model class. if i need other records of database to do something i will create an function outside of model class. and other unusual needs will be computed everywhere i need them.
Related
I am working on a Django application that uses the SimpleGmail package to fetch mails from a Gmail inbox and I need to persist them. Normally I'd have written a model for the class, but given it's an external class, I can't figure out how to cleanly persist it.
I have come across solutions such as making it an attribute of a new model that is persisted or multiple inheritance of the desired class, but none of these seem correct to me.
How do I properly register an external class as a model for Django's persistence?
It is too long to comment. So I will try to write an answer.
One way is is to create a model class with properties which can be mapped from external class with all properties.
Another way would be just import external class in your application and create an instance of this external class. I am sorry, I am not Python guy, so code implementation would not be provided.
When I have a model Car where users can upload a single picture to, I can create a property ImageFile in Django to achieve that. Now I would also like to get the metadata from this file and save them to the database.
Now I'm very unsure where I should place this method a how I should design it. It would be obvious, to have a method like _set_exifdata() or _update_exifdata() that is called every time I set an Image to the model.
Or a method get_exifdata(imagefile) that returns a dict of exifdatas. But should this method be part of the Car model? Actually, I won't need it anywhere else, so it does not make sense to put it in a general helper class. But on the other hand, I would prefer to split methods in "retrieving data" and "setting data", so _update_exif() for example would do both of it in once, and maybe that's OK in design ways, but maybe its not and there is some rules of model design I should know and respect here.
I hope someone can help me with some guidelines for model design (especially for django) and what methods should be part of methods and which should not.
if you using only for the car then you can put that value in the model save method,
which will get call every time whenever you will update the data.
I'm trying to find a way to build a robust report library that I can use with a Django project.
Essentially, what I'm looking for is a way to access a list of functions(reports) that I can allow an end-user to attach to a Django model.
For example, let's say I have an Employee object. Well, I have a module called reports.py that has a growing list of possible reports that take an employee object and output a report, usually in JSON form. There might be number of timecards submitted, number of supervisions created, etc.
I want to be able to link those changing report lists to the Employee object via a FK called (job description), so admins can create custom reports per job description.
What I've tried:
Direct model methods: good for some things, but it requires a programmer to call them in a template or via API to generate some output. Since the available reports are changing, I don't want to hard-code anything and would rather allow the end-user to choose from a list of available reports and attach them to a related model (say a JobDescription).
dir(reports): I could offer up a form where the select values are the results from dir(reports), but then I'd get the names of variables/libraries called in the file, not just a list of available reports
Am I missing something? Is there a way to create a custom class from which I can call all methods available? Where would I even start with that type of architecture?
I really appreciate any sort of input re: the path to take. Really just a 'look in this direction' response would be really appreciated.
What I would do is expand on your dir(reports) idea and create a dynamically loaded module system. Have a folder with .py files containing module classes. Here's an example of how you can dynamically load classes in Python.
Each class would have a static function called getReportName() so you could show something readable to the user, and a member function createReport(self, myModel) which gets the model and does it's magic on it.
And then just show all the possible reports to the user, user selects one and you run the createReport on the selected class.
In the future you might think about having different report folders for different models, and this too should be possible by reflection using model's __name__ attribute.
I'm coding a desktop app with Python and Qt, using PySide. I need to display a tree view in which top-level items are objects of different type than their children. Specifically, a top-level item is a Git repository, whereas its children are directories in the work tree.
For a repository, I want to show its path and currently checked-out branch. For a directory, I just want to show its name.
Right now, I do this by having my QAbstractItemModel descendant use isinstance on the underlying model object (retrieved from internalPointer() method) and decide how to format the resulting string.
I was wondering whether there was a more Pythonic (or just less clunky) way of doing this kind of double dispatch.
What I don't want to do is define a method for this purpose in my model classes for Git repo and work tree file, because I feel this would violate SRP.
Any thoughts or ideas are most welcome. Also, if anyone can think of a less clunky title for this question, let me know ;)
If you were ok with each Model class having a function containing View code, then you could just call those functions. To separate the Model/View code without using isinstance, this sounds like a case for the Visitor pattern, as described in this SO answer, and as used in the ast module.
Basically, each Model class has an accept() method that takes a Visitor object. The accept() method for a repository calls the visit_repository() method of that Visitor object, passing self (which is the Model instance). Similarly, the accept() method for a directory calls the visit_directory() method of that Visitor object, passing self. The visit_repository() or visit_directory() method then has access to the Model instance and knows its type and can show the appropriate view. This separates the View code (in the Visitor object) from the Model code (in the Model class).
*Note: instead of using different function names (visit_repository() vs visit_directory()), you can use multimethods, e.g., this SO answer about multimethods in Python.
In Ruby on Rails, each model entity has a "validate_on_something" hook method, that will be called before the entity is actually persisted to the database. I would like similar functionality in Google App Engine. I am aware that you can do validation on individual Properties by passing arguments to them in their declarations. However, if I wish to do more validation than that, is there some place within the model class declaration within which I can do that?
Also, along the same lines, sometimes a entity needs modification before it is actually persisted to the database. I might need to modify (transform) the entity right before it is actually written to the database. Is there some place in the entity class declaration that would allow me to do so?
I am aware that I can put these transformations/validations outside of the class. Bu this hardly seems like good OO design. It really seems like there should be hook methods that would automatically be called in a model for these sort of needs.
So my question is, what is the most appropriate way to handle the validation and transformation of entities before they are persisted?
The best answer depends on what sort of transformations you need to do. There's no generalized pre-/post- put methods for models, but there are several other options:
As you mentioned, you can pass validation functions to Property class constructors
You can use a custom property class that generates values programmatically, such as this one.
You can modify entities as they are stored at the lowest level using api call hooks.
Are you using any kind of web framework on top of the raw app engine api's? Rails is a very high level framework. Have you looked into Django or any of the other web frameworks? You may find those are closer to rails than raw appengine entities.
Alternatively, if you want something lower level, have a look at this article on
hooks