Re: Ticket #5025 - truncate filter, why hasn't it been accepted?
flo...@gmail.com wrote:
> I have a custom filter that does just this that I use in virtually
> every single Django project I use. It's such a common pattern that it
> seems almost silly not to have it included in core. It's also small
> enough that it won't add much in the way of maintenance. Also, there
> already exists a truncate_words, which has nice symmetry with the
> proposed name. Finally, as has been said before, it's something that
> new users intuitively expect to find, so let's not disappoint them.
>
> I quite strongly feel that slice is not a suitable alternative,
> because 1) adding the ellipses requires a non-trivial amount of
> additional template logic (and this logic need be repeated every time
> ellipses are wanted) and 2) it makes the actual markup of the template
> less semantically relevant.
>
> Count me as a big +1 for including this.
>
> Thanks,
> Eric Florenzano
>
>
Agree +1 on including it into Django.
(both truncate and truncate_html)
I'm having similar experiences as Eric, think 7 out of 10 sites
eventually use it in one way or another. To give some quick
examples; filenames, links, fullnames with hover, limiting user
generated content, csv exports, etc.
Sometimes in conjunction with truncate_words, like:
{{ content|truncate_words:40|truncate_letters:200 }
To make sure that text (mostly from user content, or scrapers)
get's limited to some fair amount even one words are extremely
long.
We also include it in django-extensions as truncate_letters.
It always seemed strange why truncate_words is included and
something to truncate letters isn't. Seems a logical pair
I also feel slice isn't an alternative, if it where then by the same
token we could remove truncate_words because you could also
split and slice. And it means repeating yourself many times over
when it can be solved with a simple template_tag.
Regards,
Bas
--
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: compressed fixture support
I agree with Russ Magee's feeling. For compression you should just use pipes, you already pipe the output to a file, you should also pipe it through a compress app. An -c,--compress option does not make any sense without an accompanying -o,--output-file option as well. Though i'm +1 on having transparent support for gzip and bzip2 in commands where we actually specify the filename. ( ./manage.py loaddata somefile.json.gz ) And would be as easy to implement, the possible usecases i've got is with a big fixture of a organism/protein database. This can be compressed very well and is only applied one, so no need to keep a 50+ MB fixture around (and in version control) when it can be compressed in a few mb with gzip. Anyways sorry to bump this thread ;) On Sat, 2008-09-13 at 19:43 +0800, Russell Keith-Magee wrote: > On Sat, Sep 13, 2008 at 1:35 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > > > I'd like to add support for fixture load/dump to deal with compressed > > (gzip) files transparently. > > Something like #4924, perhaps? :-) > > I'm not completely sold on the --compress option to dumpdata - there > are many options for compression other than gz, and you can use shell > pipes to compress the output of dumpdata using whatever scheme you > desire. > > However, loading compressed fixtures is a reasonable suggestion > (although, like Jacob, I don't have much need for them myself). > > 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-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: `create_or_update` method on query sets, managers, and related managers.
Most of the times i have some extra condition in there.
if not created and modified>instance.modified:
for key, value in defaults_dict.items():
setattr(instance, key, value)
instance.save()
Now this extra clause can be fairly arbitrary.
A generic piece of code could check if there's any difference
between the defaults dict and the instance, then update those
differences and save the instance. Drawback is that wouldn't be very
fast but at least better then continuously saving the model imho.
def create_or_update(...):
updated = False
obj, created = Model.objects.get_or_create(something=something, ...,
defaults_dict = defaults_dict)
if not created and any(value!=getattr(obj, key) for key, value in
defaults_dict.items()):
# TODO: only update differences here (nicer then updating all?)
for key, value in defaults_dict.items():
setattr(obj, key, value)
obj.save()
updated = True
return obj, created, updated
Guess something like this could/would also be a nice snipplet to put on
django snipplets :)
On Wed, 2008-09-10 at 22:04 -0700, Tai Lee wrote:
> On a few occasions I've found myself doing something like:
>
> instance, created =
> Model.objects.get_or_create(something=something, ..., defaults={
> 'somethingelse': somethingelse,
> ...
> })
> if not created:
> instance. somethingelse = somethingelse
> ...
> instance.save()
>
> I'd like to propose a `create_or_update` method, similar to
> `get_or_create`, which would work like this:
>
> instance, created =
> Model.objects.create_or_update(something=something, defaults={
> 'somethingelse': somethingelse,
> })
>
> If `instance` doesn't exist, it will be created with the specified
> kwargs and `defaults`. If it does exist, it will be updated with
> `defaults`. What does everyone think?
>
>
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
css includes in class Admin like js = ()
Hi Guys,
In semi-response to wonderfull things like Upcoming changes to the Django
admin :)
How about having something similar as the js tuple for css styles ?
A usecase could be the admin fields for a model, there u can declare
something like:
fields = (
(None, {
'fields': ('name',),
}),
("Slot 1", {
'description': 'Slot 1 Content',
'classes': 'wide extrapretty imgfoo',
'fields': ('foo','bar',),
}),
("Slot 2", {
'description': 'Slot 2 Content',
'classes': 'wide extrapretty imgbacon',
'fields': ('bacon','spam','eggs',),
}),
)
As with js u can add some javascript to fields of your choosing, an added
option
css would let u add a file with the 2 extra .imgfoo {} and .imgbacon {} css
classes.
But maybe also other things like adding a border or different bg color to
that one
special field in your model :-)
respect and regards,
Bas
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
