Re: suggestion: Don't make the tag "url" dirty in Django1.5
That example is incorrect.
{% url app_views.client %}
will not change to
{% "url app_views.client" %}
it will change to
{% url "app_views.client" %}
which, as you can see, enables passing the view from something other than a
literal string.
On 27 March 2012 09:22, gs412 wrote:
> In Django1.5
>
> {% url app_views.client %}
>
> will change to
>
>> {% "url app_views.client" %}
>
>
> I think it is a stupid idea
> Why so many people use django? becouse of 'DRY', but now django become
> more and more 'dirty'
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/-kXfyDKv3-MJ.
> 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-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.
Re: [GSoC 2012] Schema Alteration API proposal
On 18 March 2012 23:33, Russell Keith-Magee wrote: > > 2. An inspection tool that generates the appropriate python code after > >inspecting models and current state of database. > > The current consensus is that this shouldn't be Django's domain -- at > least, not in the first instance. It might be appropriate to expose an API > to extract the current model state in a Pythonic form, but a fully-fledged, > user accessible "tool". Is there a writeup anywhere of why this is the consensus? AFAICT it looks like Django already provides half of this in the form of DatabaseIntrospection, that e.g. South actually uses, which generates a model class from the current state of the database. Doing the diff as well doesn't seem like much of a stretch, and might make it more likely for third party custom fields to be made migrateable, if the interface for doing so is in Django core. - ojno -- 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.
Re: Class based views: A standard hook for http-method-independent code
That's not the case - get_context_data, get_queryset, are examples of hooks like this preprocess one, not places where more would be added. I'm not sure if there's a better analogy. Overriding the dispatch method would be the correct solution if you wanted to behave the same towards all methods, but seems a bit heavy for factoring out validation or common code between methods where you still want your get/post/etc to be called (or not, as the case may be.) - ojno On 2 March 2012 15:22, Andre Terra wrote: > Then that would also be the case for many other methods in generic > class-based views, like get_context_data, get_queryset, etc.. I hate > boilerplate code as much as the next guy, but I'm not sure I follow why > this single method would get a special hook. Correct me if I'm wrong, but > special cases aren't special enough to break the rules. > > > Cheers, > AT > > > On Fri, Mar 2, 2012 at 11:53 AM, Jonathan French > wrote: > >> That's true, but I agree it seems a useful enough hook to make it a hook, >> rather than needing to do it yourself like that. I would vote for it being >> called 'preprocess', to make it clear that it's both optional and run >> before the method-specific function. >> >> - ojno >> >> >> On 2 March 2012 13:40, Michael van Tellingen < >> michaelvantellin...@gmail.com> wrote: >> >>> Hi, >>> >>> This should already be quite easy to implement, do something like: >>> >>>def dispatch(self, *args, **kwargs): >>># Some code >>>return super(YourView, self).dispatch(*args, **kwargs) >>> >>> Regards, >>> Michael >>> >>> >>> On Fri, Mar 2, 2012 at 11:58, Charlie "meshy" Denton >>> wrote: >>> > I would like to see something like this too. I my suggestion is >>> > here: https://gist.github.com/1957251 >>> > >>> > This method has two advantages: >>> > 1. You can modify the request, args, and kwargs before they get saved >>> to the >>> > view. >>> > 2. You can execute code after request, args, and kwargs are saved but >>> before >>> > the dispatch handler is called. >>> > 3. You can save extra variables to self as required >>> > >>> > I expect 2 is probably the most common use case. >>> > >>> > Meshy. >>> > >>> > >>> > >>> > On Thursday, March 1, 2012 6:38:08 PM UTC, Marc Tamlyn wrote: >>> >> >>> >> Hi all, >>> >> >>> >> Apologies if this has been raised before. I've had a look around and >>> can't >>> >> find a good way of doing this with the current code. >>> >> >>> >> I regularly have views which rely on some custom code which runs some >>> >> sanity checking on the request and is independent of method. As an >>> example, >>> >> consider a view which creates an object related to a parent. This is >>> easily >>> >> achievable by overriding the form_valid method of CreateView and >>> excluding >>> >> the foreign key from the form. However, the view should return a 404 >>> if the >>> >> related object specified by the url does not exist. Written as a non >>> class >>> >> based view, the natural flow is to try to load the parent object from >>> the >>> >> database, handle it as necessary, and then split paths depending on >>> whether >>> >> we have a get or post. It is currently very difficult to emulate this >>> >> without duplication of some sort. >>> >> >>> >> My proposal is that we add a process_request (or similar name) method >>> >> which is called by the dispatch method immediately before the method >>> handler >>> >> is called. (i.e. here). This would then allow pre-processing and >>> sanity >>> >> checking of the request object, using the args, kwargs and request >>> that have >>> >> been saved on the class, before delegating off the the respective >>> views. The >>> >> method should return None or an HttpResponse subclass. If it returns >>> >> something, then we return that directly from the dispatch method. >>> >> >>> >> >>> >> I can supply some code (my proposal is pretty simple I think) but I >>> >> thought I'
Re: Class based views: A standard hook for http-method-independent code
That's true, but I agree it seems a useful enough hook to make it a hook, rather than needing to do it yourself like that. I would vote for it being called 'preprocess', to make it clear that it's both optional and run before the method-specific function. - ojno On 2 March 2012 13:40, Michael van Tellingen wrote: > Hi, > > This should already be quite easy to implement, do something like: > >def dispatch(self, *args, **kwargs): ># Some code >return super(YourView, self).dispatch(*args, **kwargs) > > Regards, > Michael > > > On Fri, Mar 2, 2012 at 11:58, Charlie "meshy" Denton > wrote: > > I would like to see something like this too. I my suggestion is > > here: https://gist.github.com/1957251 > > > > This method has two advantages: > > 1. You can modify the request, args, and kwargs before they get saved to > the > > view. > > 2. You can execute code after request, args, and kwargs are saved but > before > > the dispatch handler is called. > > 3. You can save extra variables to self as required > > > > I expect 2 is probably the most common use case. > > > > Meshy. > > > > > > > > On Thursday, March 1, 2012 6:38:08 PM UTC, Marc Tamlyn wrote: > >> > >> Hi all, > >> > >> Apologies if this has been raised before. I've had a look around and > can't > >> find a good way of doing this with the current code. > >> > >> I regularly have views which rely on some custom code which runs some > >> sanity checking on the request and is independent of method. As an > example, > >> consider a view which creates an object related to a parent. This is > easily > >> achievable by overriding the form_valid method of CreateView and > excluding > >> the foreign key from the form. However, the view should return a 404 if > the > >> related object specified by the url does not exist. Written as a non > class > >> based view, the natural flow is to try to load the parent object from > the > >> database, handle it as necessary, and then split paths depending on > whether > >> we have a get or post. It is currently very difficult to emulate this > >> without duplication of some sort. > >> > >> My proposal is that we add a process_request (or similar name) method > >> which is called by the dispatch method immediately before the method > handler > >> is called. (i.e. here). This would then allow pre-processing and sanity > >> checking of the request object, using the args, kwargs and request that > have > >> been saved on the class, before delegating off the the respective > views. The > >> method should return None or an HttpResponse subclass. If it returns > >> something, then we return that directly from the dispatch method. > >> > >> > >> I can supply some code (my proposal is pretty simple I think) but I > >> thought I'd open it up for discussion first. > >> > >> Marc Tamlyn > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/django-developers/-/z63TmT57twQJ. > > > > 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-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-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.
Re: make the File Storage API works with a file-like object instead of the Django File object.
You can create a Django file object from any file-like object just by passing it to the constructor. django.core.files.File(my_file_like_object) This is basically what all the storage backends do where there is an existing file object from whatever source, and what you have to do if you want to save an existing file to a FileField. - ojno On 28 February 2012 22:28, Michael wrote: > Hi, > > The File Storage API only works with the Django File object (https:// > docs.djangoproject.com/en/1.3/ref/files/storage/ ; > https://docs.djangoproject.com/en/1.3/ref/files/file/). > Wouldn't it be a good idea to make a Django file-like object instead > and make the Storage API works with it ? > That way we could use the current Django File object when it is real > files but also use a "remote" file object like the urllib2.urlopen > returns. > > What do you think ? > > Best, > Michael > > -- > 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-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.
Re: Newline stripping in templates: the dnl way
Let me make sure I've got this right --- The situation being discussed is
not where whitespace is insignificant and can be stripped, but where
whitespace is important and you want to control the exact amount of it,
e.g. plain text emails. In this case, just using stripwhitespace is not
enough. Right?
On 25 February 2012 04:27, Tai Lee wrote:
> What's better about {% for x in y -%} or {^ for x in y ^} over {%
> stripwhitespace on %} at the top of your template, followed by {% for
> x in y %}? I think the latter is far more readable.
>
--
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.
Re: Revisiting multiline tags
On 24 February 2012 17:16, Alex Gaynor wrote: > > > On Fri, Feb 24, 2012 at 12:06 PM, h3 wrote: > >> > If you'd like to make an argument as to *why* it's useful, that's >> useful, but we don't take polls. >> >> I think the argument as to why it's useful as been made quite >> extensively. >> >> On the flip side, beside the ivory tower philosophical stance, I did >> not see much >> compelling argument as to *why* this is a bad idea. >> >> > Django is nothing other than ivory tower philosophies (and I really hate > this "ivory tower" insult, as if it's a bad thing to be principled and > philosophically sound) applied to APIs. If it violates the philosophy, it > shouldn't go into an API. > > >> If you think it makes your templates look ugly, well just don't use >> it. You'd still have the choice. >> >> > No. If it's an API, it doesn't need to be used by me in order to poison > my experience with Django. > *How* does it "poison your experience"? Just the knowledge that someone, somewhere isn't writing code to your linebreak style? > >> Meanwhile some other people think it would make their templates more >> readable, but >> unfortunately they don't have the luxury to choose because an >> architect think it's ugly. >> >> At this point I think it's worth mentioning that it's a not a beauty >> contest. And even if it was, >> I don't see the beauty in lines of code that are 10 feet long. >> >> > In another thread someone had an example of a multi-line tag, and I > actually commented to my computer on how ugly I found it. Beauty may be in > the eyes of the beholder, but the reason we have BDFLs is to keep those > decisions consistent. Glyph Lefkowitz's keynote from DjangoCon this year > really drives this home. > What is the no-linebreak behaviour consistent with? > > >> >> On Feb 24, 10:15 am, Daniel Moisset wrote: >> > On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor >> wrote: >> > >> > > Folks, you seem to have missed Russell's point. Even if 100 people >> +1 this, >> > > it's meaningless. That's a tiny fraction of this mailing list's >> readership, >> > > much less of the Django community at large. Django is the way it is >> > > because, first and foremost, of taste. If you'd like to make an >> argument as >> > > to *why* it's useful, that's useful, but we don't take polls. >> > >> > It's useful because it helps some templaets in some cases be more >> readable >> >> -- >> 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. >> >> > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > -- > 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-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.
Re: Newline stripping in templates: the dnl way
Jinja implements whitespace control by putting a minus sign after/before
the % in a tag - http://jinja.pocoo.org/docs/templates/#whitespace-control -
I haven't tried it myself, but it looks like {% tag -%} is equivalent to
your {% tag %}{# .
On 24 February 2012 17:37, Tobia wrote:
> Tai Lee wrote:
> > I don't think adding {# to the end of lines is easy to understand at a
> > glance, it doesn't even convey a hint of meaning like "dnl" does
>
> I beg to differ. {# is already recognized by template authors as
> meaning "start of comment", and they know (or should know) that it
> cannot extend through more than one line. Therefore I'd think it
> intuitive that it will "eat" till the end of the line and not beyond.
>
> Look:
>
> Here are your subscriptions:
> {% for thing in things %}{#
> - {{ thing.name }}
> You added it on {{ thing.date }}
> {% endfor %}{#
> you can manage your subscriptions...
>
> Tom Evans wrote:
> > I'd be strongly -1 on anything that makes template language look more
> > like m4!
>
> I'll tell you, m4 can be quite addictive once you grasp the basics! :)
>
> > This could be addressed by having a different open/close tag for tags
> > which chomp the preceeding/next character if it is a newline. Eg:
> > {^ for item in folder ^}
>
> I don't think adding new reserved characters would make the language
> simpler for template authors, nor for the the template parser, nor for
> the sake of backwards compatibility. {# is already part of it.
>
> But I can see the need to chomp whitespace before a template tag, as
> well as the newline after it.
>
> Martin J. Laubach wrote:
> > For this (avoiding newlines) the currently discussed multiline tags
> > would work pretty well too without adding more cruft to the template
> >language:
> >
> > foo bar {#
> > #}baz
>
> If this can be accomplished without massive performance penalties, I
> agree with you.
>
> Maybe {# #} could be made multiline at first, with special code, while
> waiting for a proper implementation of generic multiline tags. This
> would certainly be more forward-compatible than my proposal above
> and it would solve more whitespace problems, if not all.
>
> Tobia
>
> --
> 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-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.
Re: Revisiting multiline tags
Since we're consensus building or whatever the fancy term is, another +1.
Mainly for comments, since {# #} is far, far more readable than {% comment
%}{% endcomment %} even with syntax highlighting, but also for other tags
too, particularly long i18n ones -- or even relatively short ones where you
have complex nested HTML and have indented yourself against a wall, but are
coding to a style which insists on a hard right margin, no exceptions.
Soft word wrapping isn't the best option, since you can produce a much
clearer result through manual line breaks and alignment than your editor
can through wrapping at the last word on the line.
This is a tiny change which would make many people's lives easier. I'm very
surprised at Django, with the whole "batteries included" thing,
deliberately withholding a feature for aesthetic reasons. When did you turn
into GNOME? ;-) Please reconsider.
- ojno
On 24 February 2012 10:29, Ivan Kharlamov wrote:
> On 02/24/2012 01:29 PM, Chris Northwood wrote:
> > A +1 from me too, I've really felt the pain on this when doing i18n
> > templates, I understand the aesthetics, but the aesthetics of
> > obscenely long tags is also bad imo...
> >
> > On 24 February 2012 09:23, Shawn Milochik wrote:
> >> On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers
> wrote:
> >>>
> >>> In the interest of making the wider community opinion heard, I too am
> +1 on this, my feeling is exactly the same as Stephen.
> >>>
> >>> --
> >>
> >> +1
> >>
> >> I understand that a BDFL has spoken and this change isn't going to
> >> happen. I hate to add to the noise, but since the argument from
> >> popularity fallacy has been invoked, I feel the need to point out that
> >> many of us didn't bother to weigh in because we didn't choose to add
> >> to the noise. Especially after the case was so well-made by others --
> >> it didn't seem necessary.
> >>
> >> Shawn
> >>
> >> --
> >> 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.
> >>
> >
>
> +1
>
> If you are against truly multiline tags, consider supporting a line
> continuation character sequence (something like backslash in most of the
> programming languages) inside tags, which a poor template author can use
> as a last resort to make his code readable.
>
> In the docs, discourage people from going multiline. Highlight that it
> is the last thing to do (like PEP does).
>
> --
> 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-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.
