Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Jerome Leclanche]

I admit, I have my own truncate filter on my website so why should I care
about bringing the truncate filter up? Heck, I've got a pretty big patchset
of features I need but "just wont be accepted".
However, feedback on an application can come from anywhere. When someone
just discovers a framework, IRC is a pretty safe bet to go to to solve
first-hand problems.
It's the most common of these first-hand problems application developers
should make easier to tackle/understand/deal with in order to make the
application as awesome as possible and the user experience as smooth as
possible. I'm pretty sure that's what all of us in this thread want.

J

On Thu, Dec 31, 2009 at 7:58 AM, Russell Keith-Magee  wrote:

> On Thu, Dec 31, 2009 at 12:54 AM, Jerome Leclanche 
> wrote:
> > On Wed, Dec 30, 2009 at 2:06 PM, Russell Keith-Magee
> >  wrote:
> >>
> >> Secondly, IMHO raw truncation based on characters is bad practice for
> >> human readable text. A sentence is composed of words, not characters.
> >> Truncating a sentence mid-word isn't a typographical practice that I
> >> particularly want to encourage.
> >
> > Please...
> > Please, please, please, do NEVER assume the use cases on your own
> websites
> > are the only ones other users will ever need.
>
> Quoting:
>
> """
> However, even with this modification - what's the use case for an N
> character truncation?
> """
>
> > Are you going to truncatewords on long filenames?
> > What about on hashes? On Email addresses?
> > Here is where I use
> > truncate:
> http://db.mmo-champion.com/i/35191/schematic-wonderheal-xt68-shades/
> > - bottom of the right box. I can't truncate such small names based on
> words
> > alone.
>
> Fine. Those are some use cases. I'm not sure I agree that tail
> truncation is the right solution for all of them, but that's a
> different battle.
>
> >> As for why this patch has languished for so long - one major reason is
> >> that nobody has made an issue of it previously. By my count, this
> >> thread is only the third time that someone has made the case for a
> >> built-in truncate filter
> > Oh NO you don't. PLEASE. grep your irc logs for truncate+filter, I know
> > you've been on irc long enough.
>
> I would ask you to please consider the following:
>
>  * I made no reference to IRC in my comments.
>
>  * Some people (including myself) don't keep historical logs of IRC
> chats, due to the ephemeral nature of IRC conversations.
>
>  * I don't recall anybody mentioning the truncate filter on django-dev
> while I was in the room *and* participating in the conversation.
>
>  * If someone did mention truncate in IRC while I was present, they
> didn't leave a lasting impression.
>
>  * The Django core team has *never* used IRC as communication channel
> of record. There is an official django-dev IRC room, but we don't use
> it to make announcements or to archive design decisions. If we make an
> important decision on IRC, it is usually backed up by a message on the
> django-dev mailing list summarizing and archiving the decision.
>
> I would then reiterate my original comment. In the archive of record -
> the django-dev mailing list - there are *exactly* three mentions of
> truncate. A truncate filter *wasn't* suggested for inclusion in the
> 1.2 feature list.
>
> I don't deny that people want this feature. However, those people
> haven't gone out of their way to draw attention to their pony until
> this thread. The original question was "why has this ticket
> languished?" The simple reason is that the issue hasn't been raised
> seriously by those that want it.
>
> 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.
>
>
>


-- 
J. Leclanche / Adys

--

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: Admin-Actions also in the object details view

[Florian Apolloner]

There is already a ticket for this request: 
http://code.djangoproject.com/ticket/12090

--

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: Admin-Actions also in the object details view

[andybak]

I can see some benefit in consistency here but what do you do about
saving the current object?

This is a problem in general with any actions performed on the same
screen a change form.

1. User enters the object detail view
2. User changes a field
3. User selects an action.

Does the action apply to the saved or unsaved state? If the former
then the admin must warn that the object will be saved before
performing the action whereas the latter option would be rather
confusing (do we keep or drop the changes?)

In general I don't think performing actions on an object makes sense
in 'edit' mode and there is no details view in the Django admin other
than an 'edit' mode.

--

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.