Hi all,
There are a lot of projects for making django deployment easier (a bit of
them are listed here: http://djangopackages.com/grids/g/deployment/ ) but
there is no clear winner, everybody have different preferences and
requirements. I think this all doesn't relate to development of django
Le 13 sept. 2011 à 05:44, Justine Tunney a écrit :
> I agree with you that reducing the barriers to using Django is very
> important. But what we need is not necessarily a web based installer, but
> something to get people off the ground so they can start playing around with
> Django very qui
The only reason Drupal is able to do that is because every cheap web hosting
provider supports PHP. If we made a web gui installer, the only people
who'd be able to use it would be people with root access and they're better
off using apt-get. There's no way to get people running Django on their
c
I think pretty much everything have been said about why this isn't
practical and why it's probably quite hard to implement "drop-in" apps
for django.
But there's one point that catched my attention: lowering entry level
for newcomers.
It's not because Django wasn't build with "drop-in" features i
Romain: My main argument is not for n00b developers, but just for any
nut with a server...
I want to be able to package my DJango project up into something as
easily installable as a Drupal distribution.
On Tue, Sep 13, 2011 at 4:47 AM, Romain Dorgueil wrote:
> Hi,
>
> it may be my first message
+1
On 9/12/11, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Jens,
>
> On 09/12/2011 10:20 AM, Jens Diemer wrote:
>>
>> I wonder that the CSRF token send from the client didn't be validated.
>
> Well, it is sanitized to only alphanumeric characters, but you're right
>
Oneliner:
re.sub('[^a-zA-Z0-9]', '', str(token.decode('ascii', 'ignore'))) if
(len(token) == 32) else ''
Cheers,
AT
On Mon, Sep 12, 2011 at 5:32 PM, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Jens,
>
> On 09/12/2011 10:20 AM, Jens Diemer wrote:
> >
> > I wonder
On Mon, Sep 12, 2011 at 3:44 PM, Carl Meyer wrote:
> Actually, I think there's generally consensus that requiring models.py
> is not ideal.
Yeah, that sounds about right. I get bitten by missing models.py all
the time, and I should supposedly know better. It's lousy usability,
so let's focus on g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Gary,
On 09/12/2011 12:04 AM, Gary Wilson Jr. wrote:
> I'm a fan of not requiring a models.py, as IMHO it shouldn't be any
> different than other common files found in an app e.g. urls.py,
> templatetags dir, etc. If I don't need any models for my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jens,
On 09/12/2011 10:20 AM, Jens Diemer wrote:
>
> I wonder that the CSRF token send from the client didn't be validated.
Well, it is sanitized to only alphanumeric characters, but you're right
that the length is never checked.
> Don't know if
A cleaned up version of my patch can be found at
http://paste.pocoo.org/show/474838/.
Test fixes aren't included in the paste, so modeltests/fixtures test
will not pass due to different ordering of the results. Github
contains the latest version including some test-fixing:
https://github.com/akaar
Hi,
it may be my first message on the list ever, but I wanted to put my 2
cents here.
From the PHP world, Symfony2 introduced a "web installer" system in its
"standard" distribution (which is the core + some fancyness).
To me, it's useless unless you want to attract people from a larger
au
On 12-09-11 18:25, Florian Apolloner wrote:
On Monday, September 12, 2011 5:39:03 PM UTC+2, Reinout van Rees wrote:
Addition: disallow attributes/methods starting with an underscore?
That's a handy way to stow away dangerous methods should you have them
in your view.
That's already
On Fri, Sep 9, 2011 at 4:56 PM, Alec Taylor wrote:
> Looks useable.
>
> Anyone interested in working with me to port this to DJango?
Alec, as other people have mentioned, Django is not Drupal. Drupal is
a web application that can be customized using plugins, where as
Django is a python library on
On Monday, September 12, 2011 5:39:03 PM UTC+2, Reinout van Rees wrote:
>
> Addition: disallow attributes/methods starting with an underscore?
>
> That's a handy way to stow away dangerous methods should you have them
> in your view.
>
That's already the case for resolving variables in templates
I wonder that the CSRF token send from the client didn't be validated.
Don't know if a DOS attack is possible by sending many request with very long
CSRF tokens?
IMHO it's a good idea to check the length before do anything with it.
e.g.:
--
On 10-09-11 00:15, Tobias wrote:
This is probably an overly simplistic implementation, but would
something like this work, more broadly covering Jacob's concerns in
the ticket about template authors being able to shoot themselves in
the foot? It seems less effective to mark all required methods
Here's an idea that might work better than a decorator:
Create a setting called ALLOW_DEACTIVATED_LOGINS. Then modify auth.login()
to enforce this as well as changing ModelBackend.get_user() to logout users
whose accounts are disabled. Make the setting True by default in 1.4 and
announce it'll b
On Sep 12, 3:38 pm, "Jonas H." wrote:
> On 09/12/2011 12:15 AM, Anssi Kääriäinen wrote:
>
> > The feature could be useful if there are users loading big fixture
> > files regularly. Otherwise it complicates fixture loading for little
> > gain.
>
> Maybe we could simply add an option to the loadd
On 09/12/2011 12:15 AM, Anssi Kääriäinen wrote:
The feature could be useful if there are users loading big fixture
files regularly. Otherwise it complicates fixture loading for little
gain.
Maybe we could simply add an option to the loaddata command -- so that
if someone really needs tons of f
I'll +1 the restriction of template tags to being arg/kwarg like. I see no
reason, other then porting already written tags, to worry about the ability to
do ``{% mytag foo as bar %}``. Personally I would think it would be desirable
to make this match python as much as possible. Python programmer
Hi all,
> For many years, writing templatetags has been among the most hilariously
> complicated things we Django developers did. Anyone who has written parsing
> for
> templatetags, over and over, shares this pain. Further, the current syntax
> present a tremendous problem for Armin Ronacher's G
Probably yeah, on the other hand the docs tell you that is_active doesn't
neccessarily have to be checked by backends, so if a backend allows to login
inactive users it makes no sense to check that flag in login_required… I
guess what I am proposing is that the login_required flag checks via the
On 09/12/2011 11:49 AM, Cal Leeming [Simplicity Media Ltd] wrote:
I may have misunderstood this thread slightly but, should templatetags
follow the same structure as *args, **kwargs??
i.e.
*args
{% create_title "hello world" 800 800 %}
**kwargs
{% create_title title="helloworld" width=800 heig
I may have misunderstood this thread slightly but, should templatetags
follow the same structure as *args, **kwargs??
i.e.
*args
{% create_title "hello world" 800 800 %}
**kwargs
{% create_title title="helloworld" width=800 height=800 %}
mixture
{% create_title "helloworld" width=800 height=800
On 09/12/2011 10:47 AM, lucky wrote:
Hello, Alex,
I agree with Wim Feijen. The ability to implement a arbitrary syntax
for tag parameters is too abstract problem and this causes an increase
in the complexity of the solution. Tag delelopers are forced to define
a grammar and deal with lexing and
Hello, Alex,
I agree with Wim Feijen. The ability to implement a arbitrary syntax
for tag parameters is too abstract problem and this causes an increase
in the complexity of the solution. Tag delelopers are forced to define
a grammar and deal with lexing and parsing. End users must to learn
and re
Hi Florian,
Then again, the default behaviour now is as you describe. That's why I
would call it a security leak.
Unfortunately, it is not only my system, it is the system of any
unaware Django programmer.
Wim
On Sep 11, 10:24 pm, Florian Apolloner wrote:
> On Sunday, September 11, 2011 8:52:0
28 matches
Mail list logo
