Re: PHP-inspired user-friendly in-browser DJango install

[Justine Tunney]

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
cheap cPanel hosting accounts.

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 quickly.  Back in the day (like circa 2004) the thing that
really helped me learn PHP was this program called EasyPHP which was a
simple Windows based installer that got me up and running and writing code
on my local machine in five minutes.

I'd like to see people start up a project for making a Windows installer for
Django that does the following:

- Bundles Python 2.7
- Uses important tools like distribute/pip/virtualenv/fabric
- Installs cygwin or mingw stuff if needed
- Has a simple GUI to do the following: a) ability generate a sqlite django
project skeletons, b) button to start/stop runserver, c) button to show the
site in your web browser, d) button to open a terminal in your project
folder, d) button to open the project folder in the file browser.

Whoever writes this tool could potentially make a lot of money because they
could also write a deployment tool for deploying sites to places like
Gondor.

On Mon, Sep 12, 2011 at 7:54 PM, Alec Taylor  wrote:

> 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 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
> audience
> > than what the framework is aimed at at first. I personally don't want
> some
> > useless (or use-once at best) code to be around my project, and I don't
> > think it's the role of a developper-oriented piece of software to provide
> > such things. Of course, a more "newbie-friendly" may be "nice-to-have",
> but
> > imho the "core" of a framework should not provide such thing.
> >
> > Romain.
> >
> > On 12/09/2011 18:39, Tom Evans wrote:
> >>
> >> 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 one can use to create web applications.
> >> With that in mind, 'porting this to django' is nonsensical - PyLucid
> >> uses Django already, and Django is only the framework, not the
> >> project.
> >>
> >> The point here is that two different web apps created using Django
> >> could have vastly different requirements and installation steps, where
> >> as Drupal has a single set of steps to go from nothing to installed.
> >>
> >> In fact, its quite common to have the same project installed and
> >> running in completely different manners. For instance on our
> >> production servers, all libraries/code/templates, even in house ones,
> >> are installed from our internal package repository (an in house pypi
> >> clone), where as in development, each package is checked out from
> >> subversion in an editable form.
> >>
> >> PyLucid is a good example of a project based on django providing
> >> simple and clean installation instructions - although I wouldn't
> >> deploy it quite like that myself, any solution which uses .htaccess is
> >> Bad and Wrong imo*.
> >>
> >>> (the reason I'm not doing it myself is that I am very new to Python and
> >>> DJango)
> >>>
> >> And (not to be too harsh) this is why you are suggesting it. Django is
> >> like a tool, admittedly it's one of those Leatherman style multi tools
> >> that you can use to do almost anything, but it's still a tool for you
> >> to use rather than a base.
> >>
> >> Cheers
> >>
> >> Tom
> >>
> >> * de gustibus non est disputandum
> >>
> >
> > --
> > 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 

Re: PHP-inspired user-friendly in-browser DJango install

[h3]

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 in mind
that it's not possible to lower the entry level.

Not long ago, I've started working on doing exactly that.

I've written a Python package which makes django development a
breeze.. at least for me so far. It's basically a thin wrapper for
fabric, pip & virtualenv.

Among other sweet things, with simple commands I can:

 * Configure it for an existing project
 * Enter development mode (activate virtualenv, creates it and install
requirements if non-existents)
 * Update clear/requirements, restart apache, syncdb on any stages
(dev, demo, beta, prod)
 * Deploy to any stages (configured ssh keys makes it's even easier)

To be honest the deploy part works, but it still needs a bit of
polishing. However all the other commands are so damn useful in my
everyday work that it's really worth using.

My motivation was twofold:

 1. Type less. I hate having to type the same thing over and over and
Ctrl+R has its limits. I run a business and it's a waste of time. I
often work on more than 10 projects at the same time, if my package
makes me save more than 100 commands over the their lifetime of a
project, it's already worth it.

 2. Collaboration. Where I live Django isn't quite popular, in fact it
barely exists. Even most web design companies and programmers never
heard of it. And most developers never heard of pip, fabric,
virtualenv or even rsync for that matter. I know it sucks, but I have
to deal with it. So the faster I can set an developer on track, the
faster he can generate the profits necessary to pay his salary.

Now don't worry, the reason I write a reply on this thread is not
because I think such tool should be included in django core.

But as a whole, I think the django community would gain a lot by
promoting or even building such external tool.

A different project, aimed at setting developers on track in no time.


I know many tools exists and there's many ways to setup and use
django, but just like Python itself there is optimal ways to do it.

I think Django should advocate good practices, but also try to make
developers' life easier.

At the end of the day it would pay off.

For those who are interested, my project is hosted there:
https://github.com/h3/python-dad/tree/master/dad

Most of the docs are still hosted there (moving to docs/ & rtd):
http://code.google.com/p/python-dad/w/list

I welcome comments, suggestions and pull requests :)


On Sep 12, 2:47 pm, Romain Dorgueil  wrote:
> 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
> audience than what the framework is aimed at at first. I personally
> don't want some useless (or use-once at best) code to be around my
> project, and I don't think it's the role of a developper-oriented piece
> of software to provide such things. Of course, a more "newbie-friendly"
> may be "nice-to-have", but imho the "core" of a framework should not
> provide such thing.
>
> Romain.
>
> On 12/09/2011 18:39, Tom Evans wrote:
>
>
>
>
>
>
>
> > 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 one can use to create web applications.
> > With that in mind, 'porting this to django' is nonsensical - PyLucid
> > uses Django already, and Django is only the framework, not the
> > project.
>
> > The point here is that two different web apps created using Django
> > could have vastly different requirements and installation steps, where
> > as Drupal has a single set of steps to go from nothing to installed.
>
> > In fact, its quite common to have the same project installed and
> > running in completely different manners. For instance on our
> > production servers, all libraries/code/templates, even in house ones,
> > are installed from our internal package repository (an in house pypi
> > clone), where as in development, each package is checked out from
> > subversion in an editable form.
>
> > PyLucid is a good example of a project based on django providing
> > simple and clean installation instructions - although I wouldn't
> > deploy it quite like that myself, any solution which uses .htaccess is
> > Bad and Wrong imo*.
>
> >> (the reason I'm not doing it myself is that I am very new to Python and 
> >> DJango)
>
> > And 

Re: PHP-inspired user-friendly in-browser DJango install

[Alec Taylor]

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 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 audience
> than what the framework is aimed at at first. I personally don't want some
> useless (or use-once at best) code to be around my project, and I don't
> think it's the role of a developper-oriented piece of software to provide
> such things. Of course, a more "newbie-friendly" may be "nice-to-have", but
> imho the "core" of a framework should not provide such thing.
>
> Romain.
>
> On 12/09/2011 18:39, Tom Evans wrote:
>>
>> 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 one can use to create web applications.
>> With that in mind, 'porting this to django' is nonsensical - PyLucid
>> uses Django already, and Django is only the framework, not the
>> project.
>>
>> The point here is that two different web apps created using Django
>> could have vastly different requirements and installation steps, where
>> as Drupal has a single set of steps to go from nothing to installed.
>>
>> In fact, its quite common to have the same project installed and
>> running in completely different manners. For instance on our
>> production servers, all libraries/code/templates, even in house ones,
>> are installed from our internal package repository (an in house pypi
>> clone), where as in development, each package is checked out from
>> subversion in an editable form.
>>
>> PyLucid is a good example of a project based on django providing
>> simple and clean installation instructions - although I wouldn't
>> deploy it quite like that myself, any solution which uses .htaccess is
>> Bad and Wrong imo*.
>>
>>> (the reason I'm not doing it myself is that I am very new to Python and
>>> DJango)
>>>
>> And (not to be too harsh) this is why you are suggesting it. Django is
>> like a tool, admittedly it's one of those Leatherman style multi tools
>> that you can use to do almost anything, but it's still a tool for you
>> to use rather than a base.
>>
>> Cheers
>>
>> Tom
>>
>> * de gustibus non est disputandum
>>
>
> --
> 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-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: CSRF token not validated?

[Babatunde Akinyanmi]

+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
> that the length is never checked.
>
>> 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.
>
> Sanity-checking the length sounds reasonable to me - do you mind opening
> a ticket for this and attaching your patch?
>
> Thanks,
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk5ubHQACgkQ8W4rlRKtE2frrQCgr8HhCPKaPGKyTocUGnmiU9Ku
> ekYAoNgZqJ/n4SJnd1tD2Zkpeb/+du47
> =ZWv6
> -END PGP SIGNATURE-
>
> --
> 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.
>
>

-- 
Sent from my mobile device

-- 
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: CSRF token not validated?

[Andre Terra]

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 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 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.
>
> Sanity-checking the length sounds reasonable to me - do you mind opening
> a ticket for this and attaching your patch?
>
> Thanks,
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk5ubHQACgkQ8W4rlRKtE2frrQCgr8HhCPKaPGKyTocUGnmiU9Ku
> ekYAoNgZqJ/n4SJnd1tD2Zkpeb/+du47
> =ZWv6
> -END PGP SIGNATURE-
>
> --
> 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-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: #7198 - Better error message when app is missing models.py

[Jacob Kaplan-Moss]

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 getting rid of the requirement not fixing the error
message.

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-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: #7198 - Better error message when app is missing models.py

[Carl Meyer]

-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 app, then
> why must I still have a models.py?  That said, it also seems there
> could be some backwards incompatibilities if code or external tools
> rely on a valid app including a models.py file.

Actually, I think there's generally consensus that requiring models.py
is not ideal. There's already an existing GSoC branch (app-loading),
which already fixes the models.py issue (AFAIK) but is somewhat
languishing for lack of attention. So I think the best path towards
getting that fixed is to check out that branch and help get it in
merge-ready shape. Jannis was the mentor for that GSoC, he or Arthur
Koziel (the student) can probably comment most knowledgeably about what
needs to be done.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5ub0QACgkQ8W4rlRKtE2cISACgh/lYqhb4OR4aqllMPR4xyG4P
c8MAnRyh+tdcXCpxTq6Z8g5L+MNNC7ZX
=pVuz
-END PGP SIGNATURE-

-- 
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: CSRF token not validated?

[Carl Meyer]

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

Sanity-checking the length sounds reasonable to me - do you mind opening
a ticket for this and attaching your patch?

Thanks,

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5ubHQACgkQ8W4rlRKtE2frrQCgr8HhCPKaPGKyTocUGnmiU9Ku
ekYAoNgZqJ/n4SJnd1tD2Zkpeb/+du47
=ZWv6
-END PGP SIGNATURE-

-- 
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: Fixture loading using bulk_create

[Anssi Kääriäinen]

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/akaariai/django/tree/fixture_loading

I hope the patch will help in solving the natural keys problem. The
biggest problem is that the patch doesn't handle maximum amount of SQL
parameters. Give it 100 serialized instances of a model containing 10
fields and it will fail.

 - Anssi

On Sep 12, 4:41 pm, Anssi Kääriäinen  wrote:
> 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 loaddata command -- so that
> > if someone really needs tons of fixtures for their tests it's possible
> > to profit from bulk insertions by manually invoking loaddata from their
> > test code. And the implementation is quite simple:
>
> >http://paste.pocoo.org/show/474602/(doesn'tcover all edge-cases yet)
>
> > I did some benchmarking with this code and it speeds up fixture loading
> > *a lot*:http://www.chartgo.com/get.do?id=bdfe6af778(chunksize=0does
> > not use `bulk_create` but `save`, and the speedups seen for chunksize=1
> > is because `bulk_create` is used, thus avoiding `save` overhead)
>
> > Jonas
>
> I like this idea much better than trying to hack loaddata to use
> bulk_create while maintaining compatibility with the current code.
>
> The hard limitations would be as follows:
>   - There must not be any updates.
>
> Then there are limitations which could be lifted later on:
>
>   - No natural keys (or the targets of the natural keys must exists in
> the DB). I think this could be lifted later on - the dumped objects
> are ordered in a way that natural keys do not form circles - just save
> the objects in the same order and resolve the natural keys when saving
> - not when deserializing.
>
>   - Inherited models must be saved using the normal way. This could be
> lifted: make bulk_create insert inherited objects if they have PK set
> trusting that the user will insert the base objects in the same
> transaction, or that they are already present. That is, create a
> similar "raw" mode for bulk create that exists for Model.save_base.
>
>   - Objects with M2M data are saved the normal way. This could be
> improved later on, so that m2m data would also be bulk saved along
> with the objects.
>
>   - All objects must be loaded into memory: this is easy to lift, just
> flush the collected objects once per N objects. I am not sure of this,
> but you probably can flush the collected objects also once you find
> out a new class - the objects are serialized class at a time.
>
>   - Signals aren't sent at all. It is easy to batch send the signals
> if wanted.
>
> My version of the patch solves all those cases in a way compatible
> with the current implementation. The biggest difference to your
> version is that my version can be used when running tests - but the
> speed difference for Django's test suite is somewhere around 2-3%. The
> cost is some added complexity, and one select per batch to see which
> PKs are already in the DB and which ones not. So it seems there is not
> much point for the added complexity.
>
> The most difficult problem is that my patch _will_ break some users
> fixture loading due to the SQL length / parameter amount limitations
> of different backends. This is hard to solve cleanly. For example
> SQLite3 seems to have a 999 parameter limitation, so that you can save
> 333 three field models, 99 ten field models or just 10 hundred field
> models. If you have a bulk_create flag, then the backwards
> incompatibility is not a problem.
>
> So, in summary, it seems having a bulk_create flag is the only way
> forward.
>
>  - Anssi

-- 
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: PHP-inspired user-friendly in-browser DJango install

[Romain Dorgueil]

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 
audience than what the framework is aimed at at first. I personally 
don't want some useless (or use-once at best) code to be around my 
project, and I don't think it's the role of a developper-oriented piece 
of software to provide such things. Of course, a more "newbie-friendly" 
may be "nice-to-have", but imho the "core" of a framework should not 
provide such thing.


Romain.

On 12/09/2011 18:39, Tom Evans wrote:

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 one can use to create web applications.
With that in mind, 'porting this to django' is nonsensical - PyLucid
uses Django already, and Django is only the framework, not the
project.

The point here is that two different web apps created using Django
could have vastly different requirements and installation steps, where
as Drupal has a single set of steps to go from nothing to installed.

In fact, its quite common to have the same project installed and
running in completely different manners. For instance on our
production servers, all libraries/code/templates, even in house ones,
are installed from our internal package repository (an in house pypi
clone), where as in development, each package is checked out from
subversion in an editable form.

PyLucid is a good example of a project based on django providing
simple and clean installation instructions - although I wouldn't
deploy it quite like that myself, any solution which uses .htaccess is
Bad and Wrong imo*.


(the reason I'm not doing it myself is that I am very new to Python and DJango)


And (not to be too harsh) this is why you are suggesting it. Django is
like a tool, admittedly it's one of those Leatherman style multi tools
that you can use to do almost anything, but it's still a tool for you
to use rather than a base.

Cheers

Tom

* de gustibus non est disputandum



--
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: class based views: object instead of dictionary as context?

[Reinout van Rees]

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 the case for resolving variables in templates, I don't
think we need any specialcasing here.

 > The only way I can see yourself shooting in the foot is
when you have a
 > form view that reacts to get() and post(). Upon "get()",
the template

 > *could* call data-modifying methods on the class.


Not easily, since the templates can only call methods which don't
require extra params, get/post do take request at least.


I love it when problems solve themselves :-)


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 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: PHP-inspired user-friendly in-browser DJango install

[Tom Evans]

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 one can use to create web applications.
With that in mind, 'porting this to django' is nonsensical - PyLucid
uses Django already, and Django is only the framework, not the
project.

The point here is that two different web apps created using Django
could have vastly different requirements and installation steps, where
as Drupal has a single set of steps to go from nothing to installed.

In fact, its quite common to have the same project installed and
running in completely different manners. For instance on our
production servers, all libraries/code/templates, even in house ones,
are installed from our internal package repository (an in house pypi
clone), where as in development, each package is checked out from
subversion in an editable form.

PyLucid is a good example of a project based on django providing
simple and clean installation instructions - although I wouldn't
deploy it quite like that myself, any solution which uses .htaccess is
Bad and Wrong imo*.

>
> (the reason I'm not doing it myself is that I am very new to Python and 
> DJango)
>

And (not to be too harsh) this is why you are suggesting it. Django is
like a tool, admittedly it's one of those Leatherman style multi tools
that you can use to do almost anything, but it's still a tool for you
to use rather than a base.

Cheers

Tom

* de gustibus non est disputandum

-- 
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: class based views: object instead of dictionary as context?

[Florian Apolloner]

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 don't think 
we need any specialcasing here.

> The only way I can see yourself shooting in the foot is when you have a 
> form view that reacts to get() and post(). Upon "get()", the template 

> *could* call data-modifying methods on the class. 


Not easily, since the templates can only call methods which don't require 
extra params, get/post do take request at least. 

Cheers,
Florian

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

CSRF token not validated?

[Jens Diemer]

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.:
--
diff --git a/django/middleware/csrf.py b/django/middleware/csrf.py
index b5a8579..8e03635 100644
--- a/django/middleware/csrf.py
+++ b/django/middleware/csrf.py
@@ -72,7 +72,10 @@ def get_token(request):
 def _sanitize_token(token):
 # Allow only alphanum, and ensure we return a 'str' for the sake of the 
post
 # processing middleware.
-token = re.sub('[^a-zA-Z0-9]', '', str(token.decode('ascii', 'ignore')))
+if len(token) != 32:
+token = ""
+else:
+token = re.sub('[^a-zA-Z0-9]', '', str(token.decode('ascii', 
'ignore')))
 if token == "":
 # In case the cookie has been truncated to nothing at some point.
 return _get_new_csrf_key()
--


--

Mfg.

Jens Diemer



http://www.jensdiemer.de

--
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: class based views: object instead of dictionary as context?

[Reinout van Rees]

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 with
alters_data, as this method also wouldn't prevent get(), post(), etc.
from being called in subclassed views (which could potentially
generate recursive loops).

https://github.com/tobiasmcnulty/django/compare/master...ticket-16744


It is already more elaborate than what I'm using locally now :-) I don't 
have a proxy object in my own views. Seems like a good idea, though.


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.


The only way I can see yourself shooting in the foot is when you have a 
form view that reacts to get() and post(). Upon "get()", the template 
*could* call data-modifying methods on the class.




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 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: plea for re-opening ticket 13125 marked as won't fix

[Justine Tunney]

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 be set to False in either 1.5 or 1.6.

This way is_active can be secure by default, not require users to implement
its functionality themselves while also following the principle of least
astonishment.  The only confusing this about this solution is that users
might not understand it doesn't affect the admin login form and
auth.views.login

On Mon, Sep 12, 2011 at 3:43 AM, Florian Apolloner wrote:

> 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
> auth backends whether or not the user should be allowed to pass, that way
> all the neccessary checks stay in one place…
>
>  --
> 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/-/A922lTjpZc8J.
>
> 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-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: Fixture loading using bulk_create

[Anssi Kääriäinen]

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 loaddata command -- so that
> if someone really needs tons of fixtures for their tests it's possible
> to profit from bulk insertions by manually invoking loaddata from their
> test code. And the implementation is quite simple:
>
> http://paste.pocoo.org/show/474602/(doesn't cover all edge-cases yet)
>
> I did some benchmarking with this code and it speeds up fixture loading
> *a lot*:http://www.chartgo.com/get.do?id=bdfe6af778(chunksize=0 does
> not use `bulk_create` but `save`, and the speedups seen for chunksize=1
> is because `bulk_create` is used, thus avoiding `save` overhead)
>
> Jonas

I like this idea much better than trying to hack loaddata to use
bulk_create while maintaining compatibility with the current code.

The hard limitations would be as follows:
  - There must not be any updates.

Then there are limitations which could be lifted later on:

  - No natural keys (or the targets of the natural keys must exists in
the DB). I think this could be lifted later on - the dumped objects
are ordered in a way that natural keys do not form circles - just save
the objects in the same order and resolve the natural keys when saving
- not when deserializing.

  - Inherited models must be saved using the normal way. This could be
lifted: make bulk_create insert inherited objects if they have PK set
trusting that the user will insert the base objects in the same
transaction, or that they are already present. That is, create a
similar "raw" mode for bulk create that exists for Model.save_base.

  - Objects with M2M data are saved the normal way. This could be
improved later on, so that m2m data would also be bulk saved along
with the objects.

  - All objects must be loaded into memory: this is easy to lift, just
flush the collected objects once per N objects. I am not sure of this,
but you probably can flush the collected objects also once you find
out a new class - the objects are serialized class at a time.

  - Signals aren't sent at all. It is easy to batch send the signals
if wanted.

My version of the patch solves all those cases in a way compatible
with the current implementation. The biggest difference to your
version is that my version can be used when running tests - but the
speed difference for Django's test suite is somewhere around 2-3%. The
cost is some added complexity, and one select per batch to see which
PKs are already in the DB and which ones not. So it seems there is not
much point for the added complexity.

The most difficult problem is that my patch _will_ break some users
fixture loading due to the SQL length / parameter amount limitations
of different backends. This is hard to solve cleanly. For example
SQLite3 seems to have a 999 parameter limitation, so that you can save
333 three field models, 99 ten field models or just 10 hundred field
models. If you have a bulk_create flag, then the backwards
incompatibility is not a problem.

So, in summary, it seems having a bulk_create flag is the only way
forward.

 - Anssi

-- 
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: Fixture loading using bulk_create

[Jonas H.]

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 fixtures for their tests it's possible 
to profit from bulk insertions by manually invoking loaddata from their 
test code. And the implementation is quite simple:


http://paste.pocoo.org/show/474602/ (doesn't cover all edge-cases yet)

I did some benchmarking with this code and it speeds up fixture loading 
*a lot*: http://www.chartgo.com/get.do?id=bdfe6af778 (chunksize=0 does 
not use `bulk_create` but `save`, and the speedups seen for chunksize=1 
is because `bulk_create` is used, thus avoiding `save` overhead)


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-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: Proposal for a new templatetag definition syntax

[Donald Stufft]

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 programmers will find it 
more familiar then attempting to turn parameter passing into a parsing 
situation, and non python programmers will find it simple enough learn quickly. 
Being a restricted grammar, it also has the benefit to have less surprises, you 
don't have to worry about how this random tag works, there's one (obvious) way 
of doing it.

Something like

class MyTag(tags.Tag):
 width = tag.IntegerArgument()
 height = tag.IntegerArgument()
 using = tag.StringArgument(required=False)
 as = tag.StringArgument(required=False, default=None)

which would translate to:

``{% mytag 600 700 %}``
``{% mytag 600 700 as="mytag_return" %}``
``{% mytag 600 700 "template_name.html" %}``
``{% mytag 600 600 using="template_name.html" as="mytag_return" %}``

The only thing I really don't like about this is the ``as`` kwarg. We could 
stuff a boolean into a Meta class that is something like ``allow_assignment`` 
which will support something more like what we have now…

``{% mytag 600 700 as "mytag_return" %}``
``{% mytag 600 700 "template_name.html" as "mytag_return" %}``
``{% mytag 600 700 using="template_name.html" as "mytag_return" %}``

With the stipulation that the as [keyword] must appear as the last item in the 
tag.

On Monday, September 12, 2011 at 7:17 AM, Jannis Leidel wrote:  
> 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 GSOC towards template
> > compilation: template tags define a ``render()`` method, which takes the
> > current context (a stack of dictionaries) and perform some behavior which is
> > opaque to the caller. This is a problem because one of the core objectives 
> > of
> > the template compilation infrastructure is to store the template context in
> > Python local variables, rather than in dictionaries. For all these reasons,
> > several of us (myself, Idan, Russ, Carl Meyer, Andrew Godwin, Jonas Obrist,
> > Chris Beaven) just sat down (we actually stood, mostly) and tried to iron 
> > out a
> > proposal that solves these problems, taking inspiration from the plethora of
> > libraries that exist today.
> >  
> > We ultimately created two possible solutions, one inspired primarily by
> > django-classy-tags and django-templatetag-sugar, the other mostly inspired 
> > by
> > django-ttags.
>  
> FTR, the app is called django-ttag, not django-ttags.
>  
> > We came to a fragile agreement on the first. We primarily
> > evaluated two cases for these, one very simple, the other more complex, and
> > compared the resulting implementations.
> >  
> > The first case we considered was a templatetag which takes two, required,
> > arguments. Invocation looks like ``{% mytag foo bar %}``. The two 
> > definitions
> > look like:
> >  
> >  class MyTag(Tag):
> >  args = [
> >  Argument("foo"),
> >  Argument("bar"),
> >  ]
> >  
> >  
> >  class MyTag(Tag):
> >  foo = Argument()
> >  bar = Argument()
> >  
> >  
> > the second case we considered was a tag which has one required, positional,
> > argument, and two optional, keyword arguments, which can occur in any order,
> > followed by a final, optional keyword argument, meaning any of the following
> > invocations are valid:
> >  
> >  {% mytag src limit 1 offset 10 %}
> >  {% mytag src limit 1 offset 10 with foo %}
> >  {% mytag src limit 1 %}
> >  {% mytag src offset 10 limit 1 %}
> >  {% mytag src %}
> >  
> > and the two implementations were:
> >  
> >  class MyTag(Tag):
> >  args = [
> >  Argument("source"),
> >  Unordered(
> >  NamedArgument("limit", required=False),
> >  NamedArgument("offset", required=False),
> >  ),
> >  NamedArgument("as", required=False, resolve=False)
> >  ]
> >  
> >  
> >  class MyTag(Tag):
> >  source = Argument()
> >  limit = NamedArgument(required=False)
> >  offset = NamedArgument(required=False)
> >  as_ = BasicArgument(required=False)
> >  
> >  class Meta:
> >  ordering = (
> >  ('source',),
> >  Unordered('limit', 'offset'),
> >  ('as_',)
> >  )
> >  
> > The general consensus was that the second implementation was *very* slightly
> > preferable in the simple case, however it was significantly more 
> > complicated in
> > the second case, and thus the first implementation was preferable overall.
>  
> I'd like to express my sincere discomfort with the two example cases you used
> to develop the API. At least from the experience I have with writing template
> tags (with the standard API, @simple_tag, django-template-sugar,
> django-classy-tags and django-tagcon/ttag) 

Re: Proposal for a new templatetag definition syntax

[Jannis Leidel]

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 GSOC towards template
> compilation: template tags define a ``render()`` method, which takes the
> current context (a stack of dictionaries) and perform some behavior which is
> opaque to the caller. This is a problem because one of the core objectives of
> the template compilation infrastructure is to store the template context in
> Python local variables, rather than in dictionaries. For all these reasons,
> several of us (myself, Idan, Russ, Carl Meyer, Andrew Godwin, Jonas Obrist,
> Chris Beaven) just sat down (we actually stood, mostly) and tried to iron out 
> a
> proposal that solves these problems, taking inspiration from the plethora of
> libraries that exist today.
> 
> We ultimately created two possible solutions, one inspired primarily by
> django-classy-tags and django-templatetag-sugar, the other mostly inspired by
> django-ttags.

FTR, the app is called django-ttag, not django-ttags.

> We came to a fragile agreement on the first. We primarily
> evaluated two cases for these, one very simple, the other more complex, and
> compared the resulting implementations.
> 
> The first case we considered was a templatetag which takes two, required,
> arguments. Invocation looks like ``{% mytag foo bar %}``.  The two definitions
> look like:
> 
> class MyTag(Tag):
> args = [
> Argument("foo"),
> Argument("bar"),
> ]
> 
> 
> class MyTag(Tag):
> foo = Argument()
> bar = Argument()
> 
> 
> the second case we considered was a tag which has one required, positional,
> argument, and two optional, keyword arguments, which can occur in any order,
> followed by a final, optional keyword argument, meaning any of the following
> invocations are valid:
> 
> {% mytag src limit 1 offset 10 %}
> {% mytag src limit 1 offset 10 with foo %}
> {% mytag src limit 1 %}
> {% mytag src offset 10 limit 1 %}
> {% mytag src %}
> 
> and the two implementations were:
> 
> class MyTag(Tag):
> args = [
> Argument("source"),
> Unordered(
> NamedArgument("limit", required=False),
> NamedArgument("offset", required=False),
> ),
> NamedArgument("as", required=False, resolve=False)
> ]
> 
> 
> class MyTag(Tag):
> source = Argument()
> limit = NamedArgument(required=False)
> offset = NamedArgument(required=False)
> as_ = BasicArgument(required=False)
> 
> class Meta:
> ordering = (
> ('source',),
> Unordered('limit', 'offset'),
> ('as_',)
> )
> 
> The general consensus was that the second implementation was *very* slightly
> preferable in the simple case, however it was significantly more complicated 
> in
> the second case, and thus the first implementation was preferable overall.

I'd like to express my sincere discomfort with the two example cases you used
to develop the API. At least from the experience I have with writing template
tags (with the standard API, @simple_tag, django-template-sugar,
django-classy-tags and django-tagcon/ttag) it was the simple use cases that
were more common, rather than the complex in day-to-day work. While one could
say that this has something to do with my coding style and clients, I'd have
to say that keeping the template tag API simple instead of complex has always
been a major goal. So unless there was a decision to start encouraging moving
business logic from the views to template tags (which would be indicated by
increased complexity) I don't see a reason to prefer the API that allows
complex API.

As a matter of remote contribution to the discussion at the sprint, I've just
checked if django-ttag (the example which you preferred for the simple case)
is capable of passing your complex case, too (yes):

 https://github.com/jezdez/django-ttag/compare/django-tag-api

I'm happy that there was some discussion at the conference sprint though,
since it's an important topic, but I'd appreciate if you'd provide further
explanation of why you prefer the first, django-classy-tag and
django-template-sugar influenced example.

Since I've also worked on django-ttag (including when it was still called
django-tagcon a long time ago) quite a bit, I assume you mostly discussed how
to handle ordering the different kinds of arguments (positional vs. keyword
vs. "named" arguments). Luckily we already have a pretty strong convention for
that, as you can see when specifying forms or models. Which is why I'm
confused why an "args" class attribute would be needed in your preferred 
example.
Any elaboration as to why this verbose 

Re: plea for re-opening ticket 13125 marked as won't fix

[Florian Apolloner]

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 
auth backends whether or not the user should be allowed to pass, that way 
all the neccessary checks stay in one place…

-- 
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/-/A922lTjpZc8J.
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: Proposal for a new templatetag definition syntax

[Jonas H.]

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 height=800 %}

mixture
{% create_title "helloworld" width=800 height=800 %}

Apologies if I have completely missed the point of this thread.

Cal


I guess it's not the "point of this thread" but rather Evgeny's design 
proposal. Alex' intention seems to be discussion on a new syntax to 
define template tags.


--
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: Proposal for a new templatetag definition syntax

[Cal Leeming [Simplicity Media Ltd]]

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

Apologies if I have completely missed the point of this thread.

Cal

On Mon, Sep 12, 2011 at 10:39 AM, Jonas H.  wrote:

> 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 parsing. End users must to learn
>> and remember a custom syntax for each of tags. [...]
>>
>>
>> We should not be afraid of the python-like grammar for tag
>> paramenters. There is not principal difference beetween custom {%
>> mytag src limit 1 offset 10 %} and pythonic {% mytag src limit=1
>> offset=10 %}. The restrict syntax makes the solution simpler.
>>
>
> +1
>
> Template tags should be forced to have a simple syntax. Users should not
> have to look up the syntax each time.
>
> --
> 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+unsubscribe@**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-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: Proposal for a new templatetag definition syntax

[Jonas H.]

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 parsing. End users must to learn
and remember a custom syntax for each of tags. [...]

We should not be afraid of the python-like grammar for tag
paramenters. There is not principal difference beetween custom {%
mytag src limit 1 offset 10 %} and pythonic {% mytag src limit=1
offset=10 %}. The restrict syntax makes the solution simpler.


+1

Template tags should be forced to have a simple syntax. Users should not 
have to look up the syntax each time.


--
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: Proposal for a new templatetag definition syntax

[lucky]

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 remember a custom syntax for each of tags. A similar problem is
solved by developers of python for CLI, and they came up with `http://
docs.python.org/library/argparse.html` library (however, in our case
it is too complicated way, imho).

The writing of templates should be an easy work, with a low threshold
to entry. It would be nice if template tags will provide us with some
common basic syntax for most of them. Without the need to develop a
grammar and to RTFM a tag parameters syntax when we are need to use
them. The description of the custom syntax have be resorted to only
when absolutely necessary.

We should not be afraid of the python-like grammar for tag
paramenters. There is not principal difference beetween custom {%
mytag src limit 1 offset 10 %} and pythonic {% mytag src limit=1
offset=10 %}. The restrict syntax makes the solution simpler.

The saving of results in context variable looks like a common task and
it should be delegated to an external tool (like a filter {% mytag src|
as:bar %}).

There are just few cases where custom syntaxis is nesessary. For
example the logic and mathematical expressions with rich grammar
rules. But simplest way in those cases is to use specialized
libraries, there problems of grammar definition, lexing and parsing
already solved. Look http://pyparsing.wikispaces.com/ for example.

Evgeny

--
I'm sorry for my silly english


On Sep 11, 2:11 am, Alex Gaynor  wrote:
> On Fri, Sep 9, 2011 at 6:16 PM, Wim Feijen  wrote:
> > Hi Alex,
>
> > Probably I am thinking way too simple, but if you gave me a free
> > choice of how to write templatetags in my code, I would prefer:
>
> > def mytag(foo, bar):
> >     # some code
> >     return output
>
> > or:
>
> > class MyTag(Tag):
> >    def __init__(self, foo, bar):
> >        self.foo = foo
> >        self.bar = bar
>
> > and
>
> > def mytag(src, limit=1, offset=10, ??)
>
> > or:
>
> > class MyTag(Tag):
> >    def __init__(self, limit=1, offset=10, ??):
> >        self.limit = limit
> >        self.offset = offset
>
> >   def render(self):
> >   """do some nasty stuff to limit and offset and return something."""
>
> > Just kick me if I am talking non-sense, that's ok.
>
> > Wim
>
> > On 10 sep, 02:29, Alex Gaynor  wrote:
> > > Hello 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 GSOC towards template
> > > compilation: template tags define a ``render()`` method, which takes the
> > > current context (a stack of dictionaries) and perform some behavior which
> > is
> > > opaque to the caller. This is a problem because one of the core
> > objectives
> > > of
> > > the template compilation infrastructure is to store the template context
> > in
> > > Python local variables, rather than in dictionaries. For all these
> > reasons,
> > > several of us (myself, Idan, Russ, Carl Meyer, Andrew Godwin, Jonas
> > Obrist,
> > > Chris Beaven) just sat down (we actually stood, mostly) and tried to iron
> > > out a
> > > proposal that solves these problems, taking inspiration from the plethora
> > of
> > > libraries that exist today.
>
> > > We ultimately created two possible solutions, one inspired primarily by
> > > django-classy-tags and django-templatetag-sugar, the other mostly
> > inspired
> > > by
> > > django-ttags. We came to a fragile agreement on the first. We primarily
> > > evaluated two cases for these, one very simple, the other more complex,
> > and
> > > compared the resulting implementations.
>
> > > The first case we considered was a templatetag which takes two, required,
> > > arguments. Invocation looks like ``{% mytag foo bar %}``.  The two
> > > definitions
> > > look like:
>
> > >     class MyTag(Tag):
> > >         args = [
> > >             Argument("foo"),
> > >             Argument("bar"),
> > >         ]
>
> > >     class MyTag(Tag):
> > >         foo = Argument()
> > >         bar = Argument()
>
> > > the second case we considered was a tag which has one required,
> > positional,
> > > argument, and two optional, keyword arguments, which can occur in any
> > order,
> > > followed by a final, optional keyword argument, meaning any of the
> > following
> > > invocations are valid:
>
> > >     {% mytag src limit 1 offset 10 %}
> > >     {% mytag src limit 1 offset 10 with foo %}
> > >     {% mytag src limit 1 %}
> > >     {% mytag src offset 10 limit 1 %}
> > >     {% mytag src %}
>
> > 

Re: plea for re-opening ticket 13125 marked as won't fix

[Wim Feijen]

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:03 PM UTC+2, Wim Feijen wrote:
>
> > 3. Because the user is still logged in, (maybe for two weeks, or for
> > whatever expiration time the developer has set)
>
> Imo in that case the developer should write a middleware that logs the user
> out on the next request. I see your problem, but imo your system needs a bit
> of tweaking if you allow inactive users to browse your site till their
> session expires (which with SAVE_EVERY_REQUEST +  a high timeout) could as
> well be never…

-- 
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: Proposal for a new templatetag definition syntax

[Anssi Kääriäinen]

On Sep 11, 10:36 pm, Mikhail Korobov  wrote:
> I gave up defining this template tag with existing template tag libraries:
>
> {% easy_map  [ ] [] [using ] %}
>
> Can positional arguments be optional? Will it be possible to express this
> syntax?

>From the department of stupid ideas: Would it be possible to support
the above syntax? I mean, the MyTag definition would be just:

class MyTag(Tag):
syntax = "mytag  [ ] [] [using
]"

That would be my preferred solution.

There is just the little problem of how to parse the syntax. I don't
know how to do that. If there is any support for this idea, I am
willing to check if this is possible.

 - Anssi

-- 
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: #7198 - Better error message when app is missing models.py

[Gary Wilson Jr.]

On Fri, Sep 9, 2011 at 4:35 PM, Justin Lilly  wrote:
> Not sure why this particular ticket is marked as DDN, as it seems like
> a no-brainer. The patch provides a more clear error message when a
> user is attempting to load an app which doesn't have a models.py.
>
> https://code.djangoproject.com/ticket/7198
> https://github.com/django/django/pull/39
>
> Happy to respond to any feedback, as I think this is a worthwhile
> change.

As Carl recently commented on the referenced ticket, the DDN was
likely due to a decision on whether or not to require a models.py at
all.

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 app, then
why must I still have a models.py?  That said, it also seems there
could be some backwards incompatibilities if code or external tools
rely on a valid app including a models.py file.

For the record, about 20% of the models.py files in the django
codebase are empty (or just contain a comment):
$ find . -size -60c -name 'models.py' | wc -l
44
$ find . -name 'models.py' | wc -l
211

The issue of a missing models.py file also seems to be a frequent
visitor to our ticketing system:
https://code.djangoproject.com/ticket/3125
https://code.djangoproject.com/ticket/3310
https://code.djangoproject.com/ticket/4153
https://code.djangoproject.com/ticket/6883
https://code.djangoproject.com/ticket/7198
https://code.djangoproject.com/ticket/10661
https://code.djangoproject.com/ticket/13985
https://code.djangoproject.com/ticket/15605

...and there's been a few occasions where we've had our own issues
with missing models.py files:
https://code.djangoproject.com/changeset/6991
https://code.djangoproject.com/changeset/7950
https://code.djangoproject.com/changeset/12156
https://code.djangoproject.com/changeset/12170
https://code.djangoproject.com/changeset/13670

Gary

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