Spent last couple of days putting someone else's code up onto the one
live test environment server, and, along the way, or during the process,
I came across, or noticed that, while had been under the impression that
they might have more experience in this platform, or as django
developers, they had done a couple of things that I am pretty sure are
specifically not the best way to handle things in this context.
For example - to provide a form of layman's explanation - under django,
you implement your data-processing/rendering code in views, which can be
processed/implemented in a couple of different ways, and, I have ended
up preferring to work with defining classes per URL mapping, including
both get and post code inside said classes,and you then include forms of
URL mappings inside a collection named urlpatterns, in your urls.py file
on a form of per-app basis, where you then separate different portions
of functionality into separate apps under the whole project.
This then allows you to just refer to routing names defined inside the
urlpatterns collection from within django-specific template tags inside
the forms of html template files you combine to generate output content,
so, you don't generally hard-code URL's to parts of your project/site,
but, rather refer to portions of your code using names that can also
then be remapped later on, sort of across-the-board without requiring
multiple corrections.
The same sort of applies to static content, like script files,
stylesheet files and images, etc. since you try to stick to using
sub-folder paths for files that might share file names across different
applications, so that the static function calls inside the templates
will also not coincide/collide with each other, etc.
This then also relates to the fact that, generally, when putting
something like a django application up on the server, you might not want
to then have client-browsers referring to the application via URL's
necessarily including the port numbers, etc. that your django
application is offering interaction via, so, you might want to use
something like nginx http server to redirect input/output to your
functionality via what it refers to as upstreaming, or wsgi remapping,
but anyway.
In other words, it seemed to me now that these external developers had
more experience with just working on this in their own development
environment, and, not as much in terms of then putting results in place
live, etc., which is more or less where I myself am in terms of still
trying to get 100% comfortable with this side of the development process
in this platform, but anyway.
Either way, this is just what feels like a nice bit of confirmation that
might have been handling the process of getting comfortable with this
newish platform maybe better than had thought I was - suppose that's
part of switching over from one form of web development that you've been
focusing on for over 10 years into another form of web development in
one move - going to keep on wondering what else you should consider/look
into.
But then, some of us have always thought any good developer will always
keep on wondering what else they should pay attention to/consider/do
more research on...LOL!
Jacob Kruger
+2782 413 4791
"Resistance is futile...but, acceptance is versatile..."
** To leave the list, click on the immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** program-l-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to
** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
