Re: prepopulated_fields javascript error since r14123

[Simon Meers]

On 30 October 2010 07:50, Andrew Godwin  wrote:

>
>  It's working fine for me on my freshly-updated 1.2.X branch - did you make
> sure the caches were clear, etc, etc?
>


Yes, and I'd experienced it on several different
servers/projects/client-machines. Yet I've just tested it on a new project
also, and it seems to be fine, as you say. I've discovered that in one of
the projects someone had set up a
"templates/admin/prepopulated_fields_js.html" template (why?!) which
contained the old javascript join code! No idea what the cause was on the
other projects, but I'm guessing the core code is fine; sorry for the
confusion.

-- 
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: prepopulated_fields javascript error since r14123

[Andrew Godwin]

On 27/10/10 12:15, Simon Meers wrote:
> On 27 October 2010 19:40, Andrew Godwin  > wrote:
>
> On 27/10/10 07:01, Simon Meers wrote:
>
> Has anyone else found that using prepopulated_fields in
> admin.ModelAdmin since r14123 produces a javascript error:
> "d.join is not a function"?
>
>
> I didn't get any errors when I tested the patch before commit -
> are you having them on the 1.2.X backport, or the main trunk version?
>
>
> On the 1.2.X backport; that sounds likely to be the reason it hasn't
> been picked up.
>

It's working fine for me on my freshly-updated 1.2.X branch - did you
make sure the caches were clear, etc, etc?

Andrew

-- 
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

[Jacob Kaplan-Moss]

On Fri, Oct 29, 2010 at 11:26 AM, Waldemar Kornewald
 wrote:
> (see attachment which "implements" method (2) :).

OK.

For the record, I really don't want to be a dick here, but I think
what follows comes across that way. I'm quite sorry for not being able
to communicate myself in a less jerk-y way; hopefully you won't be too
offended.

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.

You're proposing that we hit them over the head with this need to
evaluate asset managers (whatever those are) for standards compliance
(whatever that means) and you're chastising them for not understanding
what's going on. Then you mention an "official Django standard"
without mentioning what that standard is. Worse, we've never had
"official Django standards" before, and I'm sure not going to start
with anything that high-falutin' now.

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.

At this point I'm checking out of this conversation until I see an
*actual* bug report from an *actual user. If you'd like to propose a
standard for asset managers go right ahead -- you've got a blog and
plenty of clout. If it catches on, maybe we'll add something to the
docs. Later.

Jacob

-- 
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

[Waldemar Kornewald]

Hi Carl,

On Fri, Oct 29, 2010 at 7:41 PM, Carl Meyer  wrote:
> Hi Waldemar,
>
> On Oct 29, 3:05 am, Waldemar Kornewald  wrote:
>> Just to clarify: We are in fact talking about two questions here:
>> 1. Do we need a standard for URL handling?
>>
>> This is the most important question and my answer is "yes" (I'll
>> explain this in the rest of this mail).
>
> I don't think we need a single end-to-end, all-encompassing standard
> that tries to cover every possible use case (including Sass, SCSS,
> etc). Rather than astronaut-architecting an entire hypothetical asset-
> handling system for all Django users, I think we need to separate the
> individual potential steps in the asset-handling toolchain and be
> clear about which of those steps Django is opinionated about, and
> which it is not. The only conclusion of this that seems reasonable to
> me does look like your option (2); I'm fine with calling that a
> standard. I don't believe this standard actually requires documenting
> (as in your patch), because it's obvious: if your reusable app
> provides CSS files and images, they should work out of the box as
> provided, and not rely on any other third-party tool (unless, of
> course, you document that reliance, which reduces the reusable appeal
> of your app, but is your choice).

I believe that the standard requires documenting because, as mentioned
in a previous mail, only two of the seven combining asset managers on
djangopackages.com comply with option (2). IOW, more than 70% of the
listed asset managers use an incompatible method! So, it doesn't seem
to be as obvious as you might suggest. We won't get the desired result
without documenting and promoting this standard.

>> So, should we
>> * use the same method (4) for CSS and Sass/etc.? (+consistency, -familiarity)
>> * use method (2) for CSS and method (4) for Sass/etc.? (-consistency,
>> +familiarity)
>
> Framed in your terms, clearly the latter. Let me try to sum up my
> perspective:
>
> It's a basic architectural principle that in order to build a working
> large and complex system, you break it down into smaller parts, and
> ensure that each part of the system takes care of its own
> responsibility, and needs to know as little as possible about the
> other components of the system in order to do so. This reduces
> interdependence and increases modular reusability. Here are the parts
> that have been touched on in this thread, and the responsibility of
> each one as I see it, arranged such that each piece depends only on
> knowledge of a single other piece:
>
> 1. Reusable apps should put their media in static/appname/ and expect
> it to be available at STATICFILES_URL/appname/. This is implicitly
> endorsed by Django due to the inclusion of staticfiles, though of
> course it is not required.
> 2. If reusable apps include CSS that links to images or other media,
> it should work as provided, given only the assumption in (1). (In
> practice this means relative links, since we don't know the value of
> STATICFILES_URL in advance). This is also implicitly endorsed by
> Django, simply because it does not do any link-rewriting: if your
> provided CSS is broken, Django doesn't fix it for you.
> 3. A media compressor/combiner should take working input CSS (2) and
> generate working output CSS.
> 4. A Sass/SCSS compiler should generate working CSS (2). How it
> chooses to do so, and what that means for how the Sass/SCSS itself is
> written, is an internal concern of this part of the system that should
> not spill over into other parts of the system.
>
> I believe in practice this does correspond to what you are calling
> "option 2 for CSS, option 4 for Sass."  When I look at the
> responsibilities of each part of the system independently, I can't
> honestly see any other conclusion that makes sense. Parts 3 and 4 are
> entirely external to Django; if an app wants to do things differently,
> it's free to do so, and should document its requirements. But if
> you're asking me about establishing a standard expectation for those
> areas, this is what I would expect from apps that I would choose to
> use.

Yes, that's method 2 for CSS and method 4 for Sass. I'm fine with
using that. At least, the larger user group still only uses CSS and
it's probably more important to comply with their expectations (which
is method 2).

Like I said above, I think that at least part 3 must be actively dealt with.

Part 4 would be a nice bonus since it allows easily reusable
open-source apps with Sass/etc. files. Currently, django-compressor
uses method (2) for LESS. I'm not sure about django-static, but it
might use method (2), too (at least it does for normal CSS files). I'm
sure you agree that method (2) doesn't make sense for CSS compilers
(in particular with @import). In this case method (4) is the better
option. Let's please not ignore this problem and instead promote
method (4) as the official standard for Sass/LESS/etc. Any 

Re: Gentle Proposal: add 'render' shortcut in 1.3

[Carl Meyer]

On Oct 29, 2:04 pm, Ivan Sagalaev  wrote:
> Aha, I see the point now. On a second thought I think we can avoid this
> problem altogether by not passing actual response object into
> middleware. Instead we could pass just those bits that a middleware
> should care about: a template name and a context instance. The
> middleware then may (or even must) return new values for those that
> would be placed back into the response by the request handler.

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.

Carl

-- 
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

[Ivan Sagalaev]

On 10/29/2010 09:58 AM, Russell Keith-Magee wrote:

I agree that it's important to treat people as grown ups. However,
this is something that is trivial to do by accident -- for example,
printing response.content would be an obvious debug step -- and it
will be a non-trivial thing to identify that this is the cause of your
problems.


Aha, I see the point now. On a second thought I think we can avoid this 
problem altogether by not passing actual response object into 
middleware. Instead we could pass just those bits that a middleware 
should care about: a template name and a context instance. The 
middleware then may (or even must) return new values for those that 
would be placed back into the response by the request handler.


Something still bothers me about it, but I can't invent any real 
objections myself.


--
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

[Carl Meyer]

Hi Waldemar,

On Oct 29, 3:05 am, Waldemar Kornewald  wrote:
> Just to clarify: We are in fact talking about two questions here:
> 1. Do we need a standard for URL handling?
>
> This is the most important question and my answer is "yes" (I'll
> explain this in the rest of this mail).

I don't think we need a single end-to-end, all-encompassing standard
that tries to cover every possible use case (including Sass, SCSS,
etc). Rather than astronaut-architecting an entire hypothetical asset-
handling system for all Django users, I think we need to separate the
individual potential steps in the asset-handling toolchain and be
clear about which of those steps Django is opinionated about, and
which it is not. The only conclusion of this that seems reasonable to
me does look like your option (2); I'm fine with calling that a
standard. I don't believe this standard actually requires documenting
(as in your patch), because it's obvious: if your reusable app
provides CSS files and images, they should work out of the box as
provided, and not rely on any other third-party tool (unless, of
course, you document that reliance, which reduces the reusable appeal
of your app, but is your choice).

> > 1. Not all projects want or need to combine/compress their media at
> > all, and there is no reason they should have to run their CSS through
> > a URL-rewriting filter.
>
> When your CSS files are split into different locations via apps and
> generated via manage.py collectstatic and served via the staticfiles
> view it makes no real difference *from a tools perspective*. You
> already depend on those extra tools/filters, anyway. Your point 3
> below is about the human perspective which is the real problem here.

There is a sharp line in my mind between a tool that collects files
into a single tree, and a tool that looks inside the files and munges
their contents. The latter dramatically increases the surface area for
something to go wrong. While I personally use tools that do both, I
think it is appropriate for Django itself to provide a tool that does
the former, and strictly avoid the latter. Standardizing on your
option (4) would require adding url-munging to staticfiles, or else
requiring the use of a third-party tool; I am strongly -1 to either of
those.

> > 2. Even in projects that do combine/compress media, there are good
> > reasons to want to serve the individual files directly in development
> > (to aid in front-end debugging), and only do the combining/compressing
> > step on deployment to staging/production.
>
> django-mediagenerator and several other asset managers have a view
> which takes care of serving media uncombined and uncompressed during
> development for exactly that reason (easier debugging).

And if you write CSS that works as-is, you can now do this without
using any tool outside of Django itself (and if you use a combining/
compressing tool, you can simply disable it in development if you
want, rather than still needing it to rewrite your internal links for
you).

> If you're not yet using a professional asset manager you really try
> one. It can provide a noticeable speed boost (beyond just
> combining/compressing media) by utilizing the browser's cache
> perfectly and it can also help you during development.

Implicitly denigrating competing tools does not move the discussion
forward.

> > 3. Designers and front-end developers working on Django projects
> > should not have to learn some odd way of linking in their CSS, that
> > appears to be wrong according to everything they know about how things
> > usually work. The links they write should make sense to them, not just
> > to some Python developer who invented a new "standard" for them.
>
> I see the point you're trying to make and I don't like that solution
> (4) breaks with an existing convention, either. There's still the
> other option of going with (2) for CSS and with (4) for Sass/etc. It's
> just inconsistent and this becomes even more confusing if you use some
> language with CSS-like syntax (e.g., SCSS).

I don't think that it is at all inconsistent to expect working CSS;
anyone using Sass/SCSS simply needs to figure out how to use that tool
such that it generates working CSS.

> > 1. Links in static files should be written in such a way they work as-
> > is, without knowing what root URL they will be served under (this
> > means relative internal links).
> > 2. Any third-party tool that combines/compresses CSS should be able to
> > take working input files and generate working output files, handling
> > whatever internal links it finds correctly.
>
> I agree with 1. I also fully agree that 2 *should* work the way you
> described. However, without a standard it can't and in fact this very
> moment it doesn't. Depending on your asset manager you might use
> method (1) or (2) or (4) and thus use different URL paths than some
> other developer. We already have this problem right now: CSS files
> created for 

Re: contrib.staticfiles app concerns

[Waldemar Kornewald]

Hi Jacob,

On Fri, Oct 29, 2010 at 4:58 PM, Jacob Kaplan-Moss  wrote:
> Hi Waldemar --
>
> Like a few in this thread, I'm really having trouble understanding
> exactly what you're proposing. I think the best thing, then, would be
> if you could write some code to do whatever it is you'd like.
>
> Just a proof-of-concept is totally fine -- I don't mean to ask you to
> invest a lot more time than you already have -- but I think I need to
> actually see a patch (and perhaps an example of how the functionality
> would be used?) to understand what it is you'd like to see happen
> here.

OK, so you are thinking in terms of code. A standard doesn't have to
be in code. The standard I'm talking about is primarily about
communication done officially by Django, not code that lives in Django
core. In order to explain it better I guess I have to send a patch, so
here it goes (see attachment which "implements" method (2) :). I see
no better way to make it clear what I mean with having a standard for
reusable open-source apps. Take a look at the patch, please. I'm sure
you're shocked, now, and I hope that my whole intention becomes clear:
We need a standard to write reusable open-source apps, so the
community can share more code easily.

If we ignore the standard, the real issue will become apparent when
the first developers start to publish reusable open-source apps and
others start reporting bugs about incompatible CSS files. At that
point it will be clear that just putting staticfiles into Django is
not enough to guarantee that reusable apps are truly reusable (without
extra forking and maintenance effort).

Now, if my intention has become clear, these questions need to be answered:
1. How should URLs be rewritten according to the standard? Using
method (2) or (4)?
2. Should we have a standard for Sass/etc., so reusable open-source
apps can use those, too?
3. Is it a good idea to have conflicting conventions for CSS vs
Sass/etc. (method (2) vs (4), respectively) or is it better to have
just one convention for everything (method (4))?

These questions probably don't affect internally-used apps, but I
believe they are very important for the Django open-source community.

Bye,
Waldemar

-- 
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.



ridiculous-patch.diff
Description: Binary data

Re: contrib.staticfiles app concerns

[Jacob Kaplan-Moss]

Hi Waldemar --

Like a few in this thread, I'm really having trouble understanding
exactly what you're proposing. I think the best thing, then, would be
if you could write some code to do whatever it is you'd like.

Just a proof-of-concept is totally fine -- I don't mean to ask you to
invest a lot more time than you already have -- but I think I need to
actually see a patch (and perhaps an example of how the functionality
would be used?) to understand what it is you'd like to see happen
here.

Thanks,

Jacob

-- 
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

[Harro]

I agree, if you want to compress/combine css javascript whatever it's
up to the app/tool that does this to fix relative paths and other
issues that arrise when compressing/combining files.
It has nothing to do with the serving of the files.

On Oct 29, 12:04 pm, "burc...@gmail.com"  wrote:
> Hi Waldemar,
>
> On Fri, Oct 29, 2010 at 4:19 PM, Waldemar Kornewald
>
>
>
>  wrote:
> > Hi Yuri,
>
> > On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com  
> > wrote:
> >> Hi Waldemar,
>
> >> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
> >>  wrote:
> >>> Hi Carl,
>
>  As I read it, your option 4 means putting URLs into CSS files that
>  will not resolve correctly if static files are served directly,
>  unmodified, from their source locations (after being collected from
>  apps) under STATICFILES_URL (because the URLs you give don't begin
>  with a slash, so they will be interpreted as relative to the current
>  location; and if they did begin with a slash, that would break anytime
>  STATICFILES_URL is not a path-less domain). In other words, you are
>  proposing to write CSS files that _depend_ on being run through some
>  kind of combiner/compressor/filter that will intelligently rewrite all
>  their URLs relative to STATICFILES_URL. As a proposal for a
>  "standard," this is a non-starter for several reasons:
> >> Do you agree with that "you are proposing to write CSS files that
> >> _depend_ on being run through some kind of combiner/compressor/filter
> >> that will intelligently rewrite all their URLs relative to
> >> STATICFILES_URL"?
>
> > I keep getting misunderstood, so I'll just simplify it. Forget all my
> > proposals. My primary proposal is:
> > "Let's have exactly one official standard, no matter if it's (2) or (4)."
> > What I don't want is (1), (2), and (4) living side-by-side as they do now.
>
> > Do you agree that we should have a standard?
>
> Just a standard? Or standard for some problem related to django?
>
> > If the answer is "yes", then which one should it be?
> > A: (4) for CSS and Sass/etc.
> > B: (2) for CSS, (4) for Sass/etc.
>
> >> If you do, then you understand that you're trying to impose a standard
> >> for django users that is really unnecessary for them?
> >> You're free to allow such perversion with your app, but please don't
> >> try to put this into django.
>
> >> Why can't you read css files, transform their paths to absolute, merge
> >> files, and then write paths back as relative to merged files?
>
> > That's method (2) which only works well for CSS.
>
> Django doesn't support Sass.
> Django doesn't support media compression.
> Why django should have this stupid standard?
>
> Related to your media compressor, i'd prefer not (2) or (4), i prefer
> this one I described above:
> 1. Your compressor starts after media is gathered with staticfiles
> into a single place. (All relative paths are valid at this moment!)
> 2. You read css files, transform their url paths to absolute, merge
> files, and then write back into user specified directory with paths
> rewritten as relative to merged files location.
> 3. If you're copying images, you can put images to whatever folder you
> want, but they should still work.
> Your compressor should make it possible to work after your compression
> if you'll just put that folder to media server.
>
> That way, every compressor is compatible with each other if their
> output is set to compressor-specific folder.
> This doesn't impose any standard of writing urls in their files on
> django users -- they do what they did before they have any staticfiles
> support.
>
> --
> 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: Non-SQL database cache backend

[Russell Keith-Magee]

On Fri, Oct 29, 2010 at 9:18 PM, Jonas H.  wrote:
> Hi folks,
>
> upon the recommendation on the django-nonrel mailing list, I'll re-post my
> original question here:
>
> -- Begin original message --
> I just tried to use MongoDB as cache backend (only for development ;-) but
> it failed because apparently the Django guys do hand-written SQL in the
> database cache backend, probably for the sake of performance.
>
> Of course I could write a MongoDB cache backend myself -- which probably
> wouldn't be /that/ hard -- but isn't database abstraction the job for
> Django's database framework? [...]
> -- End original message --
>
> How do think about that? I'm sure a very thin abstraction layer would
> suffice. Or, if possible (I'm not /that/ deep into the Django ORM, so I
> can't tell), some small part of the ORM's query abstraction could be used so
> the database backend would not require a certain type of database?

You're correct -- we *could* use Django's ORM for the cache backend.
However, we haven't -- and for good reason.

Caching is, by very definition, something that needs to be speed
optimized. The queries required by a cache backend are very simple,
and need to run as fast as humanly possible -- otherwise you're
missing the purpose of having a cache.

If we were to use the ORM for the cache backend, the gain in
readability would be minor, and while the overhead of using the ORM is
small, it is non-zero, and when you're talking about caching, every
little bit counts.

Writing a MongoDB (or any other non-SQL) cache backend shouldn't be a
particularly onerous task; after all, the queries are simple, and the
.The SQL backend is only 150 lines of code; a backend for any noSQL
backend should run to about the same line count.

An abstraction layer might be possible, but if you look at the source
code for the DB backend, there isn't much there that isn't raw SQL
anyway -- the cache backend essentially *is* the abstraction layer.

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.

Non-SQL database cache backend

[Jonas H.]

Hi folks,

upon the recommendation on the django-nonrel mailing list, I'll re-post 
my original question here:


-- Begin original message --
I just tried to use MongoDB as cache backend (only for development ;-) 
but it failed because apparently the Django guys do hand-written SQL in 
the database cache backend, probably for the sake of performance.


Of course I could write a MongoDB cache backend myself -- which probably 
wouldn't be /that/ hard -- but isn't database abstraction the job for 
Django's database framework? [...]

-- End original message --

How do think about that? I'm sure a very thin abstraction layer would 
suffice. Or, if possible (I'm not /that/ deep into the Django ORM, so I 
can't tell), some small part of the ORM's query abstraction could be 
used so the database backend would not require a certain type of database?


Cheers,
Jonas

--
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: Papal module configuration in SATCHMO module

[Gary Bernard]

Have you setup a paypal test site? This is required. Satchmo pretty  
much needs nothing to work with Paypal.
Just set it up and activate. But the Paypal account is required and a  
sandbox account, to test, also needs to be created. Have you done that?


Gary Bernard

Bernard Design

232 E 33rd Place
Tulsa, OK 74105

918-629-1932
918-749-0075 (fax - please call first)

g...@bernarddesign.com

http://bernarddesign.com

On Oct 29, 2010, at 12:47 AM, Tariq Mahmood wrote:


Assalam O Alaikum

when i click for purchase item from my store following error appears.
please tell me what is the problem. is it any problem with satchmo
paypal module configuration

ERROR AT PAYPAL SAND BOX SITE

We cannot process this transaction because there is a problem with the
PayPal email address supplied by the seller. Please contact the seller
to resolve the problem. If this payment is for an eBay listing, you
can contact the seller via the "Ask Seller a Question" link on the
listing page. When you have the correct email address, payment can be
made at www.paypal.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 
.




--
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

[burc...@gmail.com]

Hi Waldemar,

> A standard for a problem related to Django: How can we have reusable
> apps that come with media files? How is that possible if everyone uses
> a different asset manager?
Ok, this is a problem related to Django, but it shouldn't be solved
with scope of Django because nothing in Django depends on this
decision. Now it is better?

> Unless I've misunderstood something, the Django team added
> django.contrib.staticfiles exactly because this app is supposed to
> solve the reusable-apps-with-media-files problem. We need a standard
> URL rewriting scheme for this.
>> Related to your media compressor, i'd prefer not (2) or (4), i prefer
>> this one I described above:
>> 1. Your compressor starts after media is gathered with staticfiles
>> into a single place. (All relative paths are valid at this moment!)
>> 2. You read css files, transform their url paths to absolute, merge
>> files, and then write back into user specified directory with paths
>> rewritten as relative to merged files location.
>> 3. If you're copying images, you can put images to whatever folder you
>> want, but they should still work.
>> Your compressor should make it possible to work after your compression
>> if you'll just put that folder to media server.
>
> This is method (2). :)
> It rewrites the URLs relative to the source files before merging
> (which is your step 2).
>
>> That way, every compressor is compatible with each other if their
>> output is set to compressor-specific folder.
>> This doesn't impose any standard of writing urls in their files on
>> django users -- they do what they did before they have any staticfiles
>> support.
>
> You say that you don't want a standard, but what you describe in your
> mail is a standard. :) What else would you call your three
> instructions above? They describe how to rewrite URLs according to
> (2).
I clearly said it's my preference.

> If you still don't agree then see it for yourself: Try to use
> *exactly* the same reusable app with *exactly* the same CSS files with
> three different asset managers which combine those app CSS files into
> a single file. Tell me if it works. You'll see it's impossible.
Who said this should work?

I understand you wants to get everyone happy, by taking a decision
instead of users.

-- 
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

[Waldemar Kornewald]

Hi Yuri,

On Fri, Oct 29, 2010 at 12:04 PM, burc...@gmail.com  wrote:
> Hi Waldemar,
>
> On Fri, Oct 29, 2010 at 4:19 PM, Waldemar Kornewald
>  wrote:
>> Hi Yuri,
>>
>> On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com  
>> wrote:
>>> Hi Waldemar,
>>>
>>> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
>>>  wrote:
 Hi Carl,

> As I read it, your option 4 means putting URLs into CSS files that
> will not resolve correctly if static files are served directly,
> unmodified, from their source locations (after being collected from
> apps) under STATICFILES_URL (because the URLs you give don't begin
> with a slash, so they will be interpreted as relative to the current
> location; and if they did begin with a slash, that would break anytime
> STATICFILES_URL is not a path-less domain). In other words, you are
> proposing to write CSS files that _depend_ on being run through some
> kind of combiner/compressor/filter that will intelligently rewrite all
> their URLs relative to STATICFILES_URL. As a proposal for a
> "standard," this is a non-starter for several reasons:
>>> Do you agree with that "you are proposing to write CSS files that
>>> _depend_ on being run through some kind of combiner/compressor/filter
>>> that will intelligently rewrite all their URLs relative to
>>> STATICFILES_URL"?
>>
>> I keep getting misunderstood, so I'll just simplify it. Forget all my
>> proposals. My primary proposal is:
>> "Let's have exactly one official standard, no matter if it's (2) or (4)."
>> What I don't want is (1), (2), and (4) living side-by-side as they do now.
>>
>> Do you agree that we should have a standard?
> Just a standard? Or standard for some problem related to django?

A standard for a problem related to Django: How can we have reusable
apps that come with media files? How is that possible if everyone uses
a different asset manager?

Unless I've misunderstood something, the Django team added
django.contrib.staticfiles exactly because this app is supposed to
solve the reusable-apps-with-media-files problem. We need a standard
URL rewriting scheme for this.

>> If the answer is "yes", then which one should it be?
>> A: (4) for CSS and Sass/etc.
>> B: (2) for CSS, (4) for Sass/etc.
>>
>>> If you do, then you understand that you're trying to impose a standard
>>> for django users that is really unnecessary for them?
>>> You're free to allow such perversion with your app, but please don't
>>> try to put this into django.
>>>
>>> Why can't you read css files, transform their paths to absolute, merge
>>> files, and then write paths back as relative to merged files?
>>
>> That's method (2) which only works well for CSS.
> Django doesn't support Sass.
> Django doesn't support media compression.
> Why django should have this stupid standard?

Because practically all asset managers for Django (except for
"staticfiles") do support media combining, and a standard is required
to make those asset managers compatible with each other, so we can
write reusable apps. No standard => no reusable apps.

You also can't ignore the growing number of web developers (I've seen
a poll saying 20%) who use CSS compilers like Sass. The number is
large enough to matter even for Django.

> Related to your media compressor, i'd prefer not (2) or (4), i prefer
> this one I described above:
> 1. Your compressor starts after media is gathered with staticfiles
> into a single place. (All relative paths are valid at this moment!)
> 2. You read css files, transform their url paths to absolute, merge
> files, and then write back into user specified directory with paths
> rewritten as relative to merged files location.
> 3. If you're copying images, you can put images to whatever folder you
> want, but they should still work.
> Your compressor should make it possible to work after your compression
> if you'll just put that folder to media server.

This is method (2). :)
It rewrites the URLs relative to the source files before merging
(which is your step 2).

> That way, every compressor is compatible with each other if their
> output is set to compressor-specific folder.
> This doesn't impose any standard of writing urls in their files on
> django users -- they do what they did before they have any staticfiles
> support.

You say that you don't want a standard, but what you describe in your
mail is a standard. :) What else would you call your three
instructions above? They describe how to rewrite URLs according to
(2).

Please take a look at the existing asset managers:
http://djangopackages.com/grids/g/asset-managers/
Only two of them use (2). All the others use (1) and (4). Where do you
see the compatibility here?

If you still don't agree then see it for yourself: Try to use
*exactly* the same reusable app with *exactly* the same CSS files with
three different asset managers which combine those app CSS files 

Re: New localflavor: Turkey

[Serkan Kenar]

Hello Ekrem,

Thanks for the review.

On Fri, Oct 29, 2010 at 2:39 PM, Ekrem SEREN  wrote:

>  3) Does the postal code field accurately capture all possible Turkish
>> postal codes?
>>
>
> I believe it does. I don't know any condition about postal codes other than
> they should be 5 digits.
>

As I said earlier, I'll add the province code check for the first two
digits. The complete list can be downloaded from the Turkish Post Office's
web site, there is no exception to this rule. (5-digits, first two are
province code).

>
>
>>  4) Does the phone number field accurately capture all possible
>> Turkish phone numbers?
>>
>
> It does. But I think it would be better to get them corrected to XX
> (10 digits long, no spaces, first 3 digits are area code and the rest is
> phone number) instead of 0XXX XXX.
>

> Leading "0" is an area code and there is no need to save it to database. If
> neccessary someone could write a filter to render it any way he likes.
>

You're right, I guess that's is better. I'll fix this too, together with the
tests.

Best regards,

-- 
Serkan Kenar

-- 
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: Start project not working

[David P. Novakovic]

Hello, this mailing list is to discuss the development of django itself.

Please use django-users for questions like yours :)

David

On Fri, Oct 29, 2010 at 4:03 PM, aravind  wrote:
> I installed python2.5 and django official
>
> version and also copied admin.py in
>
> scripts but when i use django admin-py
>
> startproject myproject is not working it
>
> s showing the following message
>
>
>
> Usage: django-admin.py subcommand
>
> [options] [args]
>
> Options:
>  -v VERBOSITY, --verbosity=VERBOSITY
>                        Verbosity level;
>
> 0=minimal output, 1=normal output,
>                        2=all output
>  --settings=SETTINGS   The Python path
>
> to a settings module, e.g.
>
>
> "myproject.settings.main". If this isn't
>
> provided, the
>
>
> DJANGO_SETTINGS_MODULE environment
>
> variable will be
>                        used.
>  --pythonpath=PYTHONPATH
>                        A directory to
>
> add to the Python path, e.g.
>
>
> "/home/djangoprojects/myproject".
>  --traceback           Print traceback
>
> on exception
>  --version             show program's
>
> version number and exit
>  -h, --help            show this help
>
> message and exit
>
> Type 'django-admin.py help '
>
> for help on a specific subcommand.
>
> Available subcommands:
>  cleanup
>  compilemessages
>  createcachetable
>  dbshell
>  diffsettings
>  dumpdata
>  flush
>  inspectdb
>  loaddata
>  makemessages
>  reset
>  runfcgi
>  runserver
>  shell
>  sql
>  sqlall
>  sqlclear
>  sqlcustom
>  sqlflush
>  sqlindexes
>
> --
> 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.
>
>

-- 
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.

Start project not working

[aravind]

I installed python2.5 and django official

version and also copied admin.py in

scripts but when i use django admin-py

startproject myproject is not working it

s showing the following message



Usage: django-admin.py subcommand

[options] [args]

Options:
  -v VERBOSITY, --verbosity=VERBOSITY
Verbosity level;

0=minimal output, 1=normal output,
2=all output
  --settings=SETTINGS   The Python path

to a settings module, e.g.


"myproject.settings.main". If this isn't

provided, the


DJANGO_SETTINGS_MODULE environment

variable will be
used.
  --pythonpath=PYTHONPATH
A directory to

add to the Python path, e.g.


"/home/djangoprojects/myproject".
  --traceback   Print traceback

on exception
  --version show program's

version number and exit
  -h, --helpshow this help

message and exit

Type 'django-admin.py help '

for help on a specific subcommand.

Available subcommands:
  cleanup
  compilemessages
  createcachetable
  dbshell
  diffsettings
  dumpdata
  flush
  inspectdb
  loaddata
  makemessages
  reset
  runfcgi
  runserver
  shell
  sql
  sqlall
  sqlclear
  sqlcustom
  sqlflush
  sqlindexes

-- 
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: New localflavor: Turkey

[Ekrem SEREN]

2010/10/29 Russell Keith-Magee 

> python runtests.py --settings=test_sqlite forms
>

This test run without error.

 1) Is the list of provinces complete and correct?
>

The list is complete and correct.


>  2) Is the use of integers the best key for this list? i.e., is there
> a better natural key, like US state abbreviations?
>

Yes. These integers are cars' license plate's first two digit in Turkey. So
if someone just see the key of the province s/he would know the province
name. (For example anyone would know that Istanbul's license plate code is
34)


>  3) Does the postal code field accurately capture all possible Turkish
> postal codes?
>

I believe it does. I don't know any condition about postal codes other than
they should be 5 digits.


>  4) Does the phone number field accurately capture all possible
> Turkish phone numbers?
>

It does. But I think it would be better to get them corrected to XX
(10 digits long, no spaces, first 3 digits are area code and the rest is
phone number) instead of 0XXX XXX.

Leading "0" is an area code and there is no need to save it to database. If
neccessary someone could write a filter to render it any way he likes.


>  5) Does the id number field accurately capture and validate all
> possible Turkish ID numbers?
>

It does. I've tested it with several real ID's.


>  6) Do the provided tests contain enough examples to validate that 3-6
> are correct?
>

Tests are ok. But phone number test could have some additional tests without
the leading zero:

self.assertEqual(f.clean("3124555678"), "0312 4555678")
self.assertEqual(f.clean("312 4555678"), "0312 4555678")
self.assertEqual(f.clean("312 455 56 78"), "0312 4555678")

Regards,
-- 
Ekrem SEREN

-- 
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: New localflavor: Turkey

[Serkan Kenar]

Hello Russel,

He has already contacted me in private for tests. I wanted to add my
comments here as well for the issues you raised so that Ekrem and others in
the Turkish community can also read them.

On Fri, Oct 29, 2010 at 4:58 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
>  1) Is the list of provinces complete and correct?
>  2) Is the use of integers the best key for this list? i.e., is there
> a better natural key, like US state abbreviations?
>

The integers are actually the license plate codes for the provinces. So they
are unique and common way to store province information. But there are some
provinces which are established later than the others are out of order. I
put the provinces in the alphabetical order, but the integer codes are not
ordered. I think this is more appropriate for the user.


>  3) Does the postal code field accurately capture all possible Turkish
> postal codes?
>

It does check only for a 5 digit number, it covers all possible postal
codes. I can add an additional check for the first two digits to be <= to 81
(the number of provinces).


Best regards,

-- 
Serkan Kenar

-- 
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: More efficient negative lookups

[andybak]

One small related point.

The admin could benefit from a way of doing negative lookups within
the lookup syntax itself.

Currently there is no way to construct an exclude filter change list
views in the URL.

i.e. If I am writing a custom filterspec or anything else that results
in a URL for a changelist page then I can do:

/admin/app/model/?model__id__exact=4

but I can't reverse the logic.

There might be better ways to allow this than just adding a negative
version of every lookup but I thought I'd throw another use case into
the ring.

Andy

-- 
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

[burc...@gmail.com]

Hi Waldemar,

On Fri, Oct 29, 2010 at 4:19 PM, Waldemar Kornewald
 wrote:
> Hi Yuri,
>
> On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com  wrote:
>> Hi Waldemar,
>>
>> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
>>  wrote:
>>> Hi Carl,
>>>
 As I read it, your option 4 means putting URLs into CSS files that
 will not resolve correctly if static files are served directly,
 unmodified, from their source locations (after being collected from
 apps) under STATICFILES_URL (because the URLs you give don't begin
 with a slash, so they will be interpreted as relative to the current
 location; and if they did begin with a slash, that would break anytime
 STATICFILES_URL is not a path-less domain). In other words, you are
 proposing to write CSS files that _depend_ on being run through some
 kind of combiner/compressor/filter that will intelligently rewrite all
 their URLs relative to STATICFILES_URL. As a proposal for a
 "standard," this is a non-starter for several reasons:
>> Do you agree with that "you are proposing to write CSS files that
>> _depend_ on being run through some kind of combiner/compressor/filter
>> that will intelligently rewrite all their URLs relative to
>> STATICFILES_URL"?
>
> I keep getting misunderstood, so I'll just simplify it. Forget all my
> proposals. My primary proposal is:
> "Let's have exactly one official standard, no matter if it's (2) or (4)."
> What I don't want is (1), (2), and (4) living side-by-side as they do now.
>
> Do you agree that we should have a standard?
Just a standard? Or standard for some problem related to django?

> If the answer is "yes", then which one should it be?
> A: (4) for CSS and Sass/etc.
> B: (2) for CSS, (4) for Sass/etc.
>
>> If you do, then you understand that you're trying to impose a standard
>> for django users that is really unnecessary for them?
>> You're free to allow such perversion with your app, but please don't
>> try to put this into django.
>>
>> Why can't you read css files, transform their paths to absolute, merge
>> files, and then write paths back as relative to merged files?
>
> That's method (2) which only works well for CSS.
Django doesn't support Sass.
Django doesn't support media compression.
Why django should have this stupid standard?

Related to your media compressor, i'd prefer not (2) or (4), i prefer
this one I described above:
1. Your compressor starts after media is gathered with staticfiles
into a single place. (All relative paths are valid at this moment!)
2. You read css files, transform their url paths to absolute, merge
files, and then write back into user specified directory with paths
rewritten as relative to merged files location.
3. If you're copying images, you can put images to whatever folder you
want, but they should still work.
Your compressor should make it possible to work after your compression
if you'll just put that folder to media server.

That way, every compressor is compatible with each other if their
output is set to compressor-specific folder.
This doesn't impose any standard of writing urls in their files on
django users -- they do what they did before they have any staticfiles
support.

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

On 29 окт, 10:09, Russell Keith-Magee  wrote:
>
> Ah - I wasn't aware there was a working implementation of this idea --
> did I miss a link somewhere?
>

No, there is no full working implementation. I'm talking about Ivan's
code snippet:

 response = get_response(...)
 if hastattr(response, 'force_bake'):
 # apply template response middleware
 response.force_bake()
 # apply normal response middleware

===

> If any template-response-middleware were to bake the
> response, subsequent template-reposnse-middlewares could potentially
> have problems, as any changes they make to context etc will be
> ignored.

Just realized that this is not correct. Changes won't be ignored but
the template will be rendered twice.

-- 
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: Ticket #7817: Extending "with" and "include" tags.

[Harro]

I would suggest also adding a way to exclude all context except items
specified with the with syntax.
(nocontext keyword or something like that).

Because sometimes I have certainly named items in my context which can
also be used in the included template but I don't want there. Sure you
can overwrite them one by one, but the faster and cleaner way would be
to exclude the whole context.


On Oct 29, 3:22 am, Russell Keith-Magee 
wrote:
> On Wed, Oct 27, 2010 at 3:46 PM, SmileyChris  wrote:
> > On Oct 27, 5:35 am, Łukasz Rekucki  wrote:
> >> I would like to bring this up again, because this is something that
> >> would really improve readability of my templates. I'm mainly
> >> interested in ticket #7817 (the include tag changes), but extending
> >> "with" tag (ticket 9456) would keep things consistent.
>
> > Here's a link to the ticket for the lazier ones among us:
> >http://code.djangoproject.com/ticket/7817
>
> > The main decision which needs to be made is one of syntax.
>
> > The current proposal uses:
> > {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
> > but this introduces an inconsistency with the {% with %} tag.
>
> > Consistency would be nice, but I think this starts to look a bit
> > confusing, static tokens outnumbering actual functional ones:
> > {% include "name_snippet.html" with name as "Joe" and greeting as
> > "Hello" %}
>
> > My proposal is that the current {% with name as "Joe" %} format
> > becomes the legacy format, and that the new format becomes (also
> > allowing for multiple arguments):
> > {% with name="Joe" greeting="Hello" %}
>
> > Other tags which currently use the "as" token are: cycle, regroup and
> > url. These all introduce a new variable into the current context,
> > which does differ slightly from how {% with %} alters a variable in a
> > contained scope. So my secondary (perhaps somewhat feeble) argument is
> > that this actually helps to keep the "as" token's behaviour more
> > consistent. :)
>
> > Thoughts?
>
> Repeating what I said to Chris in IRC for the benefit of posterity:
>
> I don't have any strong preference either way, but whatever style we
> pick, we need to be consistent.
>
> I can certainly appreciate the clarity and terseness of the "foo=bar
> pork=ham" syntax. My only concern would be whether it is too
> "programmery" for the intended audience of the template language. We
> have existing uses of the 'x=y' syntax -- such as in the {% url %}
> tag, so I don't think this should be a major concern.
>
> As David points out, the fact that {% blocktrans %} already does 'with
> X as Y and A as B' would seem to set a precedent for the verbose
> syntax. This verbose syntax is also syntactically consistent with what
> the {% with %} tag already does, so there's no need to introduce a
> 'legacy' format.
>
> I could swing either way on this. If we were starting with a clean
> slate, I'd prefer the terse syntax, and I think Chris provides a
> reasonable argument for how the usage of 'as' can be explained
> conceptually. However, the legacy issue and the precendent set by {%
> blocktrans %} provides a compelling argument to use the more verbose
> syntax.
>
> If we can introduce the terse syntax while maintaining the old syntax
> (including the analogous change in  blocktrans), I think it would be a
> worthwhile change. However, I certainly won't complain if public
> opinion sways the other way.
>
> 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: contrib.staticfiles app concerns

[Waldemar Kornewald]

Hi Yuri,

On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com  wrote:
> Hi Waldemar,
>
> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
>  wrote:
>> Hi Carl,
>>
>>> As I read it, your option 4 means putting URLs into CSS files that
>>> will not resolve correctly if static files are served directly,
>>> unmodified, from their source locations (after being collected from
>>> apps) under STATICFILES_URL (because the URLs you give don't begin
>>> with a slash, so they will be interpreted as relative to the current
>>> location; and if they did begin with a slash, that would break anytime
>>> STATICFILES_URL is not a path-less domain). In other words, you are
>>> proposing to write CSS files that _depend_ on being run through some
>>> kind of combiner/compressor/filter that will intelligently rewrite all
>>> their URLs relative to STATICFILES_URL. As a proposal for a
>>> "standard," this is a non-starter for several reasons:
> Do you agree with that "you are proposing to write CSS files that
> _depend_ on being run through some kind of combiner/compressor/filter
> that will intelligently rewrite all their URLs relative to
> STATICFILES_URL"?

I keep getting misunderstood, so I'll just simplify it. Forget all my
proposals. My primary proposal is:
"Let's have exactly one official standard, no matter if it's (2) or (4)."
What I don't want is (1), (2), and (4) living side-by-side as they do now.

Do you agree that we should have a standard?

If the answer is "yes", then which one should it be?
A: (4) for CSS and Sass/etc.
B: (2) for CSS, (4) for Sass/etc.

> If you do, then you understand that you're trying to impose a standard
> for django users that is really unnecessary for them?
> You're free to allow such perversion with your app, but please don't
> try to put this into django.
>
> Why can't you read css files, transform their paths to absolute, merge
> files, and then write paths back as relative to merged files?

That's method (2) which only works well for CSS.

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

[burc...@gmail.com]

Hi Waldemar,

On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
 wrote:
> Hi Carl,
>
>> As I read it, your option 4 means putting URLs into CSS files that
>> will not resolve correctly if static files are served directly,
>> unmodified, from their source locations (after being collected from
>> apps) under STATICFILES_URL (because the URLs you give don't begin
>> with a slash, so they will be interpreted as relative to the current
>> location; and if they did begin with a slash, that would break anytime
>> STATICFILES_URL is not a path-less domain). In other words, you are
>> proposing to write CSS files that _depend_ on being run through some
>> kind of combiner/compressor/filter that will intelligently rewrite all
>> their URLs relative to STATICFILES_URL. As a proposal for a
>> "standard," this is a non-starter for several reasons:
Do you agree with that "you are proposing to write CSS files that
_depend_ on being run through some kind of combiner/compressor/filter
that will intelligently rewrite all their URLs relative to
STATICFILES_URL"?

If you do, then you understand that you're trying to impose a standard
for django users that is really unnecessary for them?
You're free to allow such perversion with your app, but please don't
try to put this into django.

Why can't you read css files, transform their paths to absolute, merge
files, and then write paths back as relative to merged files?

-- 
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: RFC: issue 13617

[Russell Keith-Magee]

On Tue, Oct 26, 2010 at 8:00 AM, Benjamin Wohlwend  wrote:
> Hi,
>
> Russell, thanks for having a look at this. Much appreciated!
>
> On Mon, Oct 25, 2010 at 4:04 PM, Russell Keith-Magee
>  wrote:
>> Responding so that
>>
>> "localize off" is a much better approach to localize
>>
>>  1) I think there is still a need for a template filter. There's an
>> analog here with autoescape; there's an autoescape template tag for a
>> large block of content, but there's also an escape filter to escape a
>> single variable.
>
> The revised patch has a template filter. Not sure about using the same
> name as for the template tag, though.
>
>>
>>  2) activate() isn't a cheap operation; I know I put {% localize "de"
>> %} as a use case in the ticket, but on reflection, I'm not sure it's
>> worth the overhead. That said, I'm willing to be convinced otherwise
>> if there's a lot of demand for this feature.
>
> I agree that switching locale in the template rendering stage seems to
> be an obscure use case. I removed it for the time being.
>
>>
>>  3) The '_localize' magic variable in the context. It looks to me like
>> a better solution would be to pass down a 'localize' argument to
>> render. This is a little more intrusive to the codebase, but it
>> doesn't have the same code smell to me.
>
> I tried to implement this, but this puts me firmly into code paths I'm
> not comfortable messing with, especially with regard to backwards
> compatibility. I confined the `localization` argument to
> `VariableNode`'s with an `isinstance` check, but still, any third
> party `Node`s inheriting from `VariableNode` will not like this.
>
>>
>>  4) 'force' isn't a good description of the argument to date_format()
>> et al. I'd be inclined to extend the 'localize' argument from point
>> (2), and use a ternary logic value; True/False, plus None == use the
>> value of USE_L10N.
>
> Done. I named the argument `localization`, though. `localize` crashes
> with the `localize` function in `django.utils.formats`.

I've just done a polish of your patch. Looking at the changes required
by render() started to make me a little nervous, since they required
changing the API for render, so I went looking for a better way -- and
found it with autoescape. You don't have to create a context variable
to store something in the context. Given that localization is a core
concept in Django, keeping localization state in the context makes
sense, so I've modified your patch to use that approach.

I've also separated the tags into their own tag library, keeping the
analogy with the i18n tag library.

I've uploaded the patch to the ticket; I want to get a couple of key
people to comment on it before I commit, but with any luck this should
land in the next day or so.

Thanks for your work on this!

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: contrib.staticfiles app concerns

[Waldemar Kornewald]

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 need to
> maintain a clearer conceptual separation between the various layers of
> functionality here.

Just to clarify: We are in fact talking about two questions here:
1. Do we need a standard for URL handling?

This is the most important question and my answer is "yes" (I'll
explain this in the rest of this mail).

2. I'm suggesting that (4) should be the standard.

This is where you focused your reply and from this you somehow
concluded that the answer to the first question is "no". The code
examples in my previous mail show that we do need a standard
(independent of which method becomes the standard).

> As I read it, your option 4 means putting URLs into CSS files that
> will not resolve correctly if static files are served directly,
> unmodified, from their source locations (after being collected from
> apps) under STATICFILES_URL (because the URLs you give don't begin
> with a slash, so they will be interpreted as relative to the current
> location; and if they did begin with a slash, that would break anytime
> STATICFILES_URL is not a path-less domain). In other words, you are
> proposing to write CSS files that _depend_ on being run through some
> kind of combiner/compressor/filter that will intelligently rewrite all
> their URLs relative to STATICFILES_URL. As a proposal for a
> "standard," this is a non-starter for several reasons:
>
> 1. Not all projects want or need to combine/compress their media at
> all, and there is no reason they should have to run their CSS through
> a URL-rewriting filter.

When your CSS files are split into different locations via apps and
generated via manage.py collectstatic and served via the staticfiles
view it makes no real difference *from a tools perspective*. You
already depend on those extra tools/filters, anyway. Your point 3
below is about the human perspective which is the real problem here.

> 2. Even in projects that do combine/compress media, there are good
> reasons to want to serve the individual files directly in development
> (to aid in front-end debugging), and only do the combining/compressing
> step on deployment to staging/production.

django-mediagenerator and several other asset managers have a view
which takes care of serving media uncombined and uncompressed during
development for exactly that reason (easier debugging).

If you're not yet using a professional asset manager you really try
one. It can provide a noticeable speed boost (beyond just
combining/compressing media) by utilizing the browser's cache
perfectly and it can also help you during development.

> 3. Designers and front-end developers working on Django projects
> should not have to learn some odd way of linking in their CSS, that
> appears to be wrong according to everything they know about how things
> usually work. The links they write should make sense to them, not just
> to some Python developer who invented a new "standard" for them.

I see the point you're trying to make and I don't like that solution
(4) breaks with an existing convention, either. There's still the
other option of going with (2) for CSS and with (4) for Sass/etc. It's
just inconsistent and this becomes even more confusing if you use some
language with CSS-like syntax (e.g., SCSS).

> 4. Django does not provide any built-in tools to combine, compress, or
> rewrite links in media, so it is certainly not going to adopt a
> "standard" that requires the use of such a tool.

While staticfiles doesn't combine media it definitely is a bulit-in
tool and it could easily be extended to rewrite URLs (for the purpose
of having a standard).

> In other words, the only reason a "standard" would even be needed here
> is because you want to establish a new standard which makes the source
> CSS files unusable in the absence of a filter which implements the
> standard!
>
> I think the problem here is a desire to conflate multiple issues which
> are clearer when considered separately. To wit:
>
> 1. Links in static files should be written in such a way they work as-
> is, without knowing what root URL they will be served under (this
> means relative internal links).
> 2. Any third-party tool that combines/compresses CSS should be able to
> take working input files and generate working output files, handling
> whatever internal links it finds correctly.
>
> Both of these seem almost so obvious that they shouldn't require
> stating at all; you'll also note that they keep the question of
> internal linkage neatly separated from the presence or absence of a
> hypothetical compressor/combiner.

I agree with 1. I also fully agree that 2 *should* work the way you
described. However, without a standard it can't and in fact this very

Re: Gentle Proposal: add 'render' shortcut in 1.3

[Russell Keith-Magee]

On Fri, Oct 29, 2010 at 2:50 PM, Ivan Sagalaev
 wrote:
> Russel:
>>>
>>> Wouldn't it make sense to put a flag on the TemplateResponse
>>> that prohibits accidental baking?
>
> Mikhail:
>>
>> So maybe it will be better not to make bake/force_bake public so that
>> users won't be able to shoot themselves in the foot?
>
> I don't think it's doable at all. People still can call any method in as
> well as they can ignore or alter any protection flag. I believe it's
> sufficient to abide to the Python way here, write a proper documentation and
> treat people as grown-ups trusting them not to do bad things in their
> process_template_response.

I agree that it's important to treat people as grown ups. However,
this is something that is trivial to do by accident -- for example,
printing response.content would be an obvious debug step -- and it
will be a non-trivial thing to identify that this is the cause of your
problems.

Maybe an unconditional exception is a little strong, but some sort of
safety catch seems called for.

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: Gentle Proposal: add 'render' shortcut in 1.3

[Ivan Sagalaev]

Russel:

Wouldn't it make sense to put a flag on the TemplateResponse
that prohibits accidental baking?


Mikhail:

So maybe it will be better not to make bake/force_bake public so that
users won't be able to shoot themselves in the foot?


I don't think it's doable at all. People still can call any method in as 
well as they can ignore or alter any protection flag. I believe it's 
sufficient to abide to the Python way here, write a proper documentation 
and treat people as grown-ups trusting them not to do bad things in 
their process_template_response.


--
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.