Hi, All.
For django.template.backends.django.DjangoTemplates (filesystem and
app_directories) it can be very useful. This can be implemented?
WBR, Vitaly.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
On Thu, Mar 17, 2016 at 1:44 PM, Florian Apolloner
wrote:
> Yes, this seems like a major pain point, especially since the routing does
> not scale if you add another app, ie you need to add a wrapper which then
> dispatches to the individual connect routines. In a best case scenario I'd
> just ha
Hi folks (and especially Andrew):
I've just completed writing an example Channels app [1] for an article
about Channels [2]. Overall it was a super-pleasant experience: Channels
seems pretty solid, the APIs make sense to me, and I couldn't be more
excited about the new things this'll let me do!
I
Thank you. I am happy that this gets solved.
Am Dienstag, 15. März 2016 15:54:26 UTC+1 schrieb Tim Graham:
>
> Here's the mailing list thread:
> https://groups.google.com/d/topic/django-developers/8LMJ44KAxWI/discussion
>
> I think mostly the implementation just needs to be completed.
>
> On Tues
You're right. Assume I put the keyword arguments at the end, sorry - the
two positional arguments are the channel name and the consumer.
On Fri, Mar 18, 2016 at 12:21 PM, Ryan Hiebert wrote:
>
> On Mar 18, 2016, at 9:58 AM, Andrew Godwin wrote:
>
> routing = [
> route("http.request", ViewCo
On Wed, Mar 16, 2016 at 04:06:32PM +0100, Raphaël Barrois wrote:
> Hello there,
>
> I am not sure the tone of that discussion is suitable for that mailing-list ;)
I totally agree on this point. Let's try to keep it civil.
> Regarding the initial discussion, if I understand correctly, the idea wo
Hi Connor,
I personally usually avoid class based views whenever possible and stick to
function based views whenever possible. Would these Conditions be usable
within function based views too?
Thanks,
Collin
On Thursday, March 17, 2016 at 8:00:16 AM UTC-4, Connor Boyle wrote:
>
> My original
Triaged
---
https://code.djangoproject.com/ticket/26351 - Recommend enabling MySQL's
STRICT_TRANS_TABLES to prevent silent truncation (accepted)
https://code.djangoproject.com/ticket/26355 - Add support for PostgreSQL's
array_append to ArrayField (accepted)
https://code.djangoproject.co
I like most of it apart from the fact you can set a consumer to consume ANY
channel, which seems incredibly dangerous - when a channel is wrongly
consumed the only visible error is usually just a lack of response to the
end client, and no two channels have messages that are similar in any
useful wa
I'm not sure whether or not to accept a related proposal to add a
"formfield_defaults" keyword to model fields [0]. e.g.
link = models.OneToOneField(
...
formfield_defaults={
'widget': forms.RadioSelect,
}
)
It seems useful, but I'm not sure if it increases the coupling betw
Yes, definitely! That was something I had in mind coming up with the
concept. The "Conditions" themselves are written with no knowledge of and
have no relation to class-based views, they simply give a pass or a fail
given certain conditions.
On Friday, March 18, 2016 at 10:56:46 PM UTC+8, Colli
Yes, my intent is that "path" is just a stand-in for "any string key in a
message", thus you could route other ways (for example, `method` in
http.request, though that's probably not super useful inside Django).
Andrew
On Sat, Mar 19, 2016 at 1:40 PM, Vincent wrote:
> Andrew,
>
> Thanks for the
On Saturday, March 19, 2016 at 7:01:28 PM UTC+1, Daniel R wrote:
>
> But given the wide use of {{STATIC_URL}} this may be an easy and
> worthwhile fix instead of asking users to change template references.
>
Wide? Not sure what your definition of wide is, but I suspect that the tag
has way hig
On Wed, Mar 16, 2016 at 3:22 PM, Matías Iturburu wrote:
> Even if I submit a patch I wouldn't be able to:
> - Merge it into mainline.
> - Upload the patched version to pypi.
>
> So it's a no-starter,
> I can't rely on my fork, not for production, as I
> should guarantee that the package it's, at l
The current PR is here: https://github.com/django/django/pull/5949 -- Now
that the general idea is clear, I think I will push it as branch to the
main Django repo, so others can help working on it. There is still quite a
bit to do, but the general functionality is working as intended.
Cheers,
F
I've always used the STATIC_URL context processor variable in templates and
didn't have trouble with it up until a few days ago when a customer
required to use the STATICFILES_STORAGE.
I then realized I would need to change all the {{STATIC_URL}} template
references to use a {% static %} tag vi
Andrew,
Ah, excellent. I just took a short break (too many LOC at work today), and
while I was away I was thinking about all of this.
Here's what I came up with:
https://gist.github.com/orokusaki/17b4cf734b4d2f2af117
On Friday, March 18, 2016 at 3:57:38 PM UTC-4, Andrew Godwin wrote:
>
>
>
> O
In the beginning I thought about making an api which supports column
databases such as cassendra but would mean that i would need to first find
commonalities between all 3 ( column , document and relational ) but such
commonalities would be lesser and so finally i would require to create a
sepa
> On Mar 16, 2016, at 11:55 AM, Connor Boyle wrote:
>
> I'm hoping to add a feature that I've thought Django has needed for a long
> time, and thought that Google Summer of Code would be an excellent
> opportunity for it. Basically, it would be an API for defining 'Conditions'
> and applying
Thanks. #11652 is a good description of the same problem in the context of
the "change" page. I think that, in practice, it is more of a problem with
a list_editable, since you're updating many records at once. This makes a
"collision" with some other part of the system more likely.
I think the
Andrew,
Thanks for the explanation.
(re: including based only on path, routing based on channel (and optionally
path?)), I really really like that simplicity, the more I think about it.
Expanding on that to include your prior examples, I'm assuming `path` is
just incidental for http / websocke
On Wed, 16 Mar 2016 15:39:40 +0100
James Pic wrote:
> On Wed, Mar 16, 2016 at 3:22 PM, Matías Iturburu wrote:
> > Even if I submit a patch I wouldn't be able to:
> > - Merge it into mainline.
> > - Upload the patched version to pypi.
> >
> > So it's a no-starter,
> > I can't rely on my fork, not
I'm still working on fleshing out how specifically to add them into
function-based views–what code the API should provide to automate or
semi-automate the auth-related functionality once a Condition has failed
(redirect to login, etc.). I'll get that in my proposal ASAP, but if you
have any par
Hi all, I talked with FunkyBob on IRC a few weeks ago and told him I was
interested in optimizing the template language. One of the suggestions he
made was to make a profiling/benchmarking framework to test changes. While
I wouldn't call it a framework yet I have a script set up to run the djang
2016-03-16 6:24 GMT-03:00 James Pic :
> What do you mean stuck? Aren't you supposed to port the packages and
> submit a patch in that case? How are you stuck ?
>
Alright... I don't know you but no, that doesn't quite work that way.
Even if I submit a patch I wouldn't be able to:
- Merge it into m
It seems like FileField should delegate some of these methods to an
underlying Storage backend, no? I don't know what the implications to
back-compat would be, but the idea seems like a sensible one to start with.
The storage backend API may need to grow some additional methods to
verify/valida
On Thursday, March 17, 2016 at 9:56:40 PM UTC+1, Jacob Kaplan-Moss wrote:
>
> I'd considered an API like this, and it's certainly clean and
> straightforward. However, we've already got a URL routing library in
> Django, so I think I'd like to try to find a way to re-use it for
> websockets. I
Hi all!
Perhaps the wiki is the best place for this kind of things?
Thanks for your feedback
Best
James
On Mar 16, 2016 12:59 AM, "James Pic" wrote:
> I'd like to illustrate why I think having official documentation about
> deployment on PaaS would be great.
>
> What I mean by "there is confu
On Thu, Mar 17, 2016 at 1:41 PM, Jacob Kaplan-Moss
wrote:
>
>
> 1. Debugging errors:
>
> I found debugging errors that happen in a consumer to be *really*
> difficult -- errors mostly presented as things just silently not working.
> It took a ton of messing around with logging setups before I coul
To add a bit more about this, it seems that FileField is really meant to be
working with an OS file system, making it harder to use a custom Storage
that sends data to somewhere like AWS S3 where basically everything is a
file (there are no real folders, just key prefixes)
These 3 functions ins
Perhaps it is a bit early for this but Is there anywhere origin is checked
against ALLOWED_HOSTS ?
Middleware support would be nice to but I guess you'll come to that when
implementing user authentication.
Keep up the great work !
--
You received this message because you are subscribed to the G
I'm hoping to add a feature that I've thought Django has needed for a long
time, and thought that Google Summer of Code would be an excellent
opportunity for it. Basically, it would be an API for defining 'Conditions'
and applying them to Views. Common usages would include restricting views
bas
Hi Vincent,
I think you make some good points - in particular, I think includes are
probably a necessity, as you say. However, I disagree we should let people
have either channel->url or url->channel; I'd like us not to try and give
people multiple ways to do things if we can help it, especially i
Also note, I just copy-pasted the same SyntaxError (kwarg before arg).
On Friday, March 18, 2016 at 3:40:22 PM UTC-4, Vincent wrote:
>
> Hey Andrew,
>
> Thanks for looking through all that, and for the reply.
>
> I like the simplicity of your updated examples. I started to make a
> counter-exampl
Correction:
> I can't use atomic blocks
This is not true.
"You can use atomic just over the section that causes the error", this has
been suggested to me multiple times and I thought I had no use for it but
it was actually very useful in many cases.
With that technic and with the Django pat
My original inspiration actually was Django Rest Framework, but I wanted to
show that I had actually thought it out and that it is indeed possible to
implement (albeit not quite as cleanly as DRF does it). I'll try to finish
a more detailed write-up of how they compare, but in short they are ver
> On Mar 18, 2016, at 9:58 AM, Andrew Godwin wrote:
>
> routing = [
> route("http.request", ViewConsumer),
> route("websocket.connect", path="^chat/(?P[^/]+)/$", ChatConnect),
> route("sms.receive", sender="+44(?P[0-9]+)$",
> UkSmsConsumer),
> include(path="^notifications", "not
This is the 2nd major issue I can recall caused by MySQL default of
REPEATABLE READ transaction isolation level. I think Django should simply
switch itself to a default of using READ COMMITTED, consistent with (all?)
other supported database backends, and document how, if a user really
really wants
On Thursday, March 17, 2016 at 5:42:05 PM UTC+1, Jacob Kaplan-Moss wrote:
>
> Channels routes all WebSocket connections to a single set of consumers
> (the `websocket.*` consumers). This means that if you want multiple
> WebSocket URLs in a single app you need to manually parse the path. And, to
I am recently trying to make an aws S3 storage (I know there are a few
libraries in there but I needed some customization). The storage works fine
so far!
However, there are some implementation details on FileField and ImageField,
in particular the function
generate_filename
https://github.com
If we prefer to remove form related stuff from models, then we should
be able to register new default model forms:
models.py:
class YourModel(models.Model):
your_field = models.BooleanField()
forms.py:
class YourModelDefaultForm(django.?.ModelFormConfiguration):
class Meta:
help
I could see this feature being helpful. (Submitting the original data and
comparing it to be sure we don't silently have a merge conflict).
On Wed, Mar 16, 2016 at 11:14 PM, John C wrote:
> Thanks. #11652 is a good description of the same problem in the context of
> the "change" page. I think th
On Thu, Mar 17, 2016 at 2:17 PM, Tim Graham wrote:
> It seems useful, but I'm not sure if it increases the coupling between model
> and forms in an undesirable way?
The coupling is already there because model fields sit right
in-between the db and form fields, so I don't know if it would
actually
Jacob, Florian, Andrew,
I've spent the last 200 minutes thinking this through and writing, and
here's what I've come up with:
https://gist.github.com/orokusaki/c67d46965a4ebeb3035a
Below are the full contents of that Gist (but I recommend the Gist for
formatting).
I also created https://githu
FTR, there's also Djangonauts which have been there for a while:
https://github.com/djangonauts
Sorry, I tried not to look uncivil - and yet I fail to see where I
was, but definitely re-reading and thinking about it (I'm not an
english native speaker). Please anyone feel free to PM me and point me
My original inspiration actually was Django Rest Framework, but I wanted to
show that I had actually thought it out and that it is indeed possible to
implement in core Django (albeit not quite as cleanly as DRF does it). I'll
try to finish a more detailed write-up of how they compare, but in sho
Hi,
I have been working for preparing a proposal on SqlAlchemy integration with
django. While I haven't done with in detail proposal and in depth technical
specs, I'm posting my very draft proposal to understand If the broader
strokes of my approach are nearly OK and I should proceed with the c
47 matches
Mail list logo
