Calling an external script from Django admin interface? - python

I have a Django admin interface that is used almost solely as a gui form for making changes to a single postgresql table. There's also a Python script that's currently run manually from the command line whenever a change is made to the database, & I'd like to hook that up so it runs whenever someone hits "save" after making a change to a row of the table via the admin interface. If this was an entry in views.py, it looks like I'd import the script as a module and run its main function from the view (ie, Can Django use "external" python scripts linked to other libraries (NumPy, RPy2...)). I'm not sure, however, how to do this in the admin interface.
How is admin.py similar/different to a regular entry in views.py?
Where do I put the import/call to the external script - somewhere in the model, somewhere in admin.py?
I'm familiar with Python, but am fairly new to (& somewhat mystified by) "web stuff" (ie, frameworks like Django), & I'm not even sure if I'm asking this question very clearly, because I'm still a little fuzzy on the view/model concept ...
Edit: Turns out I had, in fact, found the solution by reading the documentation/tutorial, but assumed there was a difference with admin stuff. As Keith mentioned in the comments, I'm now running into permissions issues, but I guess that's a separate problem. So thanks, & maybe I'll stop second guessing myself ...

Generally, things you want to happen at 'save' time are either
Part of the model.
If so, you override the model's save method: http://docs.djangoproject.com/en/1.3/ref/models/instances/#saving-objects
You can do anything in that save method.
Part of the view function.
If so, you either extend the admin interface (not so easy), or you write your own.

One thing you might consider is defining the save_model method in your ModelAdmin. This will get executed when someone saves from the admin (but not when someone does a save outside of the admin). This approach might depend on what your requirements are, but should give you the necessary hook when doing the save from the admin.
In admin.py
class MyModelAdmin(admin.ModelAdmin):
model = models.MyModel
def save_model(self, request, obj, form, change):
# you can put custom code in here
obj.save()

Related

Edit FileField file contents from Django Admin

I have a situation where I have python scripts that are stored as files that need to be modified from the Admin panel. Currently some of my models can have scripts attached to them:
class Action(PolymorphicModel):
title = models.CharField(max_length=100)
text = BBCodeField('text', blank=True)
action_script = models.FileField(upload_to='action_scripts')
In my Admin panel I can upload a file but I have been asked to make this file editable in-place if the user has the right permissions. I've searched all over for an idiomatic way to do this, and so far I've come up with the following ideas:
Override the FileField widget to include an text edit box and save button. This seems very brute forced
Replace models.FileField with subclass of models.TextField, implement read from file, save to file, but then I lose the upload widget and data still gets stored in DB. This seems dirty because in the database all I'm storing is a filename. FileField feels like the right field type here.
Write a custom ModelForm that includes forms.TextField. Handle save to file using the save method. I'm not sure how to accomplish this because I would have to generate a filename on the fly and I don't have a primary key yet. Maybe some sort of UUID?
I'm leaning against door number 3 right now, but I've only been using Django for a week, so I'm not sure this is the right way to go, or even how to do it. Also I would need to have a custom ModelForm for every model that inherits from Action, which violates DRY.
Further complications:
Not all Actions need scripts. If the textbox is empty, the FileField can just become Null.
Action is subclassed into a handful of derived classes. The editing functionality should extend to each model's Admin panel in a scalable way, like the other fields.
This question seems generic enough that its solution would be useful for those wishing to edit HTML or CSS from the admin, etc, the same as WordPress does. Searching along those lines unfortunately brings up results to do with skinning the admin, which I'm not after. In my situation I'm trying to avoid storing python code in the database for security reasons. The Admin interface is not going to be exposed to the end users so in theory it should be safe, and I get the benefit of caching, compilation and locality (less hits to the DB).
Many thanks.

Can we make changes to the django packages

Is it okay to make changes to the django packages?
For instance in my project I have a folder lib/python2.7/site-packages/reversion/
And in here I want to add one method inside of models.py
Is this correct?
Initially I wanted to edit django's admin history page. In some models history change messages are shown in unicode format, but I need it to be string readable. In models.py I used eval function to transfer unicode to python list.
No, this is not a good practice.
In general there is other way to edit the default feature (inheritance, write your own page, etc...).
This is because if you modify the django package this becomes difficult to maintain and update.
But if it is a small project you can try to edit django package.

Django: generate python code from command line

Is here a way to write a Django command to generate code automatically?
In my case: every time I create a new model I must create the following stuff too:
Create Administration classes in admin.py
Create service functions related to this model.
Create a factory using FactoryBoy.
Create test classes.
It would be nice if there was a command that generates this stuff automatically. Not everything, of course, but just the basic, the definition.
Is there something like this today in Django? Or is there a way I can write Django commands to generate code?
I have not personally used it yet but you could try to use the third-party package
Django baker Django Baker that offers that functionality
Django Baker wants to help you get your projects up and running
quickly. Given one or more app names, s/he will automatically generate
views, forms, urls, admin, and templates for all of the models in the
models.py file. All files are pep-8 compliant (with exception to the
maximum line length rule, which I don't agree with).
Once you add a single urlpattern to your project's URLconf, you'll
have a working list view, detail view, create view, update view, and
delete view for each model in your app.
Optionally you may specify which models in an app to bake if you'd
rather not generate files for all of them.
Try django commands and jinja2 templates.
With the execution of custom defined command, set of file templates can be updated with appropriate content and copied to respective folders as per need.

business logic in Django

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.

Django app initalization code (like connecting to signals)

I need a place to run an initialization code that is application specific (like connecting to signals).
When I put the code to __init__.py module of an application I've ended up with a circular import of the models.
Is there a way to fire a function when the framework is setup and before any request is executed?
I use quite old version of django 96.6, but I'm also interested in the solutions for the current version.
Regarding the duplication of other questions:
Here is how the question differ from the duplicates suggested by S.Lott in comments:
Correct place to put extra startup code in django?
Django need to be fully initialized when the function is ran. So code in manage.py won't work.
Where should I place the one-time operation operation in the Django framework?
The function initialize the connection between my applications. So the code must be ran in each thread that will actually handle the requests.
Comments to current solutions:
I can't use urls as most of my apps don't have any urls exposed. They just listen to signals and store additional information in the database.
Signals, specifically, are recommended to be put in the models.py of your app.
Try models.py or urls.py and let us know if you have any luck.
The best place for stuff like this... anywhere, just import it in your urls.py file (for obvious reasons urls are loading before any requests).
If you don't provide urls, then you really need to put it in models.py, that's just the way it is.
Now, on to your problems: You want to define it in its own module, great, do that. To avoid a circular import, use django.db.models.get_model to return the model dynamically for you. You can provide an initialisation function for your signals module to import the relevant model and connect the relevant signals. This function would then be called at the end of models.py, being run only ever once and after your model is initialised.
There's still a chance that this wont work (if the models aren't yet ready when you set it up), but give it a try and let us know.
For me, the following works:
In init.py:
from . import models
from . import signals
signals.py imports from models, but not vice versa. signals.py contains module code that is run immediately when it is imported and is thus run when the django server starts.

Categories