Re: Improved labels for M2M relations
Hey there, thanks! I agree, "Relation between and " will work in all cases. Here’s a draft implementation: https://github.com/django/django/compare/master...julianklotz:feature_better_m2m_relation_labels Here’s what needs to be improved: - `create_many_to_many_intermediary_model`: The method uses both model classes and model class names; to access the verbose name, class names need to be resolved to “real” classes first. Any hints how to do that? `resolve_relation` doesn't to the job, because it returns both model names and classes, too. - Not sure how to implement tests for __str__ method without creating migrations? Let me know what you think about it. Julian Adam Johnson schrieb am Montag, 2. November 2020 um 10:21:06 UTC+1: > I don't think we can use just "Relation to" because M2M relationships are > two-way by default. Whilst a ManyToManyField can be declared on one model, > it adds a reverse field on the other model. We'd have to show both sides of > the relation e.g. "Relation between and ". > > On Tue, 27 Oct 2020 at 08:56, Julian Klotz wrote: > >> … one last thought: >> >> The verbose name could be: “Media Item-Piece relation” >> The string presentation could be: “Relation to > to-instance>”, e.g. “Relation to Piece xyz” >> >> Together: >> *Media Item-Piece relation: Relation to Piece xyz (ID: 11773)* >> >> >> Julian Klotz schrieb am Dienstag, 27. Oktober 2020 um 09:30:59 UTC+1: >> >>> Hi Adam, >>> >>> thanks for picking this up so quickly. >>> I considered setting custom “through” models to set verbose name and >>> __str__, but I currently can’t “afford” changing all m2m fields throught >>> the application. >>> >>> Here’s the feedback I got concerning the usability issues (e.g. for >>> MediaItem_pieces_relation object (11773)) >>> >>>- Some people thought “11773” was the number of objects to be >>>deleted, even though the UI clearly states something else – it isn’t >>>obvious for some people that relations have their own IDs >>>- People asked where they could change the (then-deleted) relation >>>to a different object >>> >>> >>> >>> *It can also help with debugging as the label appears in the default >>> str/repr.* >>> Thanks for giving me that hint. It’s the __str__ method of models.Model. >>> Changing the default string presentation may be dangerous and also too >>> generic. It would make sense to define a custom to-string method in >>> `create_many_to_many_intermediary_model` (fields/related.py)*.* >>> Instead of showing *MediaItem_pieces_relation object (11773),* >>> something like “Media Item-Piece relation, ID: 11773) would be good*; >>> *moreover, >>> it may be a good idea to show the “from” model’s edit link to point people >>> to the place where they can change this relation. >>> >>> *My main question is, does this not trigger migrations on user projects?* >>> Good point. I just checked – interestingly, neither changing the verbose >>> name nor the __str__ method triggers new migrations 拾 >>> >>> >>> >>> Best regards >>> Julian >>> >>> Adam Johnson schrieb am Montag, 26. Oktober 2020 um 19:56:15 UTC+1: >>> >>>> Hi Julian >>>> >>>> It should be noted that you can improve the display today by creating >>>> explicit through models. However this is more longwinded. >>>> >>>> This change does look like a neat usability improvement to me. It can >>>> also help with debugging as the label appears in the default str/repr. My >>>> main question is, does this not trigger migrations on user projects? >>>> >>>> Thanks, >>>> >>>> Adam >>>> >>>> On Mon, 26 Oct 2020 at 16:28, Julian Klotz >>>> wrote: >>>> >>>>> >>>>> Hey there, >>>>> >>>>> here’s a little topic that impacts the usability of Django admin’s >>>>> delete views. >>>>> >>>>> When deleting an object using django admin, you get a nice summary of >>>>> all deleted objects. >>>>> I really like the overview, but the labels used to describe m2m >>>>> relations that will be deleted aren't user-friendly at all: >>>>> >>>>> […] >>>>> >>>>>- MediaItem-subseries-relation: MediaItem_sub_
Re: Improved labels for M2M relations
… one last thought:
The verbose name could be: “Media Item-Piece relation”
The string presentation could be: “Relation to ”, e.g. “Relation to Piece xyz”
Together:
*Media Item-Piece relation: Relation to Piece xyz (ID: 11773)*
Julian Klotz schrieb am Dienstag, 27. Oktober 2020 um 09:30:59 UTC+1:
> Hi Adam,
>
> thanks for picking this up so quickly.
> I considered setting custom “through” models to set verbose name and
> __str__, but I currently can’t “afford” changing all m2m fields throught
> the application.
>
> Here’s the feedback I got concerning the usability issues (e.g. for
> MediaItem_pieces_relation object (11773))
>
>- Some people thought “11773” was the number of objects to be deleted,
>even though the UI clearly states something else – it isn’t obvious for
>some people that relations have their own IDs
>- People asked where they could change the (then-deleted) relation to
>a different object
>
>
>
> *It can also help with debugging as the label appears in the default
> str/repr.*
> Thanks for giving me that hint. It’s the __str__ method of models.Model.
> Changing the default string presentation may be dangerous and also too
> generic. It would make sense to define a custom to-string method in
> `create_many_to_many_intermediary_model` (fields/related.py)*.*
> Instead of showing *MediaItem_pieces_relation object (11773),* something
> like “Media Item-Piece relation, ID: 11773) would be good*; *moreover, it
> may be a good idea to show the “from” model’s edit link to point people to
> the place where they can change this relation.
>
> *My main question is, does this not trigger migrations on user projects?*
> Good point. I just checked – interestingly, neither changing the verbose
> name nor the __str__ method triggers new migrations 拾
>
>
>
> Best regards
> Julian
>
> Adam Johnson schrieb am Montag, 26. Oktober 2020 um 19:56:15 UTC+1:
>
>> Hi Julian
>>
>> It should be noted that you can improve the display today by creating
>> explicit through models. However this is more longwinded.
>>
>> This change does look like a neat usability improvement to me. It can
>> also help with debugging as the label appears in the default str/repr. My
>> main question is, does this not trigger migrations on user projects?
>>
>> Thanks,
>>
>> Adam
>>
>> On Mon, 26 Oct 2020 at 16:28, Julian Klotz wrote:
>>
>>>
>>> Hey there,
>>>
>>> here’s a little topic that impacts the usability of Django admin’s
>>> delete views.
>>>
>>> When deleting an object using django admin, you get a nice summary of
>>> all deleted objects.
>>> I really like the overview, but the labels used to describe m2m
>>> relations that will be deleted aren't user-friendly at all:
>>>
>>> […]
>>>
>>>- MediaItem-subseries-relation: MediaItem_sub_series_relation object
>>>(11482)
>>>- MediaItem-piece-relation: MediaItem_pieces_relation object (11773)
>>>
>>> So I’d like to improve the labels a bit, using the from and to model’s
>>> verbose names. This can be easily accomplished by changing
>>> `create_many_to_many_intermediary_model` in fields/related.py.
>>>
>>> To be honest, I don’t know how to update the tests for something rooted
>>> deeply in Django’s core.Is anyone who is more competent than me interested
>>> in fixing this? It would greatly improve the “delete confirmation“ views.
>>>
>>> Here’s what I’ve got so for; it only fixes the model’s verbose name, not
>>> its string presentation.
>>>
>>> Best regards
>>> Julian
>>>
>>>
>>> […]
>>> to = make_model_tuple(to_model)[1]
>>> from_ = klass._meta.model_name
>>>
>>> if isinstance(to_model, str):
>>> to_label = to
>>> to_label_plural = to
>>> else:
>>> to_label = to_model._meta.verbose_name
>>> to_label_plural = to_model._meta.verbose_name_plural
>>>
>>> from_label = klass._meta.verbose_name
>>> from_label_plural = klass._meta.verbose_name_plural
>>>
>>> if to == from_:
>>> to = 'to_%s' % to
>>> from_ = 'from_%s' % from_
>>>
>>> meta = type('Meta', (), {
>>> 'db_table': field._get_m2m_db_table(klass._meta),
>>> 'auto_created': klass,
>>> 'app_label': klass._meta.app_label,
>>> 'db_tablespace': klass._meta.db_tablespace,
Re: Improved labels for M2M relations
Hi Adam,
thanks for picking this up so quickly.
I considered setting custom “through” models to set verbose name and
__str__, but I currently can’t “afford” changing all m2m fields throught
the application.
Here’s the feedback I got concerning the usability issues (e.g. for
MediaItem_pieces_relation object (11773))
- Some people thought “11773” was the number of objects to be deleted,
even though the UI clearly states something else – it isn’t obvious for
some people that relations have their own IDs
- People asked where they could change the (then-deleted) relation to a
different object
*It can also help with debugging as the label appears in the default
str/repr.*
Thanks for giving me that hint. It’s the __str__ method of models.Model.
Changing the default string presentation may be dangerous and also too
generic. It would make sense to define a custom to-string method in
`create_many_to_many_intermediary_model` (fields/related.py)*.*
Instead of showing *MediaItem_pieces_relation object (11773),* something
like “Media Item-Piece relation, ID: 11773) would be good*; *moreover, it
may be a good idea to show the “from” model’s edit link to point people to
the place where they can change this relation.
*My main question is, does this not trigger migrations on user projects?*
Good point. I just checked – interestingly, neither changing the verbose
name nor the __str__ method triggers new migrations 拾
Best regards
Julian
Adam Johnson schrieb am Montag, 26. Oktober 2020 um 19:56:15 UTC+1:
> Hi Julian
>
> It should be noted that you can improve the display today by creating
> explicit through models. However this is more longwinded.
>
> This change does look like a neat usability improvement to me. It can also
> help with debugging as the label appears in the default str/repr. My main
> question is, does this not trigger migrations on user projects?
>
> Thanks,
>
> Adam
>
> On Mon, 26 Oct 2020 at 16:28, Julian Klotz wrote:
>
>>
>> Hey there,
>>
>> here’s a little topic that impacts the usability of Django admin’s delete
>> views.
>>
>> When deleting an object using django admin, you get a nice summary of all
>> deleted objects.
>> I really like the overview, but the labels used to describe m2m relations
>> that will be deleted aren't user-friendly at all:
>>
>> […]
>>
>>- MediaItem-subseries-relation: MediaItem_sub_series_relation object
>>(11482)
>>- MediaItem-piece-relation: MediaItem_pieces_relation object (11773)
>>
>> So I’d like to improve the labels a bit, using the from and to model’s
>> verbose names. This can be easily accomplished by changing
>> `create_many_to_many_intermediary_model` in fields/related.py.
>>
>> To be honest, I don’t know how to update the tests for something rooted
>> deeply in Django’s core.Is anyone who is more competent than me interested
>> in fixing this? It would greatly improve the “delete confirmation“ views.
>>
>> Here’s what I’ve got so for; it only fixes the model’s verbose name, not
>> its string presentation.
>>
>> Best regards
>> Julian
>>
>>
>> […]
>> to = make_model_tuple(to_model)[1]
>> from_ = klass._meta.model_name
>>
>> if isinstance(to_model, str):
>> to_label = to
>> to_label_plural = to
>> else:
>> to_label = to_model._meta.verbose_name
>> to_label_plural = to_model._meta.verbose_name_plural
>>
>> from_label = klass._meta.verbose_name
>> from_label_plural = klass._meta.verbose_name_plural
>>
>> if to == from_:
>> to = 'to_%s' % to
>> from_ = 'from_%s' % from_
>>
>> meta = type('Meta', (), {
>> 'db_table': field._get_m2m_db_table(klass._meta),
>> 'auto_created': klass,
>> 'app_label': klass._meta.app_label,
>> 'db_tablespace': klass._meta.db_tablespace,
>> 'unique_together': (from_, to),
>> 'verbose_name': _('%(from)s-%(to)s relationship') % {'from':
>> from_label, 'to': to_label},
>> 'verbose_name_plural': _('%(from)s-%(to)s relationships') %
>> {'from': from_label_plural, 'to': to_label_plural},
>> 'apps': field.model._meta.apps,
>> })
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-develop...@googlegroups.com.
>> To view this discussion on the web visit
>> https:/
Improved labels for M2M relations
Hey there,
here’s a little topic that impacts the usability of Django admin’s delete
views.
When deleting an object using django admin, you get a nice summary of all
deleted objects.
I really like the overview, but the labels used to describe m2m relations
that will be deleted aren't user-friendly at all:
[…]
- MediaItem-subseries-relation: MediaItem_sub_series_relation object
(11482)
- MediaItem-piece-relation: MediaItem_pieces_relation object (11773)
So I’d like to improve the labels a bit, using the from and to model’s
verbose names. This can be easily accomplished by changing
`create_many_to_many_intermediary_model` in fields/related.py.
To be honest, I don’t know how to update the tests for something rooted
deeply in Django’s core.Is anyone who is more competent than me interested
in fixing this? It would greatly improve the “delete confirmation“ views.
Here’s what I’ve got so for; it only fixes the model’s verbose name, not
its string presentation.
Best regards
Julian
[…]
to = make_model_tuple(to_model)[1]
from_ = klass._meta.model_name
if isinstance(to_model, str):
to_label = to
to_label_plural = to
else:
to_label = to_model._meta.verbose_name
to_label_plural = to_model._meta.verbose_name_plural
from_label = klass._meta.verbose_name
from_label_plural = klass._meta.verbose_name_plural
if to == from_:
to = 'to_%s' % to
from_ = 'from_%s' % from_
meta = type('Meta', (), {
'db_table': field._get_m2m_db_table(klass._meta),
'auto_created': klass,
'app_label': klass._meta.app_label,
'db_tablespace': klass._meta.db_tablespace,
'unique_together': (from_, to),
'verbose_name': _('%(from)s-%(to)s relationship') % {'from':
from_label, 'to': to_label},
'verbose_name_plural': _('%(from)s-%(to)s relationships') %
{'from': from_label_plural, 'to': to_label_plural},
'apps': field.model._meta.apps,
})
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/69b6f2e0-8f0e-4cd0-b608-46fb9040b355n%40googlegroups.com.
Adding checks for common URLpattern configuration errors
Hi Django-Developers I would like to add additional system checks to the existing bunch. In particular, checks regarding common configuration errors around URLpatterns. An example check is described in the ticket here: https://code.djangoproject.com/ticket/23813 Please suggest any other common issues you might have encountered that would be great to have as a check in the Django core. And feel free to propose any checks unrelated to URLpatterns, too. Cheers Julian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/CALvBJz1k4joCj24Tp54uxBm_nrGETC14DYJkj%3D4hqxcQfPKTTw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Some thoughts on Django Form Wizard
Hey there, I have been spending a lot of time working with FormWizard recently and had a few ideas on where it might be able to be improved. Here are some of my thoughts, let me know if these are things the community would find interesting. 1) More seamless navigation between steps of the for. For me, going back and forth seemed like a three step process: Handling the submitted data, updating the template context and grabbing the correct form, and finally redirecting the user to the intended step. I was wondering if these steps could be reduced and the ability to skip or navigate easily between steps because a little simpler. 2) Saving partially submitted data. I know there are ways to do this already, but again, to me it's about baking this functionality into the FormWizard a bit more. I would allow users to partially submit data and "save for later". Once they reach the final page, all the form data would not submit until all fields have been filled out. Just some thoughts. Let me know what you think. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/89182909-1875-44cb-ab07-7f7625e2757d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: SMTP configuration in a dict
Discussion may continue in this ticket then: https://code.djangoproject.com/ticket/22734 Cheers On Wed, May 28, 2014 at 10:29 PM, Aymeric Augustin <aymeric.augustin.2...@polytechnique.org> wrote: > Still, it's a good idea, please file a Trac ticket if there isn't one > already. > > -- > Aymeric. > > Le 28 mai 2014 à 13:22, Tim Graham <timogra...@gmail.com> a écrit : > > Ramiro tried to do something similar, moving the cookie settings to a > dictionary, see #21051, but gave up due to backwards compatibility concerns. > Not saying it's impossible, but it may be a bit trickier than it looks at > first. > > On Wednesday, May 28, 2014 7:06:00 AM UTC-4, Julian Wachholz wrote: >> >> Hi django-developers >> >> I'd like to propose a relatively small change to the way we configure our >> SMTP email backends. >> Up until now, configuring your SMTP backend took up to 6 individual >> settings, ranging from EMAIL_HOST to EMAIL_USE_SSL etc. >> >> We already have a dictionary to configure things like caches and >> databases, so why not for sending email (at least with the SMTP backend). >> I've already created a POC branch complete with docs and deprecation >> warnings here: >> https://github.com/julianwachholz/django/tree/feature/12factor-smtp >> >> Please let me know what you think! >> >> Cheers >> Julian >> >> PS: This change is only so altruistic, as it would enable me to include >> email settings in my dj-database-url fork >> (https://github.com/julianwachholz/dj-config-url). >> > -- > 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/2a94dfa5-e087-4d5f-9b34-620652611c82%40googlegroups.com. > 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/2884B9B1-D40B-4F31-8902-28B91DDC69E0%40polytechnique.org. > > 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/CALvBJz1EawsS62OREO1GzU7bAVmtm-6ZGqL2YxYTWuEWTEXkZQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
SMTP configuration in a dict
Hi django-developers I'd like to propose a relatively small change to the way we configure our SMTP email backends. Up until now, configuring your SMTP backend took up to 6 individual settings, ranging from EMAIL_HOST to EMAIL_USE_SSL etc. We already have a dictionary to configure things like caches and databases, so why not for sending email (at least with the SMTP backend). I've already created a POC branch complete with docs and deprecation warnings here: https://github.com/julianwachholz/django/tree/feature/12factor-smtp Please let me know what you think! Cheers Julian PS: This change is only so altruistic, as it would enable me to include email settings in my dj-database-url fork (https://github.com/julianwachholz/dj-config-url). -- 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/3ed1fa0e-8676-412e-8265-aaa196465ffb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
What is Django?
Is there any document available that describes WHAT Django is? I am not looking for an installation guide, neither for tutorial, nor for "Django is a high-level Python Web framework". But: What does this framework include? What is it used for? How does it increase productivity? Why shouldn't I use directly Python to create web apps/ pages? How could a sample app look like (without giving source code)? Such explanations would be extremely helpful and maybe even worth to be linked into https://www.djangoproject.com/ -- 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: Design and code review requested for Django string signing / signed cookies
On Jan 4, 4:47 am, Simon Willison <si...@simonwillison.net> wrote: > As you can see, the separator between the signature and the value > defaults to being a ':'. I plan to move it from being an argument on > the sign and unsign methods to being an argument to the Signer class > constructor. Here's my $.02 based on a cursory review. I like the idea of putting this logic into django. I find myself implementing something similar often. This all looks ok from a security perspective, but it seems there are a couple of things that could be simplified: 1) sep. Why use a delimiter at all? The fields you are encoding (hash or hash+date) are of a determinate length. Put those fields first, and expect them to have the correct length when unsigning. 2) salt + 'signer'. I don't see the security advantage to this. If the django secret key is compromised, you are dead. If not, then everything should be good. If someone can brute-force the key from a large sample of signatures, and I agree that is a small but real risk (at least I thought so with MD5), then they will much more easily reverse the salt+'signer'+secret from that. Unless you picture the salt changing frequently. In which case, how does the unsigner know the salt? I suspect there may even be a security risk to letting people use salt. They may use something that is known to the attacker, and it seems like this might carry some risk in itself. One other thought - I know you expect this to be used for texty protocols like http cookies, but should the signer class be producing already-encoded data? It seems like the protocol using the signed cookie should be in charge of encoding it. i.e. produce an 8-bit chunk of data. Let the set-cookie logic decide what encoding it is passed that binary chunk. This would make the base signer class more useful for applications where encoding is not necessary. And set- cookie should be robust enough to know when the data passed to it needs encoding. -=Julian=- -- 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: Multi-Threaded Dev Server
Some months ago I tried a snippet from djangosnippets.org which shows a upload progress bar. I think some people want to use snippets like that and a multi-threaded server would help you developing such applications. 2008/11/16 Vinay Sajip <[EMAIL PROTECTED]> > > > > On Nov 16, 6:26 am, Chris <[EMAIL PROTECTED]> wrote: > > I thinkhttp://code.djangoproject.com/ticket/3357should be given > > another look at enabling optional multi-threading on the dev server. > > > > Jacob previously closed this ticket, noting the patch could introduce > > threading bugs, and would provide functionality too similar to that of > > a production environment. > > > > This is my rationale to accept this ticket: > > 1. Ajax is very common place, and often requires a multi-threaded > > server. The dev server is very convenient, but by not providing multi- > > threading support, we're preventing it from being even more useful. > > 2. Since multi-threading would be an optional setting, the default > > scenario would still be single-threaded and would not break anything. > > Only those specifically desiring multi-threading would subject > > themselves to any unforeseen bugs. > > 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi- > > threading, especially when it could be very useful. We don't even know > > if there are multi-threading bugs. And even if there are, they can be > > fixed. > > > > Regards, > > Chris > > I would second what David Cramer said. You don't need, in the general > case, need multi-threading on the server side for Ajax - it's really > about browser-side multi-threading. I'm not sure where your point 1 > comes from: I use AJAX with the standard, single-threading development > server all the time, and I have not encountered any issues at all. I'd > say leave it as it is, unless of course you have encountered some > specific problem relating to the single-threaded nature of the server. > In that case, please post some details. > > It's theoretically possible that with the server tied up with some > long-running request, the browser might time out before the server got > around to servicing an AJAX request which was next in line. However, > you should be able to configure client-side time-outs appropriately to > mitigate this. > > Regards, > > Vinay Sajip > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
New field lookups
Hi there, writing a statistic-software i do need field lookups like day, year but more specific: hour, minute, second. what about those? can i modify my django-app to add them? regards julian --~--~-~--~~~---~--~~ 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: some trouble with an older bug
> > Ahem ... where's the patch in the ticket? Perhaps I'm being dumb, but I > honestly don't see one. > Okay, sorry, it should have been this link: http://code.djangoproject.com/ticket/285 but maybe i am totally wrong and better stop writing. julian > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: some trouble with an older bug
Sorry, i did not want to offend someone, but it was just a lttle bit frustrating. there is a patch wich was postet here: http://code.djangoproject.com/ticket/1516 but it has not been applied to the yet, maybe i will do it manually with my own local django-installation. kind regards julian On 2 Sep., 12:00, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2007-09-02 at 02:49 -0700, Julian wrote: > > hi there, > > > until now i am very happy with django, but something made me spent > > some hours of time with it, i've figured this out: > > >http://code.djangoproject.com/ticket/5320 > > > wich has an underlying issue: > > >http://code.djangoproject.com/ticket/1516 > > > wich is obviously not solved yet. it occurrs in a typically situation > > (django-application in a subfolder with fastcgi) and isn't very well > > documented (not even a little comment in the docs). > > > please tell me why noone has it fixed yet and when do you plan to do? > > Perhaps you could spend a couple of minutes searching the archives -- > search for SCRIPT_NAME for example -- to see where this has been > discussed before (the last time was about a month ago, from memory). > That will show you what the issues are around this. > > It's not completely trivial to come up with a solution that works neatly > in all cases. When somebody comes up with a good patch to do that, it > will be reviewed. > > As a general rule asking "why this hasn't been fixed yet" is a bit of a > pointless question. Everybody is a volunteer. Everybody is welcome to > write a patch to try and fix the root problem. The first patch that > fixes the real problem will be committed. That's how open source > development works. Unsurprisingly, we don't sit around saying "who can > we ignore today." > > Regards, > Malcolm > > -- > Two wrongs are only the beginning.http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
some trouble with an older bug
hi there, until now i am very happy with django, but something made me spent some hours of time with it, i've figured this out: http://code.djangoproject.com/ticket/5320 wich has an underlying issue: http://code.djangoproject.com/ticket/1516 wich is obviously not solved yet. it occurrs in a typically situation (django-application in a subfolder with fastcgi) and isn't very well documented (not even a little comment in the docs). please tell me why noone has it fixed yet and when do you plan to do? regards julian --~--~-~--~~~---~--~~ 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: International standard for date and time
On Jun 17, 2007, at 2:46 AM, Jonas wrote: > > On 17 jun, 01:14, "James Bennett" <[EMAIL PROTECTED]> wrote: >> Where do you propose this be used? At the database level, your DB >> will >> store date/time values in whatever internal format it prefers. > Yes, I think that should be stored so at the database level. Databases store dates internally, not strings. Aside from databases being unable to handle dates-times before the epoch this is not a big problem. The only place where ISO formats are appropriate are in machine-readable output (i.e. RSS/ATOM, web services and the like). -- Julian 'Julik' Tarkhanov please send all personal mail to [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
On Jan 27, 2007, at 6:44 PM, ak wrote: > And another thing I still don't understand is: let's pretend I use > MySQL 4.0 with national charset and my templates are in the same > charset too. How would work: It should not work. -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
On Jan 27, 2007, at 6:44 PM, ak wrote: > 1. newforms are with unicode inside > 2. ORM is with str inside 3. welcome to the world of pain -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
On Jan 26, 2007, at 11:47 AM, Michael Radziej wrote: > # 1356 sets the charset attribute of the mysql backend connection to > 'utf8' for mysql version >= 4.1 And leaves everyone who wants to operate in 8 bits out in the cold. Where they actually ought to be anyway, but I tried to stay liberal in 952 - primarily because it's still unknown how Django authors want to approach this. -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
On Jan 26, 2007, at 2:25 PM, Gábor Farkas wrote: > > Julian 'Julik' Tarkhanov wrote: >> >> >> Python's unicode is actually UTF-16 > > on linux it's usually utf-32, and on windows it's usually (always?) > utf-16. sorry I forgot that - it's been a year at least since I last touched Python (actually it was for the Django test drive) > > but you should not care about it. you see, in python, > the unicode-strings are a separate data-type, and there's > just no way to take a bytestring, and tell python: "from now on, > you are an unicode-string, because i know that you are encoded in > utf-16." segregating ustrings and strings is BBD, been' telling it for years. The latest I heard is that the next major Py will abolish bytestrings for good. Getting back to the issue that we were on, I am still strongly advocating the "don't go there" approach for anything but Unicode. How it should be handled in relation to source code is unknown to me (AFAIK Python has a pre-amble sort of declaration that you can actually use to tell the interpreter which encoding your source is in). I just know you hit some major pain when you expect ustrings and get bytestrings instead (and in Python, just as in Perl, only about 30% of the libraries actually care about what they give you). > so while it might be, that the conversion from utf-16-bytestrings to > unicode is sometimes faster thatn converting from utf-8-bytestrings to > unicode, you can't be sure, because as i wrote above, the internal > unicode-encoding is not fixed. > >> whereas IO and the databases mostly >> speak UTF-8 - >> so no, you can't dump it over the wire. > >> We Rubyists are a tad happier >> because we now >> have all in UTF-8 > > you mean that regexes, and all the methods of the string-class now are > unicode-aware in ruby? :) Regexes are unicode-aware for some time already except the case- sensitivity and the class repertoire (which will be fixed when Oniguruma is there). As for the string methods, we mostly took care of them with AS::Multibyte (without silly subclassing) and that works wonders for me. The greatest advantage is that I never have to check what's coming down the pipe because there's only one String to rule them all. -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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: django unicode-conversion, beginning
On 17-aug-2006, at 1:08, Bill de hÓra wrote: > like wanting to serve utf8 rss feeds, but have latin1 come > in and out of mysql. Might seem very extreme, but I would love to chime in. Maybe it would be wise to go even further, whereby: 1. Hardcode Django to output and input UTF-8 as the most useful for interop 1a. Any case where the developer might expect different input (for instance almost all OPML files are still exported as ISO due to idyosyncrastic way Radio worked back in the day) has to be known to him and handled explicittly 1b. Honor the charset headers sent in the request for transcoding 1c. Allow everyone who wants to output other charsets to cry and perish. 2. Stick the utf-8 output charset anywhere where it's possible (headers, page head...). 2. Allow the DB to be in another encoding for databases that support it. For instance, MySQL and Postgress will transcode the strings for the client on the fly, so you can do interop with them in UTF-8 even when they are in a different encoding. 3. Assume all templates are in UTF-8 as well because text editors have much more success dealing with it them that way. Transcode templates on read into unicode strings. 4. As a consequence of 1, let DEFAULT_CHARSET go. Too many choices really hurt here. 5. As a consequence of 1, deprecate the DATABASE_CHARSET I sent in as a patch and make it the default, so that all drivers switch their database clients to the most suitable Unicode form. SQLite has to be compiled with Unicode support, this has to be mentioned in the docs. 5. Internally, work with unicode strings exclusively (after transcoding the request and the template). Response should be python unicode as well up until the moment it gets sent out. Important to note is that every database driver has to be scrutinized for whether it returns unicode strings proper. I know, it seems so nice to be liberal and allow people to choose their encoding but just too many situations prove that to be the Wrong Choice. -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: urlify.js blocks out non-English chars - 2nd try?
On 7-jul-2006, at 17:50, Bill de hÓra wrote: > This is my point. Cut what exactly? "No good" for what exactly? We > could file patches to see what sticks, but it might be better to > figure > what's wanted first, instead of playing fetch me a rock. This is handled by Unicode standard and is called transliteration. The problem is that it's locale dependent. AFAIK Python's codecs don't implement it (but ICU4R does). If you go for tables it's going to be _many_. URLs can be Unicode-aware, just encoded - so why not replacing whitespace with dashes and doing a Unicode downcase, and be done with it? Some browsers (Safari) even show you the request string verbatim, so it's very 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: the so-called [AUDIT]
On 2-jun-2006, at 22:14, Carlo C8E Miron wrote: > > On 6/2/06, Julian 'Julik' Tarkhanov <[EMAIL PROTECTED]> > wrote: >> >> I would advise all respected Django contributors to follow the path >> mentioned here: >> >> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/138966 > > and maybe also > > http://www.encyclopediadramatica.com/index.php/Ilias Quite a history: http://dev.eclipse.org/newslists/news.eclipse.foundation/msg00291.html http://www.intellij.net/forums/thread.jspa? forumID=27=3439721=122131= and a response from Hani is the best to date, hats off. -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: the so-called [AUDIT]
On 2-jun-2006, at 22:14, Carlo C8E Miron wrote: > > On 6/2/06, Julian 'Julik' Tarkhanov <[EMAIL PROTECTED]> > wrote: >> >> I would advise all respected Django contributors to follow the path >> mentioned here: >> >> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/138966 > > and maybe also > > http://www.encyclopediadramatica.com/index.php/Ilias Half of Google to be precise. Subject closed. -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: the so-called [AUDIT]
I would advise all respected Django contributors to follow the path mentioned here: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/138966 On 25-mei-2006, at 18:27, lazaridis_com wrote: > > For a long term project, I am selecting a python based persistency > system: -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MySQL 4.1.x charset support
http://code.djangoproject.com/ticket/952 On 22-mrt-2006, at 6:54, ak wrote: > > Thanks, posted: http://code.djangoproject.com/ticket/1528 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MySQL 4.1.x charset support
I file a much broader patch for thus about a few months ago. Check out the tickets. On 22-mrt-2006, at 6:54, ak wrote: > > Thanks, posted: http://code.djangoproject.com/ticket/1528 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
