On Mon, 2007-07-02 at 04:54 +0000, rtconner wrote:
> Hello Djangoes (Djangoers?),
>
> I've spent a good amount of time familiarizing myself with Django,
> writing my own blog and plugging in the Polls tutorial. I'm very close
> to really liking (almost loving) Django. I've just got a few small
> annoyances I want to ask about. They all, oddly enough, have to do
> with templating.
>
> 1. First, I've not seen much on webhelpers (aka auto generate an
> anchor or other html). Is this the standard way to go, or is there
> another way to go about getting helpers..
> http://code.google.com/p/django-helpers/
"Whatever works for you" is the standard answer. Lots of people have
written little utilities. If they help you out, why not use them? If
they don't, then you're not forced to use them.
> 2. Do I really have to put "return render_to_response('...')" in all
> of my views? I know this is just one line of code, but hear me out.
> Django is all about making project dev go as fast as possible. It
> seems likely that it is an easy thing to have views automatically
> render a template in an assumed location. Yes its just one line of
> code, but its one line I see no reason I have to write. If I don't
> want a template loaded I should explicitly have to say so.
I suspect you're trading very temporary speed for some possibly
non-maintainable software development habits.
That could get very confusing, since views are only one type of function
that is going to be in your source code and a non-trivial code base is
going to have a lot of non-view functions. The developer looking at a
function shouldn't need to think about whether it is going to have the
return value treated in some magic fashion (e.g. which template would be
loaded? How would you use the same view to render to one of multiple
templates?)
If you really want automatic render_to_response calls inserted, it
shouldn't take very long to write a view middleware that does that, I
would guess. Not something that's likely to be added to core, though.
> 3. Going along with the last item .. please please tell me I do not
> really have to put absolute paths in the TEMPLATE _DIRS tuple. 100% of
> my projects get deployed to multiple servers, generally a development
> server, a QA server and a production server. I can in no way ensure
> paths will be the same in all three. How have others handled this?
> Does this mean I have to have my deploy scripts edit the path?
The settings file is just a Python file. You can import things from
other locations, do computations, consult tea-leaves -- whatever you
like to construct the right setting values. Factor out the common pieces
such as the installation prefix into a separate and use that to
construct TEMPLATE_DIRS (via imports). Or use the filename of the
settings file, if you can trust it (which you can't always if it's been
byte-compiled ahead of time).
Using relative paths is not a robust approach, since what are they
relative to? Note, also, that TEMPLATE_DIRS is only used by one of the
default template loaders (the filesystem loader). The application
template loader will effectively use relative paths, since it looks in
app_dir/templates/, so if you have templates that are associated closely
with a particular application, that is where they should go. This is
explained in the documentation for the various template loaders.
> 3a. Note: This is two items where I've wanted a well defined template
> location. Just out of curiosity, why does Django give the freedom to
> put templates anywhere? I can't see this being a tremendously useful
> thing. Always any good project should have the templates nearby the
> views/controllers/models.
Possibly true in the way you work, but that isn't a constraint we would
want to impose on everybody. For example, a site-wide base template
could be written that is used by all apps and then installed into a
directory in TEMPLATE_DIRS and thus not tied to any particular
application. There are quite a lot of uses for templates that can be
loaded by name by apps, but are not tied to those particular
application. The filesystem-based template loader is indespensible in
those cases.
You could, for example, distribute a whole suite of code that only
required the user to have some templates and their own settings file in
order to create something that was easily reskinned by the user without
needing to change the (third-party) source.
> For quick access from text editor, but
> really, both should be in SVN right next to each other.
That assumes only you are developing all the apps you are ever going to
use. Third-party apps can also take advantage of templates your provide,
though (one example).
> 4. Do I really have to always load template tags in the template Is
> there no way to auto load them? It's my guess I'll always have 3-4
> template tags I use regularly. Thats 3-4 extra lines of code per
> template. Is there a way to just force a certain (group of) template
> tags to be loaded for every template in my system?
Search for add_to_builtins() in the archives.
Regards,
Malcolm
--
If it walks out of your refrigerator, LET IT GO!!
http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
