> Djangonauts? Djangistas? Djangans?
Djangonauts, I like that best!
> <h2>{{eh}}</h2> ? 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.
> <h2>{{eh}}</h2> ? 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
-~----------~----~----~----~------~----~------~--~---
