Re: Vendoring Select2

[is_null]

Hi all,

In our experience, it would be worth removing noConflict, but we need 
Django to have a recent jQuery release, it's wasn't always the case but now 
it's good. I don't know who relies on that except grappeli, but they would 
probably be happy to get rid of their double jquery loading because that's 
been the source of many user issues, at least in DAL's repo.

Another library that would be worth proposing is jquery-autocomplete-light 
(disclamer: I'm the author), particularely because it is built to let the 
server render the suggestions box, and because it's pretty light by essence 
(does nothing on selection but trigger an event, it's up to the developer 
to implement the callback). But I should do some crowdfunding or something 
to cover it with JS unit tests, currently it's abandoned except by most 
django-autocomplete-light < 3.0 users, some v3 users are using it already 
even thought it's not been officially released / supported, because I was 
maintaining it with selenium tests and that was too much of a pain of 
course to have no unit tests.

If you need generic form widgets, I think we've got ok ones in 
django-autocomplete-light v3. Again what's missing for developer experience 
is just the ability to override the default form, without having to 
subclass the world just to pass it: when you need an autocomplete on a 
field, you most likely need it everywhere, ie. because the select would 
load too many options to be usable.

We'd be very happy to see noConflict removed, and try to all rely on the 
latest jQuery, rather than all try to load our own and deal with different 
variables names for jQuery. Perhaps I should try this in a fork, even if 
that means DAL will require extra steps for users not on that specific 
Django fork, at least we'd figure out if removing noConflict had unseen 
drawbacks.

Best

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/43f81fe5-6999-4400-90a7-68585ca51c49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: make Model __unicode__() default to self.name

[is_null]

Usually people tell me that type(self) is better than self.__class__, so 
you might prepare to change that too.

But yeah, it seems like a very reasonable change to me, reading lists of 
indistinct  have always required extra steps to figure out 
what models they are.

Thanks for your effort,
Best
James

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6c7cc560-8f68-497d-99f8-eb1396bcff0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Refactor Form class

[is_null]

Hi

On Thursday, March 3, 2016 at 9:00:47 PM UTC+1, Moritz S. wrote:
>
> For example, it's conceivable that the form data doesn't 
> come from a HTTP request with x-www-form-urlencoded or 
> multipart/form-data content but gets transferred as JSON. In 
> this case it should be easy to replace the HTTP parsing 
> component with a JSON parser. 
>

That's the case when using ReactNative for example. 

However, it is easy to make the client do a standard HTTP post request.
 

> Also HTML forms may not be the only place where data 
> validation is needed. An application may get an untrusted 
> dict of Python objects that doesn't have to be parsed but 
> should still be validated. In that case it would be nice to 
> be able to just use the data validation component. 
>

I'd like to see where that goes, it does sound pretty useful to me.

When users do validation without the framework it's not unusual to find 
security bugs :)

Perhaps you'd have more luck if you'd split your proposal and make a 
smaller proposal, wait and see ...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/95f4e9dc-3bae-4af4-bdf5-7f26d7b0deef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: About Understanding of source code

[is_null]

This should be mentioned too:

import ipdb; ipdb.set_trace()

If you didn't already, then go ahead and mess with it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/I1-zmObIpWEJ.
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.

Re: Django Admin Revamp - Any updates?

[is_null]

I'm not sure if it's worth mentioning ...

2. Secure CRUD one-liner goal

The new admin app should, like the current admin app, allow the user to 
enable full secure (permission-based) CRUD in one line of code.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/fxyL124kbP8J.
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.

Re: Django Admin Revamp - Any updates?

[is_null]

On Saturday, April 28, 2012 10:13:03 PM UTC+2, Idan Gazit wrote:

> As I wrote, I'd like to have a clear idea of what a new admin will 
> accomplish before starting to bolt on enhancements, even great enhancements 
> like grappelli. 
>
> The admin was an impressively future-proof design, given that it is still 
> so useful years after it was designed. We should aim to make an admin that 
> will be relevant and useful five years from now; we can't design for that 
> without a couple of clear, simple goals. Grappelli may or may not align 
> with those goals.
>

As I just blogged: "Last year, I sent a letter to santa asking for 12 
transformers with super laser powers. I waited nicely and then received a 
little playmobil."

A couple of "clear, simple goals", you ask:

0. Loose coupling goal

The new admin app should not include ChangeList (ie. django-tables2), form 
rendering (ie. django-floppy-forms), queryset filtering (ie. 
django-filter), etc, etc 

1. KISS goal

The new admin app should not try to abstract the basics of Django elegant 
design. Instead of: admin.site.register(Foo, FooAdmin). I could use: 
url(r'myapp/foo/', admin.ListView.as_view(table=FooTableClass, 
filters=FooListFilters), name='myapp_foo_list'). Of course, I could use a 
shortcut / factory / something cool. But the new admin app would be so 
simple I wouldn't need ModelAdmin and I could override anything easily and 
I could even reuse parts of it in my own views (see "Loose coupling").

Hope this helps.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/8oNVlVMOya4J.
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.

Re: Trigger an event on add another

[is_null]

FTR, another solution is to intercept creation of  tags with 
DOMNodeInserted. Requires no monkey patch and is compatible with django & 
django-grappelli out of the 
box: https://github.com/yourlabs/django-autocomplete-light/commit/1f1e715e20

Thanks again for your answer (which I credited in the related github issue).

Rock'on

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/0WE7Hx4YOXwJ.
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.

Re: Trigger an event on add another

[is_null]

My bad I didn't see Mark's mail, I'll subscribe to the list and hopefully 
this shouldn't happen again.

Thanks Mark for answering

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/0SuXBSwTQMoJ.
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.

Re: ModelForm enforces its version of save_m2m

[is_null]

Thanks for answering. It's "funny code" but it works indeed.

Thanks again

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/2_4X_NFZmP8J.
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.

Re: uWSGI documentation

[is_null]

Thanks Roberto for your feedback.

The text seems ready so i created a ticket:

http://code.djangoproject.com/ticket/16057

Again, any positive feedback and/or violent flames are welcome.

James

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

Re: uWSGI documentation

[is_null]

Thanks a lot Roberto and Mikhail for your feedback.

This update includes the changes you requested, as well as more links
to uWSGI wiki: http://piratepad.net/DISxvZLCdG

Is there any other action to take ?

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

Re: uWSGI documentation

[is_null]

On Apr 4, 3:59 pm, Kristaps Kūlis   wrote:
>   I believe that running manage.py for production deployments is "not
> way to go", as it has been noted by django devs previously.
>  What purpose would runuwsgi command serve ?

I'm unsure. Roberto's proposal is interresting: i could configure
uwsgi in settings.py and then just run runuwsgi. Although that looks a
little to much for django itself, it would be great in a pluggable
django app.

That said i'd love to *not* have to put a 3 liners module in my
project directory anymore. A runuwsgi command might not be the only
way to solve this need.

On Apr 2, 4:44 pm, Łukasz Rekucki  wrote:
>
> +1. More docs didn't hurt anybody. At least while there is someone to
> maintain them.
>

You can count on me (until death).

>
> > What do you think ?
>
> My first impression is that you're focusing too much on all those
> switches. That section got me totally lost. That should be simplified.
> Also, do I really need to type all that stuff? I probably won't be
> doing that on production, so showing how to place it in a
> configuration file would be better.
>
> I would also drop the whole "advantages" section. The purpose of the
> page is to show how to deploy a Django app onuWSGI, not compare it
> against other solutions. You also mention some features, but never
> show how to enable/use them which is confusing.

Thanks for your feedback, I did my best to take it in consideration
while rewriting most of the documentation this week.

(Some examples are still missing but most of it is there. Feedback is
always appreciated)


How to use Django with uWSGI


.. highlight:: bash

uWSGI_ is a fast, self-healing and developer/sysadmin-friendly
application
container server coded in pure C.

.. _uWSGI: http://projects.unbit.it/uwsgi/

Prerequisite: uWSGI
===

`uWSGI wiki`_ describes
several
installation procedures. Using pip, the python package manager,
installing any
uWSGI_ version can be done with one command line. For example::

# install current stable version
pip install uwsgi
# or install LTS (long term support)
pip install http://projects.unbit.it/downloads/uwsgi-lts.tar.gz

Prerequisite: general concept
=

uWSGI model
---

uWSGI_ operates on a client-server model. Your Web server (ie. Nginx,
Apache)
communicates with a django-uwsgi "worker" process to serve dynamic
contents.
The Web server can communicate with the uWSGI_ process either:

* directly by the uWSGI_ protocol through a socket created by uWSGI_,
* or by proxying HTTP requests to the minimalist HTTP server built in
uWSGI_,

In the first case: the Web server can do uWSGI_ protocol (often with a
module). It can then use either a Unix domain socket (a "named pipe"
on Win32
systems), or it can use a TCP socket. What you choose is a matterr of
preference. Usually, a TCP socket is easier because connecting to a
port
doesn't require special permissions.

In the second case, the Web server doesn't need to do uWSGI_ protocol.
It just
needs to be able to proxy HTTP requests to the HTTP server built-in
uWSGI_.
The procedure is the same than proxying any HTTP server. Note that the
Web
server is a "reverse proxy" in this case.

Configuring the uWSGI server


In any case, when you set up your Web server, you'll just need to
point its
uwsgi or proxy module to the host/port or socket you specified when
starting
the uWSGI_ server.

.. admonition:: Choosing the socket

The easiest is to set the socket to a high level (>1024) local
port like
127.0.0.1:3000. If the socket is a file, the system administrator
must
ensure that the Web server process has read, write and execute
privileges
on that file.

uWSGI is highly configurable and thus there are many ways to start the
process. For example, uwsgi version 0.9.6.8 provides a hundred
switches.
This guide demonstrates the most important of them, but does not
intent to
substitute the official manual and online documentation.

uWSGI_ supports configuration through:

* command line switches
* ini files
* xml files

Managing the uWSGI server
-

The system administrator controls the worker process pool by sending
signals
to the master process. For example, the unix kill command sends such
signals.
uWSGI_ can write the master process id to a "pidfile". A "pidfile" is
a plain
text file containing just a process id.

Starting the server
---

Starting an uWSGI_ server is the role of the system administrator,
like
starting the Web server. It is *not* the role of the Web server to
start the
uWSGI_ server. This means:

* the uWSGI_ server can be restarted or reloaded independently from
the Web
  server,
* it is the role of the system administrator to make uWSGI_ to start
on boot
  or reboot: either through 

New messages API: regressions ?

[is_null]

Greetings hackers,

Django offered a feature to add messages to offline users, or to add
messages to users in slots (if that's the pythonic name for "functions
connected to signals"). It is still possible before 1.4, to call
myuser.message_set.create() which doesn't need the request object.

In 1.4, it will only be possible to add messages to online users and
only in code which has the request object in its scope. That means:

- no more adding messages to offline users
- no more adding messages to users in slots

A django hacker insisted that I should post on the list about this
change, in case you were not aware about the consequences which might
be seen as a regression.

Cheers

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