Re: Add an extra parameter to 'static' tag

[Florian Apolloner]

Hi Renato,

On Sunday, June 1, 2014 4:36:55 PM UTC+2, Renato Oliveira wrote:
>
> On Sunday, June 1, 2014 3:26:06 AM UTC+2, Renato Oliveira wrote:
>>>
>>> I open sourced  the 
>>> modification we did (4 or 5 lines plus tests), and was about to send it to 
>>> pypi and wondered if it is an improvement to do on Django itself.
>>>
>>
>> I don't think so, since Django already provides a way to do what you are 
>> after: You can write your on static storage backend which the static-tag 
>> will then use, this way the backend will figure out what to do when 
>> DEBUG=False/True.
>>
>
> Yeah, i'm aware of this, and sorry for not being explicit. The goal of 
> this improvement is to point to many places. For exampe, if I have a 
> project with, bootstrap, jquery and angular. I can do this:
>
> {% static 'path/to/my/angular.js' http://googlecdn/angular.js %}
> {% static 'path/to/bootstrap.css' http://bootstrapcdn/bootstrap.css %}
>

I don't see any difference to the  DEBUG example here, a storage backend 
can still return different URLs, depending on the filename (eg angular vs 
bootstrap). Your proposal seems to remove the choice from the user and puts 
it into the template. FWIW, in my experience per project CDNs often 
introduce greater latency and less performance than a single (or more) 
keep-alive connections to one server fetching all the files (possible 
concatenated).

Cheers,
Florian

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d7da3542-f64e-4aed-83c0-4d56070d9d01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add an extra parameter to 'static' tag

[Reinout van Rees]

On 01-06-14 16:36, Renato Oliveira wrote:


{% static 'path/to/my/angular.js' http://googlecdn/angular.js %}
{% static 'path/to/bootstrap.css' http://bootstrapcdn/bootstrap.css %}


It seems to me that the core use case of the staticfiles app is to 
manage *local* css files well. This includes the scenario where the 
local files are copied off to a CDN. That CDN's base URL can then be 
used in production.



What you are proposing sounds to be a different problem:

- You want to use a CDN in production.

- You want to use local files as a fallback for when you're on a train 
without an internet connection to the CDN.



So... I don't think this change should go into staticfiles.

But... the basic use case is sound. Perhaps you could change your code 
into a template tag that looks like

{% cdn http://googlecdn/whatever.js %} ?

With a management command that would download all the relevant files to 
a local directory? (Assuming you can list the templates). Or that would 
do it on the fly when an internet connection is available when you use 
the template?


It works the other way around from your current approach, but that looks 
to me to be the right way around :-)




Reinout

--
Reinout van Reeshttp://reinout.vanrees.org/
rein...@vanrees.org http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/lmg7nt%24og3%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Weekly update

[Daniel Pyrathon]

Hi All,

An update on my side, some interesting work has happened this week: me and 
Russell have decided to start on the implementation early in order to 
understand better the internals of Options. Currently I am working on the 
following:

*Providing one single function: get_fields(types, opts, **kwargs)*
Previously we had identified a number of functions that contained similar 
data but had a different return type. We are going to provide one function 
that takes a set of field types + options and returns the same output 
everywhere: ((field_name, field), ...). This has the benefit of simplicity 
and is more maintainable than the previous approach.

TYPES = DATA, M2M, FK, RELATED_OBJECT, RELATED_M2M
OPTS = NONE, LOCAL_ONLY, CONCRETE, INCLUDE_HIDDEN, INCLUDE_PROXY, VIRTUAL

*Providing two functions for retrieving details of a specific field*
As specified in my previous document, in many parts of the code we just 
want to retrieve a field object by name, other times we have a field but 
need other metadata such as: owner (model_class), direct (bool), m2m 
(bool). We will provide two functions:

get_field(field_name) -> field_instance

get_field_details(field_instance) -> direct, m2m, (still to be defined)

While we still have not entirely defined what *get_field_details *will 
return, this will be done soon.


*Building a test suite for the existing API*
The new API development will be driven by a test suite that will compare 
the current (legacy) API with the new implementation. While return types 
will be different, we are asserting that all the correct fields and 
metadata are returned. Building a test suite means we can start 
implementing before a final API spec is finalised. It also means we can 
iterate faster and, from my perspective, I also understand a lot more of 
the current implementation. We are testing each combination of fields and 
options together.

My current implementation is visible 
here: https://github.com/PirosB3/django/compare/soc2014_meta_refactor

For any questions or suggestions, let me know.

Daniel Pyrathon


On Monday, May 26, 2014 1:28:31 AM UTC+2, Daniel Pyrathon wrote:
>
> Hi All,
>
> Just to make you know, I have put up the current _meta API documentation 
> here:
> http://162.219.6.191:8000/ref/models/meta.html?highlight=_meta
> As always, feel free to ask questions.
>
> Daniel
>
> On Monday, May 26, 2014 1:26:27 AM UTC+2, Daniel Pyrathon wrote:
>>
>> Hi Josh,
>>
>> The meta API specified in the docs (
>> https://github.com/PirosB3/django/blob/meta_documentation/docs/ref/models/meta.txt)
>>  
>> is the current API. I have documented this in order to understand more of 
>> the current implementation and it will be good to show a comparison when a 
>> new meta API will be approved.
>>
>> My current proposal (https://gist.github.com/PirosB3/371704ed40ed093d5a82) 
>> and it will be discussed tomorrow with Russell. I will post as soon as I 
>> have updates.
>>
>> Daniel Pyrathon 
>>
>> On Saturday, May 24, 2014 10:37:49 AM UTC+2, Josh Smeaton wrote:
>>>
>>> Hi Daniel,
>>>
>>> Nice work putting that document together. Is the meta document you put 
>>> together the current API or is it the API you are proposing? If the latter, 
>>> a few suggestions (and if others disagree, please point that out):
>>>
>>> - Remove all mention of caching. That should be an implementation detail 
>>> only, and not a requirement for other implementations.
>>> - the *_with_model methods really rub me up the wrong way. I would 
>>> prefer always returning the _with_model variant, and letting the caller 
>>> discard the model if they don't need it.
>>> - I'm not a fan of virtual and concrete fields, though I have to admit 
>>> I'm not sure how they're different, especially in the context of different 
>>> implementations.
>>> - Not sure that m2m should be differentiated from related.
>>> - init_name_map should be an implementation detail.
>>> - normalize_together should be an implementation detail.
>>>
>>> Regards,
>>>
>>> Josh
>>>
>>> On Saturday, 24 May 2014 05:05:02 UTC+10, Daniel Pyrathon wrote:

 Hi all,

 In the last days I have built a documentation of the current state of 
 Options. Based on feedback and prototyping I have thought of a potential 
 interface for _meta that can solve the issues currently present, such as 
 redundancy (in code and in caching systems). The interface has also been 
 thought to be maintainable and is a base that can be used to create custom 
 meta stores.
 Obviously this is far from perfect, It will need many iterations and 
 maybe it is too complex. I would really love to gain as much feedback as 
 possible so it can be discussed with Russell and the community on Monday.

 The documentation of _meta can be found here: 
 https://github.com/PirosB3/django/blob/meta_documentation/docs/ref/models/meta.txt
 I will be refining the document in the next days, I will also be 
 publishing the docs on a 

Re: Add an extra parameter to 'static' tag

[Renato Oliveira]

On Sun, Jun 1, 2014 at 6:52 AM, Florian Apolloner 
wrote:

> Hi Renato,
>

Hi Florian, thanks for answering

>
>
> On Sunday, June 1, 2014 3:26:06 AM UTC+2, Renato Oliveira wrote:
>>
>> I open sourced  the
>> modification we did (4 or 5 lines plus tests), and was about to send it to
>> pypi and wondered if it is an improvement to do on Django itself.
>>
>
> I don't think so, since Django already provides a way to do what you are
> after: You can write your on static storage backend which the static-tag
> will then use, this way the backend will figure out what to do when
> DEBUG=False/True.
>

Yeah, i'm aware of this, and sorry for not being explicit. The goal of this
improvement is to point to many places. For exampe, if I have a project
with, bootstrap, jquery and angular. I can do this:

{% static 'path/to/my/angular.js' http://googlecdn/angular.js %}
{% static 'path/to/bootstrap.css' http://bootstrapcdn/bootstrap.css %}

And If I have to write some css or js file,

{% static 'path/to/users.js' %}

And this would use Django storage or S3, whatever.

>
> Cheers,
> Florian
>

I looked for alternatives, and read about django custom storage backends,
and it doesn't seemed to me that it could do it.

If there is a way to do this without changing the template tag, this e-mail
must be on django-users, sorry :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGPLouWmPt%2BVQNyuLy00o7P4-OLgVZR1JDvN_ZGH_6JCWsPFHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add an extra parameter to 'static' tag

[Florian Apolloner]

Hi Renato,

On Sunday, June 1, 2014 3:26:06 AM UTC+2, Renato Oliveira wrote:
>
> I open sourced  the 
> modification we did (4 or 5 lines plus tests), and was about to send it to 
> pypi and wondered if it is an improvement to do on Django itself.
>

I don't think so, since Django already provides a way to do what you are 
after: You can write your on static storage backend which the static-tag 
will then use, this way the backend will figure out what to do when 
DEBUG=False/True.

Cheers,
Florian 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1ecef89d-ec48-4ae0-bd97-95275bcd72f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for function application in ORDER BY

[Tim Martin]

Funnily enough, I'd already seen that patch but I hadn't figured out the 
full significance of it. I attempted to solve #22288 
(https://code.djangoproject.com/ticket/22288), but spotted that your patch 
would possibly solve the problem entirely, and at the very least breaks my 
attempt to solve that specific case.

The expression concept seems like a good direction to be going in. I'd 
definitely be interested in seeing how to extend this to solve the two 
tickets I'm working on. I'll take a look at your code and see what I can do 
with it, and ask if I get stuck.

Tim

On Sunday, 1 June 2014 09:46:02 UTC+1, Josh Smeaton wrote:
>
> I would like to point you towards a patch I'm currently working on which 
> is essentially your option 2: https://github.com/django/django/pull/2496
>
> It doesn't seem very relevant at first, since it only applies to .annotate 
> and .aggregate, but the infrastructure behind it certainly does. In short, 
> the patch expands on the concept of "Expressions". Expressions are nodes in 
> a tree that output SQL. Functions can be expressions, a field (F() object) 
> can be an expression, or the number 5 can be an expression. Funnily enough, 
> I implemented the SQL `Lower` function as a test: 
> https://github.com/jarshwah/django/commit/362fec1330f1f40c45ece5769f9e35047c87a010#diff-4c9f3e475cf7fa25e6d21c2fb7b8c30fR185
>
> What I'd like to do if this patch is accepted (and I believe it will be 
> for 1.8; it's a matter of getting the backwards-compat right), is to expand 
> the concept of expressions into the other pieces of the API, especially 
> `order_by`. Once order_by understands expressions, it's trivial to order 
> the result set by any kind of sql you could imagine..
>
> - .order_by(NullsLast('field'))
> - .order_by(Lower('field'))
> - .order_by(Coalesce(F('field'), F('otherfield')))
> etc.
>
> Marc is right that custom transforms could be used if order_by was taught 
> the API. I would prefer to teach order_by about Expressions though, since 
> F() supports custom lookups and transforms already. His version would then 
> look like: .order_by(F('title__lower')). I can see the value in a 
> keyword__based API that is similar to the rest of django (like .filter()), 
> but I find the syntax limiting when trying to compose multiple expressions 
> together.
>
> If you were interested in branching off and working on bringing the same 
> functionality to order_by, I'd be happy to provide information or support 
> if you had any questions.
>
> Regards,
>
> Josh
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/09acb528-94ca-4529-a8f1-9267de180b6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for function application in ORDER BY

[Josh Smeaton]

I would like to point you towards a patch I'm currently working on which is 
essentially your option 2: https://github.com/django/django/pull/2496

It doesn't seem very relevant at first, since it only applies to .annotate 
and .aggregate, but the infrastructure behind it certainly does. In short, 
the patch expands on the concept of "Expressions". Expressions are nodes in 
a tree that output SQL. Functions can be expressions, a field (F() object) 
can be an expression, or the number 5 can be an expression. Funnily enough, 
I implemented the SQL `Lower` function as a 
test: 
https://github.com/jarshwah/django/commit/362fec1330f1f40c45ece5769f9e35047c87a010#diff-4c9f3e475cf7fa25e6d21c2fb7b8c30fR185

What I'd like to do if this patch is accepted (and I believe it will be for 
1.8; it's a matter of getting the backwards-compat right), is to expand the 
concept of expressions into the other pieces of the API, especially 
`order_by`. Once order_by understands expressions, it's trivial to order 
the result set by any kind of sql you could imagine..

- .order_by(NullsLast('field'))
- .order_by(Lower('field'))
- .order_by(Coalesce(F('field'), F('otherfield')))
etc.

Marc is right that custom transforms could be used if order_by was taught 
the API. I would prefer to teach order_by about Expressions though, since 
F() supports custom lookups and transforms already. His version would then 
look like: .order_by(F('title__lower')). I can see the value in a 
keyword__based API that is similar to the rest of django (like .filter()), 
but I find the syntax limiting when trying to compose multiple expressions 
together.

If you were interested in branching off and working on bringing the same 
functionality to order_by, I'd be happy to provide information or support 
if you had any questions.

Regards,

Josh


On Saturday, 31 May 2014 21:22:14 UTC+10, Tim Martin wrote:
>
> Hi all,
>
> I was looking at implementing the behaviour proposed in #13006 (
> https://code.djangoproject.com/ticket/13006). In short, the idea is to 
> allow decorating fields in order_by() with a LowerCase() modifier to apply 
> LOWER() in SQL before ordering:
>
>Articles.objects.all().order_by(LowerCase('title'))
>
> to yield
>
>...
>ORDER BY LOWER("articles"."title")
>...
>
> Obviously it's sensible if we can generalise this to apply a wide range of 
> SQL functions with the same infrastructure.
>
> It's easy enough to make this work, but I'm having trouble with 
> generalising the solution. The problem is that the argument to order_by() 
> can be a compound expression like "-author__name" and we have to parse it 
> out. Only the SQLCompiler object (I think) has the necessary information to 
> correctly figure out the joins and turn this into valid SQL.
>
> I can see a couple of different approaches:
>
> 1) Have these decorator classes be very simple containers and keep all the 
> logic in the SQLCompiler. The compiler object will detect a 
> FunctionCallDecorator, query it for the ordering string and combine them, 
> something like:
>
>if isinstance(field, FunctionCallDecorator):
>   table, cols, order = self.find_ordering_name(field.get_field(), ...)
>
>   function = field.get_function()
>
>   # other stuff
>   order_by = "%s(%s.%s)" % (function, qn(table), qn2(col))
>
> I'm not that happy with this solution, since it binds the implementation 
> of FunctionCallDecorator very closely to the workings of SQLCompiler and to 
> ORDER BY in particular.
>
> 2) Make the argument to order_by into a tree structure that can be 
> processed by the SQLCompiler using the visitor pattern. Leaf nodes 
> (strings) get mapped into expressions by the SQLCompiler as normal, while 
> internal nodes get to define their own logic for combining the output of 
> their child nodes into an expression. The ASC / DESC direction is a bit 
> awkward here, since it's meaningless to have two function arguments that 
> order in different directions, for example.
>
> This is more similar to how we do WHERE nodes, if I'm understanding the 
> code correctly. This seems to better support multi-argument functions (e.g. 
> COALESCE) which would be a horrible kludge in the first method, and to 
> support multiple function application (e.g. LOWER(LTRIM(...))). However, it 
> feels a bit over-engineered.
>
> There are obviously lots of other variations here, but I figured I'd ask 
> before I went too much further with the design process. Does anyone have 
> any feelings about how best to approach this?
>
> Tim
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit