Yuri Baburov wrote:
> I don't like the point of view that "everyone has his own library",
> because it's too childish. It isn't a solution at all, it's just a
> despair after attempts to find a good enough solution.
> You did a great thing inventing simple and useful ORM, good template
> language, lots of other great stuff.
I think comparing a single template filter to something as big as the ORM is a
bit unfair. A simple filter takes minutes to create, an ORM on the other hand
is not so simple.
> But I'm wondering why you are willing to refuse inventing more right things?
> Remember one of you said that Django is a collection of simple things
> useful in practice?
> What's the price of philosophy if it's stopping from creating
> practically useful things?
Django is your _framework_ for building the useful things. While it may not
contain everything you need, it should certainly provide a way for you to
quickly and easily create the things you need.
> As I see the process, this thread is one where brainstorming is going on.
> After that you, dear core developers, choose the best one.
I say let the brainstorm pour. If the developers see something they like,
they will let the community know. It's pretty clear, though, that the
developers aren't in favor of adding any new syntax, and aren't very fond of
including too-non-programmer-friendly template features.
In many instances, there are ways to move the complexity out of the templates
and into the code. This is a big reason why the template language is so
limiting, as it forces you to put the complexity in the code where it should
be. I have no idea what sort of situation the OP is in since there was not a
lot of information about what's going on around the proposed template filter
code, but maybe instead of:
{{ myModel.getLocalizedNames|pick:userLanguage }}
something less complex could be used:
{{ user.get_localized_name }}
or maybe the view could pass the localized name:
def view(...):
...
name = myModel.getLocalizedNames[userLanguage]
return render_to_response(..., {'name': name})
> We don't need to find ideal solution (cause it might not exist), but
> the one, that is good enough, that is worth adding to Django.
> From my side, I realize that I need such thing in templates.
> From my side, I'd like to see one good enough thing doing this job to
> be included in Django.
> I don't want everyone to create their own solution of this problem.
> In my current work I see up to 10 small projects written by 5 different
> people.
> Do you think it's good to see everyone using their own libraries that
> does such simple thing?
> And what about libraries? Should they also create their own
> templatetag for this?
> I'm begging you, please, please, find a good enough decision to
> include in django core.
You don't _have_ to resort to writing your own library, I just think that most
people end up doing that because it's faster sometimes. For those who need
and use a lot of list operations in templates, it might make sense to join
together and start a django-template-listutils project. You could could take
all the list-related template tags and filters that already exist in Django
and add to it other useful ones. Anyone who needs the special list template
filters can all use and support the same code. Then, the next person who
comes along wanting such a feature won't have to write their own library, they
can use the existing one.
There are several great Django projects out there that started with one or
more people getting together to solve a common problem. Is Django wrong for
not including them in it's codebase? Certainly not, but that does not make
those projects any less useful or any less popular.
Gary
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
