Re: contrib.staticfiles app concerns
On Fri, Oct 29, 2010 at 10:32 PM, Jacob Kaplan-Moss wrote: > There's no way I'm adding text like that to the staticfiles > documentation. Not in a million years. It's confusing to me, and > *I've* been following this discussion. Can you imagine how confusing > that's going to be to people who *haven't*? The vast majority of users > aren't going to know what the heck an "asset manager" is, what this > "standards-complient" business is, or why they should care. They're > reading this document because they want to get a CSS file up onto a > production server somewhere. That's it. Why do you think was the patch named "ridiculous-patch.diff"? I'm trying to communicate the *problem* because you haven't understood that, yet. But for some reason you expect me to send the *solution* (that's why you ask for a patch). That makes no sense at all because you don't know what the *problem* is. > As far as I can understand from the vast reams you've written so far, > what you're basically saying is "if you use url() in a CSS file it > needs to point to an URL that actually exists." I'm pretty sure most > people are smart enough to figure that out. No, you're looking at this from the wrong perspective. When people use django.contrib.staticfiles then of course they will use URLs that exist. Anything else is ridiculous. Why would anyone write URLs that don't work? :) But is it so difficult to understand that a lot of developers use some *other* asset manager? More than 70% of those other asset managers *force* you to write *broken* URLs. Most asset managers are broken! The problem is not staticfiles, but the large number of broken 3rd-party asset managers. Why are they broken? Because they combine your files and once your files are combined the URLs suddenly work. IOW, those asset managers convert *broken* URLs into *working* URLs. That's their convention and their standard. Is this stupid? Yes. It's still reality. A very large number of developers use this stupid broken convention. Now what do you think, how likely is it that open-source developers will use such a *broken* asset manager (not staticfiles) and release *broken* CSS code that is *incompatible* with django.contrib.staticfiles? It's far too likely for Django to ignore this. This is the last time I try to explain this. As you said, let's just wait for the first users to report a bug. I hope that then you'll realize that Django's *3rd-party* asset managers have to be fixed, not staticfiles. I'll do my part and at least convert django-mediagenerator to a staticfiles-compatible URL scheme. Bye, Waldemar -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- 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: contrib.staticfiles app concerns
Hi Waldemar, So, we agreed, it's not a problem with django, it's problem with those 3rd-party apps. Perhaps, you can write emails to their authors now explaining your position? Actually, it's not a problem that 70% of those apps are broken -- in other areas, the percent of "wrong" solutions can be up to 90-100% ;) On Sat, Oct 30, 2010 at 4:36 PM, Waldemar Kornewald wrote: > On Fri, Oct 29, 2010 at 10:32 PM, Jacob Kaplan-Moss > wrote: >> There's no way I'm adding text like that to the staticfiles >> documentation. Not in a million years. It's confusing to me, and >> *I've* been following this discussion. Can you imagine how confusing >> that's going to be to people who *haven't*? The vast majority of users >> aren't going to know what the heck an "asset manager" is, what this >> "standards-complient" business is, or why they should care. They're >> reading this document because they want to get a CSS file up onto a >> production server somewhere. That's it. > > Why do you think was the patch named "ridiculous-patch.diff"? I'm > trying to communicate the *problem* because you haven't understood > that, yet. But for some reason you expect me to send the *solution* > (that's why you ask for a patch). That makes no sense at all because > you don't know what the *problem* is. > >> As far as I can understand from the vast reams you've written so far, >> what you're basically saying is "if you use url() in a CSS file it >> needs to point to an URL that actually exists." I'm pretty sure most >> people are smart enough to figure that out. > > No, you're looking at this from the wrong perspective. When people use > django.contrib.staticfiles then of course they will use URLs that > exist. Anything else is ridiculous. Why would anyone write URLs that > don't work? :) > > But is it so difficult to understand that a lot of developers use some > *other* asset manager? More than 70% of those other asset managers > *force* you to write *broken* URLs. Most asset managers are broken! > The problem is not staticfiles, but the large number of broken > 3rd-party asset managers. > > Why are they broken? Because they combine your files and once your > files are combined the URLs suddenly work. IOW, those asset managers > convert *broken* URLs into *working* URLs. That's their convention and > their standard. Is this stupid? Yes. It's still reality. A very large > number of developers use this stupid broken convention. > > Now what do you think, how likely is it that open-source developers > will use such a *broken* asset manager (not staticfiles) and release > *broken* CSS code that is *incompatible* with > django.contrib.staticfiles? It's far too likely for Django to ignore > this. > > This is the last time I try to explain this. As you said, let's just > wait for the first users to report a bug. I hope that then you'll > realize that Django's *3rd-party* asset managers have to be fixed, not > staticfiles. > > I'll do my part and at least convert django-mediagenerator to a > staticfiles-compatible URL scheme. > > Bye, > Waldemar > > -- > Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: > http://www.allbuttonspressed.com/blog/django > > -- > 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. > > -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.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-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: contrib.staticfiles app concerns
Hi Yuri, On Sat, Oct 30, 2010 at 1:22 PM, burc...@gmail.com wrote: > Hi Waldemar, > > So, we agreed, it's not a problem with django, it's problem with those > 3rd-party apps. Yes, exactly! That's why I wanted an official standard that all 3rd-party apps can follow. > Perhaps, you can write emails to their authors now explaining your position? I thought about doing that, but it would be a lot easier if Django officially promoted this as a standard. Otherwise I'm just some random guy trying to convince them that they should fix their asset managers. This might even mean that they have to migrate all their current CSS code (or at least add a settings switch for the old behavior). Who would invest this effort just because some random guy suggests it? It would be so much easier with the Django core team leading this effort. Bye, Waldemar -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- 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.
CUBRID as Django bakend
Hello, Are there any plans to add CUBRID - http://www.cubrid.org/ ad Django backend? Seems to be very optimized DB for web application (opensource with internal support clastering, partitioning, efficient paging support) Thanks, Alex -- 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: CUBRID as Django bakend
On Sat, Oct 30, 2010 at 8:59 PM, Alex wrote: > Hello, > > Are there any plans to add CUBRID - http://www.cubrid.org/ ad Django > backend? > > Seems to be very optimized DB for web application (opensource with > internal support clastering, partitioning, efficient paging support) Given that I've never even heard of CUBRID before your post... no, there aren't any plans. More broadly, there aren't really any plans to add extra database backends to Django's core itself. Instead, we're encouraging a community of database backends to flourish. Our built-in set of SQLite, MySQL, Postgres and Oracle gives us coverage of the most widely used open source databases, and one major commercial database. This enables us to claim, from a marketing position, that we are a cross-database solution. Then, there are external backends available for DB2, Sybase SQLAnywhere, MSSQL, Firebird, and others. These projects exist entirely outside Django's source tree, and they have their own release cycles, maintainers, and so on. If CUBRID is something that you think is important, then I encourage you to write a database backend to support it. If CUBRID provides a Python DB-API compliant interface, and contains a well-featured SQL implementation, it should be fairly easy to write such a backend. However, if it turns out that CUBRID has some eccentricity that requires a modification to the Django database backend API, make a proposal and we'll consider 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.
Re: CUBRID as Django bakend
On Sat, 2010-10-30 at 05:59 -0700, Alex wrote: > Hello, > > Are there any plans to add CUBRID - http://www.cubrid.org/ ad Django > backend? > > Seems to be very optimized DB for web application (opensource with > internal support clastering, partitioning, efficient paging support) There are no plans I know of, and I for one have never heard of it until now. That suggests it doesn't have a huge amount of market share, and not enough to warrant a backend included in core as yet. Luke -- "I have had a perfectly lovely evening. However, this wasn't it." (Groucho Marx) Luke Plant || http://lukeplant.me.uk/ -- 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: contrib.staticfiles app concerns
Hi Waldemar, The problem was really hard to understand for me because I was assuming you're trying to describe django.contrib.staticfiles flaw while you were describing the problem with third-party asset managers. I think you have described a real problem here but (as you said) this problem is not a problem of Django itself and should be reported to asset apps authors and users via bug tracker and blog posts, not to django-developers list. I don't see how the incompatibility you describe relates to staticfiles at all - it is a flaw in asset managers and it is related to how css/html works, not to the way django works. On 30 окт, 15:36, Waldemar Kornewald wrote: > On Fri, Oct 29, 2010 at 10:32 PM, Jacob Kaplan-Moss > wrote: > > There's no way I'm adding text like that to the staticfiles > > documentation. Not in a million years. It's confusing to me, and > > *I've* been following this discussion. Can you imagine how confusing > > that's going to be to people who *haven't*? The vast majority of users > > aren't going to know what the heck an "asset manager" is, what this > > "standards-complient" business is, or why they should care. They're > > reading this document because they want to get a CSS file up onto a > > production server somewhere. That's it. > > Why do you think was the patch named "ridiculous-patch.diff"? I'm > trying to communicate the *problem* because you haven't understood > that, yet. But for some reason you expect me to send the *solution* > (that's why you ask for a patch). That makes no sense at all because > you don't know what the *problem* is. > > > As far as I can understand from the vast reams you've written so far, > > what you're basically saying is "if you use url() in a CSS file it > > needs to point to an URL that actually exists." I'm pretty sure most > > people are smart enough to figure that out. > > No, you're looking at this from the wrong perspective. When people use > django.contrib.staticfiles then of course they will use URLs that > exist. Anything else is ridiculous. Why would anyone write URLs that > don't work? :) > > But is it so difficult to understand that a lot of developers use some > *other* asset manager? More than 70% of those other asset managers > *force* you to write *broken* URLs. Most asset managers are broken! > The problem is not staticfiles, but the large number of broken > 3rd-party asset managers. > > Why are they broken? Because they combine your files and once your > files are combined the URLs suddenly work. IOW, those asset managers > convert *broken* URLs into *working* URLs. That's their convention and > their standard. Is this stupid? Yes. It's still reality. A very large > number of developers use this stupid broken convention. > > Now what do you think, how likely is it that open-source developers > will use such a *broken* asset manager (not staticfiles) and release > *broken* CSS code that is *incompatible* with > django.contrib.staticfiles? It's far too likely for Django to ignore > this. > > This is the last time I try to explain this. As you said, let's just > wait for the first users to report a bug. I hope that then you'll > realize that Django's *3rd-party* asset managers have to be fixed, not > staticfiles. > > I'll do my part and at least convert django-mediagenerator to a > staticfiles-compatible URL scheme. > > Bye, > Waldemar > > -- > Django on App Engine, MongoDB, ...? Browser-side Python? It's > open-source:http://www.allbuttonspressed.com/blog/django -- 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: contrib.staticfiles app concerns
Hi Mikhail, On Sat, Oct 30, 2010 at 1:22 PM, Mikhail Korobov wrote: > Hi Waldemar, > > The problem was really hard to understand for me because I was > assuming you're trying to describe django.contrib.staticfiles flaw > while you were describing the problem with third-party asset managers. It seems like most people here had this assumption. :( > I think you have described a real problem here but (as you said) this > problem is not a problem of Django itself and should be reported to > asset apps authors and users via bug tracker and blog posts, not to > django-developers list. I don't see how the incompatibility you > describe relates to staticfiles at all - it is a flaw in asset > managers and it is related to how css/html works, not to the way > django works. I went to django-developers in order to get some official Django backing. I think this can be seen as a Django problem: It's Django's community that will experience the problem and it's Django's task to take care of its own community. If we tell asset manager authors "Fix your asset manager." they might just respond "No. Your way is wrong. Mine is right.". But if we can point to the Django documentation and say "Hey, you don't follow the specification." it's a whole different story. It's not a matter of taste, anymore. It becomes a hard fact. They can still decide to not fix their code, but then they know they are breaking the specification. Bye, Waldemar -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- 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: CUBRID as Django bakend
On Oct 30, 3:47 pm, Luke Plant wrote: > On Sat, 2010-10-30 at 05:59 -0700, Alex wrote: > > Hello, > > > Are there any plans to add CUBRID -http://www.cubrid.org/ad Django > > backend? > > > Seems to be very optimized DB for web application (opensource with > > internal support clastering, partitioning, efficient paging support) > > There are no plans I know of, and I for one have never heard of it until > now. That suggests it doesn't have a huge amount of market share, and > not enough to warrant a backend included in core as yet. I had not heard of it either; apparently they get that a lot [1]: """ Why very few global users know about CUBRID? All these years CUBRID has been available in Korea only, since it supported only Korean language. Therefore, most non-Korean developers and users from other countries have never heard of CUBRID. """ [1] http://www.cubrid.org/faq -- 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: Gentle Proposal: add 'render' shortcut in 1.3
On 10/29/2010 09:38 PM, Carl Meyer wrote: Seems that a template-response-middleware might reasonably want to look at some other response data (headers? or simply extra annotation attributes?) in order to make decisions about what to do. You right. And it's not feasible (or beautiful) to just rip everything out of response and pass as local arguments. Back to thinking :-). Russel and others: do you think the issue of accidental baking is a show-stopper here? -- 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: Gentle Proposal: add 'render' shortcut in 1.3
On Oct 31, 8:26 am, Ivan Sagalaev wrote: > Russel and others: do you think the issue of accidental baking is a > show-stopper here? It seems a simple enough proposal that trying to access the content property would raise an error until it is explicitly baked. Problem solved. -- 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: Gentle Proposal: add 'render' shortcut in 1.3
On 10/30/2010 10:47 PM, SmileyChris wrote: It seems a simple enough proposal that trying to access the content property would raise an error until it is explicitly baked. Problem solved. True. I seem to somehow missed it between the lines. Thanks! I'm +1 on it by the way. -- 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: Custum permission bug
Do you have South in your INSTALLED_APPS? I've noticed it doesn't fire
the appropriate syncdb signals.
--
Michael
On Fri, 2010-10-29 at 08:46 +0800, Russell Keith-Magee wrote:
> On Thu, Oct 28, 2010 at 8:12 PM, Narciso Oceguera wrote:
> > Hi, everyone.
> >
> > As documentation said, I just added the lines:
> >
> > class USCitizen(models.Model):
> > # ...
> >
> > class Meta:
> > permissions = (
> > ("can_drive", "Can drive"),
> > ("can_vote", "Can vote in elections"),
> > ("can_drink", "Can drink alcohol"),
> > )
> >
> > But after executing: manage.py syncdb
> > I can't get my custom permission added in the permission table. I think this
> > is a bug because the permissions was not found in
> > model._meta.permission attribute ( opts.permissions ) as the signals
> > (syncdb) expect. These
> > permission were added to the model object itself.
>
> I can't reproduce your problem. The model you provided synchronizes
> fine for me, and permissions are added as expected.
>
> 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.
Re: Custum permission bug
On Thu, Oct 28, 2010 at 9:12 AM, Narciso Oceguera wrote:
> Hi, everyone.
>
> As documentation said, I just added the lines:
>
> class USCitizen(models.Model):
> # ...
>
> class Meta:
> permissions = (
> ("can_drive", "Can drive"),
> ("can_vote", "Can vote in elections"),
> ("can_drink", "Can drink alcohol"),
> )
>
> But after executing: manage.py syncdb
> I can't get my custom permission added in the permission table. I think this
> is a bug because the permissions was not found in
> model._meta.permission attribute ( opts.permissions ) as the signals
> (syncdb) expect. These
> permission were added to the model object itself.
If I understand you correctly, you have found an eror in the Django
documentation
that had already been reported as ticket [1]13503. I will fix it now.
The permissions are about things an user can or can't do with
a model instance, not about things a model can or can't do.
Could you please confirm this is what you're talking about?
Sorry for the inconvenience and thanks for bringing it to our attention..
--
Ramiro Morales
1. http://code.djangoproject.com/ticket/13503
--
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.
