Re: Questions about Django Templating
On 7/3/07, scadink <[EMAIL PROTECTED]> wrote: > 3a. I wish Django would simply assume that my templates are under > app_name/templates. That way, I would have my models and views in the Use the app template loader? http://www.djangoproject.com/documentation/templates_python/#loader-types > 4. I'm not sure about this, but could you put the loads in base.html No, this actually doesn't work. Each template has its own namespace. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Questions about Django Templating
1. Rails people are big on not writing HTML.
<%= link_to 'Apple', :url => 'http://apple.com' %>
http://apple.com;>Apple
The shortcuts just aren't shorter. And, as anyone with a large Rails
app will tell you, once you get users, you frantically go around
removing all of those template helpers. They take FOREVER to parse
and aren't shorter or more readable. It just isn't hard to make HTML
tags so there's no sense in not doing it.
2. This still does bug me - not much though. In one sense, it's good
because it means you have to explicitly pass variables to the template
- much more secure than simply having everything that's an instance
variable get passed.
3a. I wish Django would simply assume that my templates are under
app_name/templates. That way, I would have my models and views in the
app_name folder and all their corresponding templates under that. I'm
guessing the decision was made for loose coupling reasons. this way,
you aren't tied to Django's system. There's also an argument for
templates that might be used in multiple apps and you wouldn't want to
copy it to multiple places.
Really, it just isn't that hard to deal with 2 and 3. And it probably
makes the apps more maintainable in the future. I used to complain
about the manual URLs, but they're amazing. It just isn't that much
code and it takes 15 seconds to write. If you have 100 views (quite
the large site), you've wasted less than half an hour in total.
4. I'm not sure about this, but could you put the loads in base.html
and then have everything extend that base? If you aren't able to call
template tags loaded in the base file, you should be able to. This
might be a bug/feature request.
Django won't be for everyone. Some people won't like the explicit
calls. I find that the more I use Django, the more I see the value in
(most) of its explicitness.
On Jul 2, 12:54 am, rtconner <[EMAIL PROTECTED]> 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/
>
> 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.
>
> 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?
>
> 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. For quick access from text editor, but
> really, both should be in SVN right next to each other.
>
> 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?
>
> Well like I said, none of these items are huge problems, just little
> annoyances I was curious about. Thanks.
>
> -Rob
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Questions about Django Templating
Well I want my subject back, and I'll fight for it if I have to. On Jul 2, 9:21 am, "Bryan L. Fordham" <[EMAIL PROTECTED]> wrote: > oh wow, I don't know how I managed to send that to this list. That was a > reply to a private email, having nothing to do with Django. Obviously. > > Sincere apologies --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Questions about Django Templating
Hey, don't hijack my thread, get your own ;) On Jul 1, 11:45 pm, "nick feng" <[EMAIL PROTECTED]> wrote: > Hi All, > > I plan to build a django-based website for open-sourcing these days, I have > read the django-book. > Since my limited knowledge of web developing(this is my first time to develop > website), I find it's still hard to start now. > Will anybody share your django-based website source code with me ? Thank you > very much! > I promise that your codes is only used for my studying django. > > Best wishes, > Nick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Questions about Django Templating
> Djangonauts? Djangistas? Djangans?
Djangonauts, I like that best!
> {{eh}} ? How would you shorten that?
The helper I use the most is an anchor helper. Its just so nice to
pass in a page and have links generated. I'm sure I'll end up writing
my own helpers too. Table Helpers are nice, I'd say Form helpers are
very needed, but I like newforms a lot, so no problems there. Helpers
do save a lot of time, and you must admit that overall.. HTML sucks as
a language. I like not writing HTML as much as possible.
Ok I'll cross #2 off the list. Flag that as a dumb question.
3 Also gets crossed off, I see that I can just have settings-prod.py,
settings-qa.py, etc and just edit Apache conf to call the one I want.
I'm not hip with using symlinks for this type of thing.
4. add_to_builtins(). Nice. I like that function. Cross 4 off also.
Malcom, lemme just check.. the code would be -
from django.template import add_to_builtins
add_to_builtins('path.to.your.library')
And then you said a good practice might be to create a new application
that only hold custom tags, so when I wanted to use all of the tags, I
just add that app to the project. This still best practice and all?
Well thanks for the quick responses. I'll take more comments if anyone
has anything else to add. Its been a very educational day already :)
On Jul 1, 11:17 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On 7/1/07, rtconner <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hello Djangoes (Djangoers?),
>
> Djangonauts? Djangistas? Djangans?
>
> > 1. First, I've not seen much on webhelpers (aka auto generate an
> > anchor or other html).
>
> I'm not sure I've seen enough of a pattern in ways HTML is used.
> {{eh}} ? How would you shorten that?
>
> {{eh|html:h2}}? The idea in the templates is to keep it simple (that
> is, close to HTML).
>
> > 2. Do I really have to put "return render_to_response('...')" in all
> > of my views?
>
> You could, I suppose, return Context and make a decorator to wrap a
> view's response, something like this:
>
> def render_normal(f, **kwargs):
>c = f(**kwargs):
>app_name_maybe = f.__module__.split('.')[0]
>template_name_maybe = "%s/%s.html" % (app_name_maybe,
> f.func_name)
>return render_to_response(template_name_maybe, context_instance=c)
>
> @render_normal
> def a_view(request, **kwargs):
>return Context({})
>
> ...
>
> Will you next want to avoid creating a context object?
> I don't see a way to avoid the 1 line either way.
>
> If you imagine most of your views would use this @render_normal
> decorator, you could hack your urlresolvers.RegExURLPattern to wrap
> the found callable with the decorator, I suppose, if not already
> guarded by a @render_abnormal decorator.
>
> > 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.
>
> If you don't like that, you can use the app loader, which will load
> templates out of your_app/templates.
>
> But yes, I use TEMPLATE_DIRS in a multi-stage environment.
>
> The answer is symlinks.
>
> /yoursiteorsomething/code/current/templates/
>
> > Does this mean I have to have my deploy scripts edit the path?
>
> Mine doesn't.
>
> > why does Django give the freedom to
> > put templates anywhere?
>
> Again, if you don't want the flexibility, use the app loader.
>
> But yes, it's useful. Consider the hosted environment where an app
> needs to be skinnable. Consider the light-weight mobile view in which
> the base template is loaded from a different location, but all other
> code is the same. Consider the ability to lighten a page by dropping
> in a no-media template when you get slashdotted.
>
> There are more uses.
>
> > 4. Do I really have to always load template tags in the
>
> Here we agree. It might be useful to have a {% load_all %} tag. The
> only danger is that your code might break in mixed environments where
> another app includes a template tag that has the same name as yours.
> Namespaces are good for programmers, but templates don't make them
> visible because they're kind of an abstract concept.
>
> Cheers,
> Jeremy
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Questions about Django Templating
On Mon, 2007-07-02 at 04:54 +, 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
Re: Questions about Django Templating
On 7/1/07, rtconner <[EMAIL PROTECTED]> wrote:
>
> Hello Djangoes (Djangoers?),
Djangonauts? Djangistas? Djangans?
> 1. First, I've not seen much on webhelpers (aka auto generate an
> anchor or other html).
I'm not sure I've seen enough of a pattern in ways HTML is used.
{{eh}} ? How would you shorten that?
{{eh|html:h2}}? The idea in the templates is to keep it simple (that
is, close to HTML).
> 2. Do I really have to put "return render_to_response('...')" in all
> of my views?
You could, I suppose, return Context and make a decorator to wrap a
view's response, something like this:
def render_normal(f, **kwargs):
c = f(**kwargs):
app_name_maybe = f.__module__.split('.')[0]
template_name_maybe = "%s/%s.html" % (app_name_maybe,
f.func_name)
return render_to_response(template_name_maybe, context_instance=c)
@render_normal
def a_view(request, **kwargs):
return Context({})
...
Will you next want to avoid creating a context object?
I don't see a way to avoid the 1 line either way.
If you imagine most of your views would use this @render_normal
decorator, you could hack your urlresolvers.RegExURLPattern to wrap
the found callable with the decorator, I suppose, if not already
guarded by a @render_abnormal decorator.
> 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.
If you don't like that, you can use the app loader, which will load
templates out of your_app/templates.
But yes, I use TEMPLATE_DIRS in a multi-stage environment.
The answer is symlinks.
/yoursiteorsomething/code/current/templates/
> Does this mean I have to have my deploy scripts edit the path?
Mine doesn't.
> why does Django give the freedom to
> put templates anywhere?
Again, if you don't want the flexibility, use the app loader.
But yes, it's useful. Consider the hosted environment where an app
needs to be skinnable. Consider the light-weight mobile view in which
the base template is loaded from a different location, but all other
code is the same. Consider the ability to lighten a page by dropping
in a no-media template when you get slashdotted.
There are more uses.
> 4. Do I really have to always load template tags in the
Here we agree. It might be useful to have a {% load_all %} tag. The
only danger is that your code might break in mixed environments where
another app includes a template tag that has the same name as yours.
Namespaces are good for programmers, but templates don't make them
visible because they're kind of an abstract concept.
Cheers,
Jeremy
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
