App Engine support

the link, as a reminder: http://code.djangoproject.com/wiki/AppEngine Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email

Re: App Engine support

will be very difficult to achieve. I had to disable result sorting in the admin interface, for example, because that would require too many composite datastore indexes and there are almost endless combinations when you can filter and sort and search results in the admin interface. Who knows, maybe

Re: App Engine support

On Aug 11, 10:01 am, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Tue, 2009-08-11 at 00:03 -0700, Waldemar Kornewald wrote: > > And these are just the first few issues we've run into when analyzing > > the source. > > Most of those are the kind of increm

Re: App Engine support

ne please add his findings to that wiki page? I only have basic knowledge about SimpleDB, so Mitch, we could need your help here. (the wiki page even has a little TODO for you :). Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ You received this message because you are s

Re: App Engine support

On Aug 12, 11:40 am, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Wed, 2009-08-12 at 02:32 -0700, Waldemar Kornewald wrote: > > Is there a way to override sql.subqueries? > > Not yet. As mentioned earlier in the thread, a large chunk of the > process o

Re: App Engine support

rows have to be re- fetched from the DB and the models must be re-instantiated - just to send signals. This could be a costly operation on non-SQL DBs, so if one already has a list of instances he wants to delete they should be reused. Bye, Waldemar Kornewald --~--~-~--~~~---

Re: App Engine support

support) * Thomas Wanschik (my colleague) * Waldemar Kornewald (that's me ;) Since we're all busy guys who can't work full-time on this project we could really need more contributors. It would be great to have more Google developers on board. ;) We also have a few other potential contributors on our l

Re: App Engine support

On Aug 27, 11:54 pm, Waldemar Kornewald <wkornew...@gmail.com> wrote: > We also have a few other potential contributors on our list, but right > now they're too busy or not ready for contributing, yet: > * Thomas Bohmbach (from Giftag) > * Curtis Thompson (from Giftag) > *

Re: App Engine support

in a scalable and efficient way *if* you know what you're doing. A dumbed down API - just to prevent noobs from doing stupid things - doesn't make sense. Instead, the emulation code should warn the developer when something gets emulated and might p

Re: App Engine support

> BTW, what would be a good name for this backend? "appengine", or is > "bigtable" more appropriate? I'd say "appengine" because we're not really using BigTable directly (the App Engine datastore is built on top o

Re: App Engine support

nctionality needed for a database backend to support Django's > various features + the backend throwing exceptions for unsupported > operations. Nobody is adding a separate API. Exactly as you want to suggest, we'll just throw exceptions for unsupported features.

backend query_class() question

Hi, why does the backend's query_class() function get the default query class as its parameter? Can't the backend just import BaseQuery? I'm asking because with different BaseQuery implementations (for SQL and non-SQL) there is no real default query class, anymore. Bye, Waldemar Kornewald

Re: backend query_class() question

you wouldn't need a caching mechanism, at all. Also, when will your branch be merged into trunk? Is there any roadmap? Regarding interoperability in a mulit-db enviroment, could you please elaborate the problem? Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ You

Re: backend query_class() question

> things I want to look at during the sprints next week. So, what did you discuss and what were the results? :) Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers"

Re: SoC merge plans?

ss() function or whether to override the whole query module? Any other issues? > The m2m refactoring patch (which is a prerequisite for the multi-db > work) could be committed now without any major problems. Then could you please commit the m2m patch? This would help us with the non-relational

Re: SoC merge plans?

use you return all classes at once via the module. By default, the module would just be django.db.models.sql. Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group.

non-relational DB

--- Task management Our tasks are managed in a Google Spreadsheet: https://spreadsheets.google.com/ccc?key=0AnLqunL-SCJJdE1fM0NzY1JQTXJuZGdEa0huODVfRHc=en The task list isn't complete, yet. We're working on that. Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ Yo

default Model.all()?

people to write ".objects" all the time? Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ 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

Re: non-relational DB

. if it already has such conversion code)? What's the status of the email backends ticket? There hasn't been any reply to Andi Albrecht's latest patch and comment. http://code.djangoproject.com/ticket/10355 This is essential for supporting all kinds of cloud platforms. Bye, Waldemar Kornewald

Re: non-relational DB

On Thu, Oct 22, 2009 at 2:07 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > > On Thu, Oct 22, 2009 at 7:46 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> >> Hi again, >> now a little question: >> >> Some fields do type conve

Re: non-relational DB

eryGlue, so maybe you should better reuse what we've started and finish that together with us, so we all don't waste time on refactoring everything twice? Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ You received this message because you are subscribed to the G

Re: non-relational DB

s will have to be manipulated and interpreted in order to emulate certain features (e.g., joins) and its much easier to do this on the final query tree than on its intermediate states. Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ You received this message b

Re: non-relational DB

On Mon, Oct 26, 2009 at 3:05 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > > On Mon, Oct 26, 2009 at 8:46 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> >> On Mon, Oct 26, 2009 at 1:12 PM, Russell Keith-Magee >> <freakboy3..

Re: non-relational DB

Hi, Russell and Alex, did you already look at QueryGlue? We really need to discuss which branch the new query_class() should be in. Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "D

Re: non-relational DB

ay, I hope you're much more likely to help. ;) Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ 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@googlegro

Re: Last chance to object to new features

ime) once I have a chance to give the patch a > final review. Thanks a lot, Russell! Andi, could you please add your App Engine email backend to our test project? Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ You received this message because you are subs

Re: non-relational DB

, Waldemar Kornewald -- 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

Re: Multiple database support: Request for feedback and testing

to define our own API in the non-relational branch. Bye, Waldemar Kornewald On Thu, Dec 3, 2009 at 5:10 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > Hi all, > > Alex Gaynor's GSoC project to add multiple database support to Django > is on the final straight. The only p

Re: Multiple database support: Request for feedback and testing

ose details. They should only provide a high-level abstraction to the DB that is as expressive and simple as possible. The details can be implemented via add-ons, so everyone can map the DB abstraction to his real DB setup. Bye, Waldemar Kornewald -- You received this message because you are subscri

Re: Multiple database support: Request for feedback and testing

Hi Russell, On Sat, Dec 5, 2009 at 2:58 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald <wkornew...@gmail.com> > wrote: >> On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee >> <freakboy3...@gmail.

help needed: non-relational DB support

into Django 1.3 (which is definitely possible, so please don't vote -1 next time if this is your only concern). I understand if you're currently busy with finishing 1.2, but if you're interested in helping when will you have time? Bye, Waldemar Kornewald -- http://twitter.com/wkornewald http

possible bug in model validation layer

/NULL. Do some DBs allow for a nullable pk or is the query executed unnecessarily? Bye, Waldemar Kornewald -- 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...@google

Re: help needed: non-relational DB support

the > functionality is mostly complete that other people offer help, mostly > in the form of testing. We are two developers who work closely together, but we don't feel very comfortable hacking through the SQL layer without any help. Bye, Waldemar Kornewald -- http://twitter.com/wkornewald h

Re: help needed: non-relational DB support

of the field values dictionary. In order to emulate JOINs we must store the column names of the primary keys used in the sql.Query instance. So, do you think this is a good path to take? Bye, Waldemar Kornewald -- http://twitter.com/wkornewald http://bitbucket.org/wkornewald/ http://allbutt

Re: help needed: non-relational DB support

e interested in adding MongoDB, CouchDB, and maybe SimpleDB support. The current code should be abstract enough for SimpleDB and probably also MongoDB (though, it would help to modify AutoField to also support string values). Other DBs might need additional changes, but that's what the "nonrel

Re: help needed: non-relational DB support

On Sun, Jan 17, 2010 at 5:36 AM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Sun, Jan 17, 2010 at 9:37 AM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> On Sat, Jan 16, 2010 at 10:35 PM, flo...@gmail.com <flo...@gmail.com> wrote: >>> I'm

Re: NoSQL Support for the ORM

at's inherently hard on a non-relational > database, besides not being able to "select_related" the parent. What if you filter on one field defined in the parent class and another field defined on the child class? Emulating this query would be either very inefficient and (for large datasets)

Re: [GSOC] NoSQL Support for the ORM

th Django. OTOH, if the goal is to make an abstraction around their indexes they can all look very similar from the perspective of Django's ORM (of course they have different "features" like sharding or eventual consistency or being in-memory DBs or supporting fast writes or reads or having trans

Re: NoSQL Support for the ORM

On Thu, Apr 8, 2010 at 6:14 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Wed, Apr 7, 2010 at 4:43 PM, Waldemar Kornewald <wkornew...@gmail.com> > wrote: >> On Wed, Apr 7, 2010 at 5:12 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: >>> No.

NoSQL Support for the ORM

rate package that adds these features. I'm just concerned that Alex' refactoring will make it more difficult or even impossible to implement an emulation layer because his goal is totally different. Bye, Waldemar Kornewald -- You received this message because you are subscribed to the Google Group

Re: NoSQL Support for the ORM

On Thu, Apr 8, 2010 at 11:03 PM, flo...@gmail.com <flo...@gmail.com> wrote: > On Apr 8, 12:32 pm, Waldemar Kornewald <wkornew...@gmail.com> wrote: > >> What I'm proposing is not a complete emulation of all features at all >> cost, but simply an automation o

Re: Some bugs in manage multidb

Hi Russell, On May 18, 1:59 pm, Russell Keith-Magee wrote: > On Tue, May 18, 2010 at 5:08 PM, Alberto Paro wrote: > > I'm developing a big application that does some complex mixing of database: > > SQL and notSQL one. > > I'm using the multidb to

Re: Some bugs in manage multidb

ango-nonrel feature set you could easily also support SimpleDB, CouchDB, Redis, and other backends. I don't see any missing features that stand in the way of achieving that goal. I hope our work can at least be used as a starting point for the GSoC NoSQL project. Bye, Waldemar Kornewald -- You

Re: Class based generic views in 1.3?

Maybe I missed something, but why don't you use __new__ instead of copying the instance? Bye, Waldemar On May 29, 11:06 pm, Ben Firshman wrote: > Luke, you're absolutely right that changing the definition of a view is a bad > idea, it just seemed the best solution then. >

Re: Class based generic views in 1.3?

On Jun 2, 11:31 pm, Luke Plant <l.plant...@cantab.net> wrote: > On Tuesday 01 June 2010 11:43:30 henning.schroe...@gmail.com wrote: > > > On May 30, 7:24 am, Waldemar Kornewald <wkornew...@gmail.com> wrote: > > > Maybe I missed something, but why don't you use

Re: Class based generic views in 1.3?

this instead: (r'', 'views.DetailView', {'queryset': Thing.object.all()}) Bye, Waldemar Kornewald -- 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

Re: Query Refactor Status Update

string to an AutoField will fail, so we'll need to find a solution for that (probably by fixing the unit tests). Bye, Waldemar Kornewald -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to dj

Re: Query Refactor Status Update

On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald <wkornew...@gmail.com> > wrote: >> Why did you revert the AutoField patch? BTW, in the Django-nonrel >> patch you'll find a few ot

Re: Query Refactor Status Update

On Tue, Jun 8, 2010 at 8:55 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Tue, Jun 8, 2010 at 12:11 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: >>> On Tue, Jun

Re: Query Refactor Status Update

On Thu, Jun 10, 2010 at 2:31 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Wed, Jun 9, 2010 at 4:25 AM, Waldemar Kornewald <wkornew...@gmail.com> > wrote: >> By not supporting string-based primary keys the MongoDB and SimpleDB >> communities will have

Re: Query Refactor Status Update

, anymore. Russell, please correct me if you meant something different. So, the question (as far as I understand) is whether the code above is actually used by so many developers that you could justify making NoSQL support a second-class citizen. Bye, Waldemar Kornewald -- You received this m

Re: Query Refactor Status Update

On Fri, Jun 11, 2010 at 5:25 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Thu, Jun 10, 2010 at 10:18 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> That's right. We believe that the long-term advantages of having a >> common AutoField f

Re: Class based generic views in 1.3?

code would unnecessarily instantiate the form two times if the form doesn't validate. Also, _load_config_values should guarantee that you don't pass unsupported arguments. This should also work with inheritance. Bye, Waldemar Kornewald -- You received this message because you are subscri

Re: Class based generic views in 1.3?

gets his own View instance. Instead of aa = AwesomeAdd() foo = aa(3, 5) the __new__-based approach allows to do this: foo = AwesomeAdd(3, 5) IOW, the "constructor" directly returns an HttpResponse (foo) instead of an AwesomeAdd instance. Bye, Waldemar Kornewald -- You received this

Re: Class based generic views in 1.3?

On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote: > On Thu, Jun 17, 2010 at 1:20 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> Please take a deeper look at his code. He doesn't use __init__. He >> uses __new__, so each requ

Re: Class based generic views in 1.3?

o rewrite the whole view from scratch to change a little detail. Bye, Waldemar Kornewald -- 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

Re: Class based generic views in 1.3?

On Thu, Jun 17, 2010 at 6:08 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote: > On Thu, Jun 17, 2010 at 2:08 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki <pat...@pld-linux.org> >> wrote: >>

Re: Class based generic views in 1.3?

On Thu, Jun 17, 2010 at 6:57 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote: > On Thu, Jun 17, 2010 at 6:49 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> The one-instance approach is no more thread-safe than having a global >> variable. In your e

Re: Class based generic views in 1.3?

re: * relatively easy for unit tests (new_instance()) * enforced thread-safety * no special code in Django's URL routing vs * no-brainer for unit tests * no enforced thread-safety (you can mistakenly create a global view instance) * special code in Django's URL routing Bye, Waldemar K

Re: Class based generic views in 1.3?

ummary spreadsheet. Feel free to change/extend it: https://spreadsheets.google.com/ccc?key=0AnLqunL-SCJJdGhxSVZaQkNCcTlzM2d4OEc5dFRPUUE=en Bye, Waldemar Kornewald -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Query Refactor Update

That's where the really interesting stuff begins. Bye, Waldemar Kornewald -- 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 grou

proposal: abstract file upload/download handling

to handle any kind of upload/download solution? Or should the admin interface try to use django-filetransfers if it's available (probably not; just thinking aloud)? Bye, Waldemar Kornewald -- You received this message because you are subscribed to the Google Groups "Django developers&q

Re: proposal: abstract file upload/download handling

web server can become unresponsive. Bye, Waldemar Kornewald -- 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 d

Re: proposal: abstract file upload/download handling

On Tue, Jun 22, 2010 at 2:40 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Tue, Jun 22, 2010 at 2:55 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: > My initial impression of django-filetransfers is that you've > constructed a lot of very complex

Re: proposal: abstract file upload/download handling

On Wed, Jun 23, 2010 at 2:58 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Wed, Jun 23, 2010 at 2:58 AM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> On Tue, Jun 22, 2010 at 2:40 PM, Russell Keith-Magee >> <russ...@keith-magee.com> wro

Re: proposal: abstract file upload/download handling

On Wed, Jun 23, 2010 at 11:06 PM, Robert Coup <robert.c...@koordinates.com> wrote: > On Thu, Jun 24, 2010 at 4:24 AM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> FileField gets a new method prepare_upload() which takes the following >> arguments: >> *

Re: proposal: abstract file upload/download handling

On Thu, Jun 24, 2010 at 1:12 PM, Luke Plant <l.plant...@cantab.net> wrote: > On Thu, 2010-06-24 at 08:40 +0200, Waldemar Kornewald wrote: > >> The boolean is sufficient because those permission checks should be >> done in the download v

Re: proposal: abstract file upload/download handling

Hi again, so, does the proposal look fine for now, so I can actually make a patch or can you already tell me now that there is a problem which needs to be solved, first? Bye, Waldemar Kornewald -- You received this message because you are subscribed to the Google Groups "Django devel

Re: Class based generic views in 1.3?

scended > into bikeshedding territory. I'm going to read through everything > posted so far and try to post a summary and round-up to help us get > refocused; gimme a few hours to pull that together and then let's try > to reach towards a consensus. Any results? Bye, Waldemar Kornewald --

Re: proposal: abstract file upload/download handling

odel/field combination. As a fallback DEFAULT_STORAGE_BACKEND is used. The API is also similar to DB routers. If any of those functions returns None the next backend is tried (as defined in settings.FILE_BACKENDS). Please provide some feedback. Does this solve all issues you had with the API? Bye, Waldemar

Re: proposal: abstract file upload/download handling

On Thu, Jul 22, 2010 at 4:30 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sun, Jul 18, 2010 at 1:59 AM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> Hi Russell, >> so, after our chat on IRC I've finally found the time to implement a >>

Re: Django, The Web Framework for perfectionists and innovative with rechargeable batteries.

an equivalent in Django's ORM before they're implemented, but it should be possible to provide separate functions for those features, too. I'm just asking because I'm interested in hearing from other people which problems we need to solve to make Django-nonrel and Django's official NoSQL proj

Re: proposal: abstract file upload/download handling

kend', } If you need more control you can use FILE_TRANSFER_BACKENDS which works more like the routers API. Bye, Waldemar Kornewald -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- You received this message becau

Re: proposal: abstract file upload/download handling

On Sat, Aug 14, 2010 at 1:45 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Thu, Jul 22, 2010 at 4:30 AM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> I accept the need for this, but this seems like a bit of a wart. This >> method wouldn't

Re: proposal: abstract file upload/download handling

No comments means it's still not good enough and I'll never get it into an acceptable shape? :) Bye, Waldemar On Sun, Aug 15, 2010 at 7:13 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Sat, Aug 14, 2010 at 1:45 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote:

Re: Query Refactor Final Status Update

shed. Ideally, also upsert support would be added (it's very easy to do, anyway). At some point we'll also need a solution for delegating the deletion of related objects to the backend. This is needed at least for App Engine, probably also for HBase, and maybe for some other DBs with transaction suppor

Re: Query Refactor Final Status Update

. If someone uses a NoSQL backend the new validation behavior would be enabled automatically. Bye, Waldemar Kornewald -- 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 subscribe

Re: proposal: abstract file upload/download handling

How often should I ping, so my patch won't be forgotten? :) On Thu, Aug 19, 2010 at 9:38 AM, Jannis Leidel <jan...@leidel.info> wrote: > Am 19.08.2010 um 01:50 schrieb Waldemar Kornewald: > >> No comments means it's still not good enough and I'll never get it >>

four NoSQL backends you want? :)

effort and allow us to reuse our existing unit tests and project code. Bye, Waldemar Kornewald -- 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 unsubs

Re: four NoSQL backends you want? :)

On Sep 25, 4:21 pm, Russell Keith-Magee wrote: > My reason for wanting this is that I'm simply not an expert in any of > these backends. I know SQL quite well, but I haven't had occasion to > try out other backends in depth. I can judge the technical merits of a > patch

Re: four NoSQL backends you want? :)

On Sun, Sep 26, 2010 at 6:54 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sun, Sep 26, 2010 at 1:24 AM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> On Sep 25, 4:21 pm, Russell Keith-Magee <russ...@keith-magee.com> >> wrote: >&g

Re: #6735 -- Class based generic views: call for comment

magical than having non-obvious thread-safety due to copy(). None of the solutions are perfect, but IMHO the thread- safety advantages of the __new__ approach (i.e., internal state created in __init__ is thread-safe) outweigh this minor detail because bugs due to thread-safety issues are

contrib.staticfiles app concerns

er off using a different solution, anyway. BTW, I noticed a bug in the staticfiles view: It checks for "if settings.DEBUG", but that should be "if not settings.DEBUG". Also, staticfiles doesn't index "media" folders although the admin uses "media" instead

Re: contrib.staticfiles app concerns

Hi Carl, On Wed, Oct 20, 2010 at 10:53 PM, Carl Meyer <carl.j.me...@gmail.com> wrote: > Hi Waldemar, > > On Oct 20, 4:04 pm, Waldemar Kornewald <wkornew...@gmail.com> wrote: >> That's a funny combination of tools. :) >> You don't really need django

Re: contrib.staticfiles app concerns

On Wed, Oct 20, 2010 at 10:13 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Wed, Oct 20, 2010 at 3:04 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> I wish that were the case. The staticfiles documentation says: >> >> """ &g

Re: contrib.staticfiles app concerns

On Thu, Oct 21, 2010 at 5:25 AM, Jannis Leidel wrote: >> The core 'django.views.static.serve' and >> 'django.core.context_processors.media' are deprecated in favor of the >> staticfiles equivalents in contrib. Is the idea that the contrib app is a >> stepping stone to

Re: contrib.staticfiles app concerns

Hi Jakob, On Thu, Oct 21, 2010 at 5:10 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Thu, Oct 21, 2010 at 3:50 AM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> With this reasoning we could as well add django-debug-toolbar, South, >> django-regis

Re: contrib.staticfiles app concerns

t solution. It should be easy to adapt the code in django-mediagenerator and make a little patch for staticfiles, so it behaves like (4). What do you think? In any case, staticfiles would need to rewrite URLs in its view, too. Otherwise we can't provide a consistent solution across all asset man

Re: contrib.staticfiles app concerns

On Thu, Oct 21, 2010 at 10:09 PM, Jacob Kaplan-Moss wrote: > On Thu, Oct 21, 2010 at 2:33 PM, Tobias McNulty > wrote: >> Ah, so realistically we should put all our media in 'static/', like >> for templates, if we want to avoid conflicts with other

Re: contrib.staticfiles app concerns

On Thu, Oct 21, 2010 at 10:04 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Thu, Oct 21, 2010 at 1:25 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> My proposal would've been to not add staticfiles in the first place, >> but it seems to be t

Re: contrib.staticfiles app concerns

On Thu, Oct 21, 2010 at 11:43 PM, Jannis Leidel wrote: >> Is staticfiles supposed to put "app/static/style.css" into >> "/style.css" or "/app/style.css"? Currently it behaves >> like the latter, but if it should behave like Django's templates we >> need to fix the code. > >

Re: contrib.staticfiles app concerns

On Thu, Oct 21, 2010 at 10:48 PM, Luke Plant <l.plant...@cantab.net> wrote: > On Thu, 2010-10-21 at 20:25 +0200, Waldemar Kornewald wrote: > > To fully support one of the other assets managers you mention, we would > need the admin and all contrib apps to get on board and use t

Re: contrib.staticfiles app concerns

On Thu, Oct 21, 2010 at 10:10 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > OK, I just went through django-mediagenerator to check if there's > anything else needed by staticfiles and I noticed that we need to have > a standard for URLs in CSS files (e.g., url(image.png)

Re: contrib.staticfiles app concerns

Hi Mikhail, On Wed, Oct 27, 2010 at 1:14 PM, Mikhail Korobov wrote: > Hi Waldemar, > > Could you explain why is this should belong to django staticfiles app? > This app has nothing to do with combining css files. It has one view > (django.contrib.staticfiles.views.serve)

Re: contrib.staticfiles app concerns

2010/10/27 Mikhail Korobov : > Why isn't it fine to have different URL rewriting schemes for > different assets bundlers? OK, sorry for not having explained it well. What I mean is this: Imagine this code snippet in a reusable app's CSS file: /* myapp/style.css */

Re: contrib.staticfiles app concerns

Hi Yuri, On Thu, Oct 28, 2010 at 6:19 AM, burc...@gmail.com <burc...@gmail.com> wrote: > Hi Waldemar, > > On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> 2010/10/27 Mikhail Korobov <kmik...@googlemail.com>: >>

Re: contrib.staticfiles app concerns

r to an image. It's never ambiguous. BTW, method (4) has the same behavior as Django's templates: {% extends %} and {% include %} are relative to the root template folder, not the source file. The only advantage of (2) is that it works more like what most developers are used to when working

Re: contrib.staticfiles app concerns

On Thu, Oct 28, 2010 at 4:41 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > What's the problem with all of this? Code written for (1) is > incompatible with code written for (2) which is incompatible with code > written for (4). The asset managers listed on djangop

Re: contrib.staticfiles app concerns

Hi Carl, On Fri, Oct 29, 2010 at 5:18 AM, Carl Meyer wrote: > Hi Waldemar, > > Thanks for putting so much thought into this issue, and outlining > these options in detail. However, I am not convinced that this > something Django core should be concerned with. I think we

Re: contrib.staticfiles app concerns

Hi Yuri, On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com <burc...@gmail.com> wrote: > Hi Waldemar, > > On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> Hi Carl, >> >>> As I read it, your option 4 means putting

  1   2   >