I second moving some (or most) of the functionality to models.py. For
instance, calculating the SHA value should be done as part of the model's
save() function, not done in the view.

Convention dictates that the only code that is placed in the view itself
should be logic related to prepping the templates for rendering/displaying
things, such as setting variables in the template context.

Any operations related to 'business logic' such as data manipulation (ie
save behavior) as it relates to specific objects should be handled by the
object/model itself. Ideally, the model instance should be smart enough to
save itself (or perform some other action) on its own without any input
from the view, assuming the necessary values for the operation are provided
from some other source.

Obviously this is only a convention and not a rule, but it will likely
serve you better in the long run. In general, views tend to be quite short.
My class-based views just have a couple of class-level attributes set, if
anything at all (although they rely heavily on inherited behavior from
parent class views, which are much more complicated).

-James
On Jan 19, 2015 12:11 AM, "Daniel França" <daniel.fra...@gmail.com> wrote:

> If the operations are model related, why don't move some of those
> functions to models.py.
> On Mon 19 Jan 2015 at 08:46 Mike Dewhirst <mi...@dewhirst.com.au> wrote:
>
>> On 19/01/2015 6:28 PM, Cheng Guo wrote:
>> > Hello,
>> >
>> > I am new to Django and I have run into an issue with views.py.  I
>> > understand that there is a function behind each view. For a view that I
>> > am currently writing, it accepts a file upload from user and stores the
>> > file on the server. To do that, I need to:
>> >
>> > 1. check the file extension is correct
>> > 2. generate a SHA-1 id for the file based on its content
>> > 3. write the file to disk
>> > 4. save information about the file to database
>> >
>> > (oh, I also created two global variables as well)
>> >
>> > As you can see, if more features are added, the list goes on. It makes
>> > this function very long. As the number of views grow, the views.py file
>> > will become bloated. I wonder what would be the ideal way to deal with
>> this?
>> >
>> > Something that I can think of but not sure if it is correct:
>> >
>> > - divide the long function up into smaller functions
>> > - store these smaller functions in a different .py file
>>
>> Absolutely correct. But first create a views directory (complete with
>> __init__.py file therein) to completely replace your views.py file.
>>
>> Then any number of files can contain your views ...
>>
>> from app.views.this import That
>>
>> ... where this.py has a class That
>>
>>
>> >
>> > Let me know your approach, thanks!
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Django users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an email to django-users+unsubscr...@googlegroups.com
>> > <mailto:django-users+unsubscr...@googlegroups.com>.
>> > To post to this group, send email to django-users@googlegroups.com
>> > <mailto:django-users@googlegroups.com>.
>> > Visit this group at http://groups.google.com/group/django-users.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/django-users/bf9f6ff3-
>> a35a-4f00-8537-c6fd66d07f8d%40googlegroups.com
>> > <https://groups.google.com/d/msgid/django-users/bf9f6ff3-
>> a35a-4f00-8537-c6fd66d07f8d%40googlegroups.com?utm_medium=
>> email&utm_source=footer>.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-users/54BCB642.8040201%40dewhirst.com.au.
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CACPst9JZnMGK8vS00G1oqwEVt9qbf3TnTsdoJCwdy-mN02qEPw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-users/CACPst9JZnMGK8vS00G1oqwEVt9qbf3TnTsdoJCwdy-mN02qEPw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciWwM%3DgBfNrqksKDED8k7Wy%2BHKu1Q1kiPu%2BUZOpg7D5dXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to