Re: a new template algorithm
On Tue, 2010-08-31 at 10:52 +0700, burc...@gmail.com wrote: > >From the engineering point of view, you did nothing important. In > fact, I think, you did a bad thing to Django: > By increasing the number of incompatible template engines for django, > you fraction the user base of each one, so you decrease the overall > quality of Django solutions, and Django plugins won't be that good (if > they provide any templates). I believe, new template engine should be > made only if it will be much better than old one (i.e, look at Razor > template engine from Microsoft ASP.NET team). > Your work also makes me think you haven't ever heard of Jinja2 and > Mako, both of which already do what you need (python programming in > templates), but have good documentation and have proper way to connect > to Django. > > >From the teenager point of view, look, you created new cool template > engine! Wow! You rock! I think this is put a bit harshly. There is absolutely no problem with people developing alternative template systems. If we bundle several with Django, that would indeed create problems of splitting the community, but allowing people to use alternatives has always been part of the philosophy of Django. This particular template system doesn't fit with our philosophy regarding templating, and also would have *very* big consequences for backwards compatibility. The only real criticism here is that Gabriele's work would be potentially much more useful to other people if it was developed as a standalone project rather than as a patch to Django. Regards, Luke -- "I don't want to achieve immortality through my work. I want to achieve it by not dying." -- Woody Allen Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: a new template algorithm
Hi,
On Aug 31, 5:52 am, "burc...@gmail.com" wrote:
> Why you patched Django instead of making a connector so everyone would
> be able to use your template engine without patching django?
This is how the whole thing started. I started a new job and the one
that was
in charge of the projects before me chose to use django. I had never
used
django before this job.
After a while that I spent time to develop new tags and filters
especially for
new projects, I began to think a way to implement a template engine
that
would let me no more write sort of "plugins" like tags and filters, a
thing that
really bother me.
As all the previews projects were based on django the easier and
faster thing
to do was to start changing the django template.
Now that I'm back working on my business projects (that as you can
understand is the priority) I can think what to do with it.
I can keep it just mine but at first I thought I could have an opinion
from you.
> Looking at your django patch, you also seems to have a typo in your
> Http500 page rewrite:
> -Request Method: {{ request.META.REQUEST_METHOD }}
> -Request URL: {{ request.build_absolute_uri|escape }}
> +Request Method: {{ request.META['RQUEST_METHOD'] }}
> +Request URL: {{ escape(request.build_absolute_uri) }}
Yes thanks, you are right, bad typing.
> From the engineering point of view, you did nothing important. In
> fact, I think, you did a bad thing to Django:
> By increasing the number of incompatible template engines for django,
> you fraction the user base of each one, so you decrease the overall
> quality of Django solutions, and Django plugins won't be that good (if
> they provide any templates). I believe, new template engine should be
> made only if it will be much better than old one (i.e, look at Razor
> template engine from Microsoft ASP.NET team).
I know that but it is a completely different platform/system/
For the "incompatibility" issue I agree with you. To have only
template
engines fully compatible is one of your priorities. I understand and
no
problem with that.
I sent you my work as you could have a look at it and see if it is
interesting and, as I said already many times, if you had find it
interesting it could be used as you wish. ABSOLUTELY in my mind
there was NOT the idea of proposing a changing to the django template
engine.
> Your work also makes me think you haven't ever heard of Jinja2 and
> Mako, both of which already do what you need (python programming in
> templates), but have good documentation and have proper way to connect
> to Django.
In my opinion this is not true. I know Jinja and it works differently.
Just looking at the Variables and Filters part of the documentation
(or
looking at the source if you prefer) you can see that it's different.
For example I didn't want to do something like this (as in Jinjia is
needed):
{% if loop.index is divisibleby 3 %}
> From the teenager point of view, look, you created new cool template
> engine! Wow! You rock!
..no comment about this.
Gabriele
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: a new template algorithm
On Aug 31, 10:20 am, Luke Plant wrote: > On Tue, 2010-08-31 at 10:52 +0700, burc...@gmail.com wrote: I guess Luke is right. I needed something and I implemented it because I couldn't find it done as I wanted by no others. A priority was Python on linux system (so no windows, .NET, ...) and to have it as soon as possible. I asked an opinion from you at first because I based my work on django. The fact that you are not interested is _obviously_ not a problem for me and I understand that. I don't think I have done something special with this thing but just something I needed. What I don't understand is the reply of some of you that pretend to "teach" me something in all the ways thinking that I need "lessons", or supposing that I feel like I found a prime number with at least 1,000,000,000 decimal digits. I don't feel so and I don't think that me sending you something to evaluate should bother you. Either no reply or just "No thanks" would have been enough for me. Anyway Thank you very much to everybody for the replies. Gabriele -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: a new template algorithm
Hello, I guess the most interesting point in this discussion is: > After a while that I spent time to develop new tags and filters > especially for > new projects, I began to think a way to implement a template engine > that > would let me no more write sort of "plugins" like tags and filters, a > thing that > really bother me. The template language is great, it's design decisions are sensible, but writing filters and tags is too complex and time-consuming. Unnecessarily so, as wrappers around creating template tags have shown (e.g. django-templatetag-sugar by Alex Gaynor). If people don't see a documented way of easily bringing features to their templates, they may switch the template engine or, well, start patching the template engine. Bottom line: we need to improve the template tag creation. Cheers Stefan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: a new template algorithm
Yep, and encourage new people to the list to actively contribute! One thing springs to mind, an agile / crystal process 'game', which encourages all parties to contribute ideas within a time frame (usually half an hour to a hour), without prejudice or discouragement. This gets lots of good and bad ideas out into the open, which can then be whittled down. Without the openness, contributors are put off, no ideas flow... Just my 2 pennies (yep, i'm in the UK :-)) On 31 Aug 2010, at 18:24, stefanw wrote: Hello, I guess the most interesting point in this discussion is: After a while that I spent time to develop new tags and filters especially for new projects, I began to think a way to implement a template engine that would let me no more write sort of "plugins" like tags and filters, a thing that really bother me. The template language is great, it's design decisions are sensible, but writing filters and tags is too complex and time-consuming. Unnecessarily so, as wrappers around creating template tags have shown (e.g. django-templatetag-sugar by Alex Gaynor). If people don't see a documented way of easily bringing features to their templates, they may switch the template engine or, well, start patching the template engine. Bottom line: we need to improve the template tag creation. Cheers Stefan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com . To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/django-developers?hl=en . -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: a new template algorithm
On Wed, Sep 1, 2010 at 1:24 AM, stefanw wrote: > Hello, > > I guess the most interesting point in this discussion is: > >> After a while that I spent time to develop new tags and filters >> especially for >> new projects, I began to think a way to implement a template engine >> that >> would let me no more write sort of "plugins" like tags and filters, a >> thing that >> really bother me. > > The template language is great, it's design decisions are sensible, > but writing filters and tags is too complex and time-consuming. > Unnecessarily so, as wrappers around creating template tags have shown > (e.g. django-templatetag-sugar by Alex Gaynor). If people don't see a > documented way of easily bringing features to their templates, they > may switch the template engine or, well, start patching the template > engine. > Bottom line: we need to improve the template tag creation. You won't get any disagreement from me (or, I suspect, anyone on the core team) about this. Where argument emerges is on the best way to solve the problem. There are several projects like Alex's that provide ways to "fix" template tags. There has also been a recent proposal to add a shortcut specifically for the "invoke callable, store as variable in context" pattern. It's worth noting that about a year ago, a similar situation existed for session based-messages. There were half a dozen projects implementing session-based messages as a third-party app, all with a slightly different take on the problem. What changed was that someone (Tobias McNulty) decided he wanted to resolve the situation, and drove the issue forward. He put up a wiki page [1] that gave a thorough summary of the issues and candidates, and got a discussion going on django-dev about the idea. He worked on an integration project to get the best aspects of all the candidates into a single codebase, and within three months, trunk had an implementation of session-based messages. There is a splendid opportunity for someone to do the same thing here. There is clearly a desire to improve the process of writing template tags. There are many candidates on the table, each with a different approach to the problem. What is needed is for someone to drive the discussion to determine the features we (as a community) want in trunk, and prepare the final candidate for merging. [1] http://code.djangoproject.com/wiki/SessionMessages Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Inline template rendering in admin shouldn't silence errors
Steps to reproduce:
1) Specify a custom admin class (say A) which mentions a custom inline
with a custom template, say "a.html"
2) Write anything to "a.html" which will raise TemplateSyntaxError -
ie "{% extends "a.html" %}
3) Observe the change_form for A. Note that you do not see any errors,
but instead the whole inline does not appear at all.
I find this behavior extremely confusing and annoying. Is it just a
bug or is there any reasoning behind that?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
contrib/admin/validation.py
There is a file called "validation.py" which attempts to do validation checking for the admin. Though I realize it might be useful for the beginners (as a basic sanity check) quite often I find it standing in my way and being annoying. The reasons are: 1) Python does not have interfaces. It relies on "duck typing". This file attempts to check whether the class follows the interface, yet in a very naive way. 2) All the check_isseq calls stop you from turning attributes into properties, which can be useful for inheritance purposes 3) sometimes the developer does not want a particular sanity checking. My recent problem was trying to create a widget for a many-to-many field with a custom through table. At the moment it is completely impossible - validation.py will just raise an error, and there is no way to go around it (if you won't count monkey-patching django). Without validation.py I would've been able to specify the widget in the admin settings and just do my own POST-data processing. In my personal opinion this whole file needs either removal, or sufficient relaxation of many constraints. Any thoughts? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
