Re: Revisiting multiline tags

2014-04-03 Thread dude 
More useful example is not ‘very long with’, just a situation with html code 
block, which have in left sir already offset about 60 cols. And when we add 
there any django template tag with params it goes exceed 80 lines (for 
standard). But we can use 120 of course. In real life html tree can be very 
deep. Html tags can be multilines and this is awesome when you want make deep 
tree good looking, but dj templates  not support it.

If django can support multiline it would be great i think and community will 
like this feature immediately.

03 апр. 2014 г., в 21:29, Daniel Ellis <ellis...@gmail.com> написал(а):

> Hmm, that does seem like a great idea!
> 
> 
> On Thu, Apr 3, 2014 at 10:17 AM, dude <y...@helldude.ru> wrote:
> Very good idea i think!
> 
> Many people love format source codes to be beauty. But they can’t because 
> django templates does’t support multiline tags.
> 
> 
> 03 апр. 2014 г., в 21:13, Daniele Procida <dani...@vurt.org> написал(а):
> 
> > On Thu, Apr 3, 2014, Carl <c...@supervacuo.com> wrote:
> >
> >> As someone said earlier in the thread, making Python programmers deal with
> >> long lines seems like some special form of torture ;)
> >
> > My own use case is this:
> >
> > {% with placeholder_width=960 generic_main_width=523 
> > sidebar_image_size="294x196" entity_image_size="445x384" 
> > entity_map_size="445x100" person_map_size="445x100" 
> > sidebar_map_size="296x100" person_image_size="460x460" 
> > person_thumbnail_size="40x40" lightbox_max_dimension=600 
> > plugin_thumbnail_size="75x75" place_image_size="627x418" 
> > place_map_size="294x182" body_heading_level=2 %}
> >
> > Now that's very horrible to read.
> >
> > This would be much nicer:
> >
> > {% with
> >placeholder_width=960
> >generic_main_width=523
> >sidebar_image_size="294x196"
> >entity_image_size="445x384"
> >entity_map_size="445x100"
> >person_map_size="445x100"
> >sidebar_map_size="296x100"
> >person_image_size="460x460"
> >person_thumbnail_size="40x40"
> >lightbox_max_dimension=600
> >plugin_thumbnail_size="75x75"
> >place_image_size="627x418"
> >place_map_size="294x182"
> >body_heading_level=2
> > %}
> >
> > And yes, there is a good reason for wanting to use {% with %} in this way!
> >
> > Daniele
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk.
> > For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



smime.p7s
Description: S/MIME cryptographic signature

Re: Revisiting multiline tags

2014-04-03 Thread dude 
Very good idea i think!

Many people love format source codes to be beauty. But they can’t because 
django templates does’t support multiline tags.


03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):

> On Thu, Apr 3, 2014, Carl  wrote:
> 
>> As someone said earlier in the thread, making Python programmers deal with 
>> long lines seems like some special form of torture ;)
> 
> My own use case is this:
> 
> {% with placeholder_width=960 generic_main_width=523 
> sidebar_image_size="294x196" entity_image_size="445x384" 
> entity_map_size="445x100" person_map_size="445x100" 
> sidebar_map_size="296x100" person_image_size="460x460" 
> person_thumbnail_size="40x40" lightbox_max_dimension=600 
> plugin_thumbnail_size="75x75" place_image_size="627x418" 
> place_map_size="294x182" body_heading_level=2 %}
> 
> Now that's very horrible to read.
> 
> This would be much nicer:
> 
> {% with 
>placeholder_width=960 
>generic_main_width=523 
>sidebar_image_size="294x196" 
>entity_image_size="445x384" 
>entity_map_size="445x100" 
>person_map_size="445x100" 
>sidebar_map_size="296x100" 
>person_image_size="460x460" 
>person_thumbnail_size="40x40" 
>lightbox_max_dimension=600 
>plugin_thumbnail_size="75x75" 
>place_image_size="627x418" 
>place_map_size="294x182" 
>body_heading_level=2 
> %}
> 
> And yes, there is a good reason for wanting to use {% with %} in this way!
> 
> Daniele
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk.
> For more options, visit https://groups.google.com/d/optout.



smime.p7s
Description: S/MIME cryptographic signature

Re: Add support for get_or_none?

2014-03-13 Thread dude 
+1, cool idea!

everybody write a lot of code for try/except block. this feature can help 
shorten code.

14 марта 2014 г., в 4:34, Josh Smeaton  написал(а):

> +1 on get_or_none. It seems to be a pattern that comes up quite a lot in user 
> code, and I know I've had use for it lots of times. Cal, are you thinking of 
> having a loose function get_or_none(qs, args, kwargs), or implementing it 
> directly on the manager? I think it'd make sense to implement on the manager, 
> but the name doesn't "fit" with the other methods available, so perhaps it'd 
> be better to match it up with get_or_create as a simple shortcut.
> 
> Josh
> 
> On Friday, 14 March 2014 04:48:16 UTC+11, Cal Leeming [Simplicity Media Ltd] 
> wrote:
> Sorry yes, you're quite right.
> 
> To be clear - the proposed solution in this thread is to make 
> `.get_or_none()` work exactly the same as `.get()`, with the only exception 
> that None is returned in place of DoesNotExist. All other logic (args, 
> kwargs, exceptions etc) stay exactly the same.
> 
> Cal
> 
> 
> On Thu, Mar 13, 2014 at 5:41 PM, Sean Bleier  wrote:
> I like the implementation referenced in the SO thread, but I would just point 
> out that `.get_or_none()` should accept both *args and **kwargs. `Q` objects 
> can be passed in as arguments to `.get()` and `.filter()`, so it's only 
> natural to allow that for `.get_or_none()`.
> 
> 
> On Thu, Mar 13, 2014 at 10:26 AM, Cal Leeming [Simplicity Media Ltd] 
>  wrote:
> Just read through all those threads/tickets, here's my conclusion.
> 
> #2659 was rejected 8 years ago [1] on the basis that it's a "feature creep", 
> and that it "doesn't offer anything revolutionary". However the same could be 
> said for .first() and .last(), yet those were accepted.
> 
> #11352 was rejected by luke plant 2 years ago [4] based on the suggested 
> implementation in that ticket, which is not the same implementation as what 
> I'm proposing this time round. The design of `get_object_or_none` being added 
> into shortcuts is not a good approach, and was right to be rejected.
> 
> #17546 was rejected 2 years ago [3] on the basis that #2659 and #11352 were 
> rejected, both of which I've addressed above.
> 
> First argument - `first()` and `.last()` have been added, yet the principle 
> behind why they were added is the same as `.get_or_none()`. 
> Second argument - The implementation being suggested in this thread is not 
> the same as what has been suggested in the three rejected tickets.
> Third argument - Thread [2] had mostly positive feedback, but there was no 
> BDFL decision specifically on `get_or_none`.
> 
> If I'm missing something here, please let me know.
> 
> Cal
> 
> [1] https://code.djangoproject.com/ticket/2659
> [2] 
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
> [3] https://code.djangoproject.com/ticket/17546
> [4] https://code.djangoproject.com/ticket/11352
> 
> 
> On Thu, Mar 13, 2014 at 5:05 PM, Shai Berger  wrote:
> On Thursday 13 March 2014 18:45:31 Cal Leeming [Simplicity Media Ltd] wrote:
> > Seems this issue was brought up several years ago, though the thread was
> > later hijacked for other functionality and get_or_none fizzled out.
> > https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q
> >
> > In Django 1.6 there were convenience methods added for .first(), for the
> > same principle of not having to catch an IndexError (or in this case, a
> > DoesNotExist error);
> > https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.model
> > s.query.QuerySet.first
> >
> > This seems to be wanted by several users, as seen here;
> > http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db
> > -or-none-if-nothing-matches
> >
> > Seems to be quite an easy fix, just needs a proper patch.
> >
> > Any thoughts?
> >
> You linked the wrong thread.
> 
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
> 
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/first%28%29/django-developers/iaOIvwzUhx4/x5wKtl7Bh2sJ
> 
> I was (and still am) for a get_or_none() that raises an exception when
> it finds multiple objects, but we were overruled.
> 
> Shai.
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/201403131905.09028.shai%40platonix.com.
> For more options, visit