Re: Revisiting multiline tags

[Curtis Maloney]

For those interested, I've now got my branch working, and only failing
tests related to ensuring no newlines appear inside tags.

You can see the diff here :
https://github.com/funkybob/django/compare/multiline-templates

Now comes the great discovery phase to see how many real-world templates
I've broken, and how much I've altered template parsing performance :)

--
Curtis



On 9 March 2014 20:47, Curtis Maloney  wrote:

> To try to help the wider community know to contribute comments, I've
> included this thread in the latest Django Update.
>
> My personal stance is -- I know I can add this to the template code
> trivially (See my django-contemplation sandpit).  However, I'm not certain:
>
> a) What performance impact it may have
> b) What potential corner cases in parsing it may expose.
>
> So, unlike all the people just asking for it, I'm going to try it.  :)
>
> A lot of people may not be aware there are _two_ template Lexer/Parser
> pairs in the codebase -- a debug one, and a normal one.  So it's a matter
> of implementing the change in _two_ places.
>
> --
> Curtis
>
>
> On 7 March 2014 07:28, Andre Terra  wrote:
>
>> +1, for one simple reason: practicality beats purity.
>>
>>
>> On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis  wrote:
>>
>>> +1 - I've had the same issue with sorl thumbnail.
>>>
>>>
>>> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini wrote:
>>>
 +1 for multiline template tags

 Regarding: "we want to discourage putting business logic in the
 template"

 Long template tags can happen even if they are logic-less, and they
 would read much nicer over several lines. For example:

 {% cloudinary main_image.image width=300 height=300
 class="img-thumbnail main-product-image" crop="fill" gravity="face"
 effect="sepia" %}

 There's no business logic here: every parameter in this tag is
 presentational log and belongs in templates (<- unless I'm wrong about
 that, please suggest a refactoring to me if you believe one is appropriate
 here!)



 On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:

>
> On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis wrote:
>
>> My grandfather was a developer in a nuclear plant that I was
>> interning at.  They used a Django-based web interface for internal
>> operations.
>>
>> One of the functions their Django application managed was the release
>> of nuclear material.  While building the application, my grandfather put
>> the following line in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and
>> reactor.definitely_wont_kill %}
>>   {{ release_form }}
>> {% else %}
>>   {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> Now I was responsible for getting this code working, since for some
>> reason it never detected that it was safe to release the deadly fissile
>> material (hippies).  So I put the following statement in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and
>> reactor.definitely_wont_kill or 1 %}
>>   {{ release_form }}
>> {% else %}
>>   {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> It seemed to work just fine, and I showed my grandfather.  Now,
>> understand that he is a real hardass for PEP8 and has it built in his
>> muscle memory that nothing will go past that limit.  Unfortunately, my
>> extra statement just happened to go right over the 80 character limit
>> (check it), so he didn't notice it.
>>
>> Fast forward 2 months.  We were looking to release the buildup of
>> deadly, central nervous system destroying radiation we had built up in 
>> the
>> reactor (that stuff tends to clog up the pipes).  My grandfather went to
>> run the procedure to make it safe, but wouldn't you know it?  That debug
>> statement was still there.  Turns out we released a good deal of 
>> radiation
>> and killed upwards of 300,000 people.  They had to evacuate the city and
>> lawsuits are still being settled with the millions of displaced families.
>>
>> Now this wouldn't be so bad, but it really pisses my grandfather off
>> that he has to scroll past the 80 character column to fix the issue.
>>
>
> As amusing as your story is, hyperbole won't win the argument.
>
> Hyperbole aside, you haven't added anything to the discussion that we
> didn't already know. Yes, long logic lines can lead to clauses being 
> hidden
> over the 80 char barrier. This isn't news.
>
> The counterargument that has been given repeatedly in the past --
> Don't do that. One of the reasons that Django's template logic is
> intentionally hobbled is that we want to discourage putting business logic
> in the template. Not adding multiline tags is one of the contributors to
> this hobbling. Your templates *shouldn't* contain 

[GSoC] Security Enhancements; Reducing coupling in Django components

[Paolo Coffetti]

Dear Russell, PaulM and Django-devs,

I'm Paolo Coffetti, a software engineer living in Amsterdam, the 
Netherlands.
I'm very close to a master degree at University of Bergamo, Italy: I've 
finished all the courses and currently working on my thesis which I'll be 
defending on June 9.
The thesis is about a project which I temporarily named Moogle (My Own 
Google). Moogle is a website with a full text search engine for private 
data: it connects to a user's accounts in Facebook, Twitter, Google (Drive, 
Gmail, Google Plus) and Dropbox, indexes all her data (only textual 
information) and provides a private full text search (available only to 
her). The project is not complete yet, but I'm working hard.

I've been working in Amsterdam in a small startup company named United 
Academics since 2010 as web developer. Officially I'm not working for them 
anymore because I'm 100% focused on my thesis, but from time to time I 
still help their IT team.
United Academics is a company which aims today to provide an Open Access 
repository to scientists, but unfortunately is lately facing some financial 
difficulties. In the last years United Academics was something slightly 
different and I worked on projects like a printing on demand website 
(www.print2book.com), a job portal (now offline), a bookstore (now 
offline), a couple of Wordpress websites 
(http://www.united-academics.org/magazine/) and more recently an Open 
Access repository (not online yet). All those projects (apart from the 
Wordpress ones) were made in Python and Django so I consider myself an 
expert with those technologies. I'm definitely not a senior cause I still 
have a lot to learn, but I'm also definitely more than a junior.

I spent some hours during the last days on Django's proposals for Google 
Summer of Code.
I'm particularly interested in: Security Enhancements and Reducing coupling 
in Django components.
I've got a good impression reading those ideas and I would like to ask you 
more details.
This is not my official proposal, I haven't deeply studied the codebase 
yet, nor made a detailed plan, but only a first approach in order to get a 
clearer idea on what the aims are and see if I am on the right track.
Also, I've never contributed to Django's code and, even tho I know Python 
quite well, all those ideas sound quite tough to me and I'm wondering if 
I'm good enough.



*Reducing coupling in Django components*

This is the idea I'd appreciate the most as Django user. Having the 
possibility to use only the template engine or the ORM or the form layer 
could be useful for many projects (I will give an example later).
Anyway it is not clear to me if this idea is more about 
refactoring/reorganizing dependencies among modules in order to decouple 
parts of the system or if it is more about packaging.

*Packaging part*
Honestly I don't know much about packaging best-practices; I did some 
research today but it's not even clear to me whether Django uses Setuptools 
or Distutils.
Anyway looking at the tickets for the packaging component I found something.

https://code.djangoproject.com/ticket/18937
It's about adding metadata to Python distributions as described in PEP345, 
but actually as jezdez says "it's easy enough to put the info in a 
setup.cfg as it's implemented by distutils2/packaging... On the other hand 
as long as distutils2/packaging isn't official released/included in Python 
3.X it may be senseless to do so."

https://code.djangoproject.com/ticket/21108
Make pre-release installable via pip

*Refactoring dependencies part*
I guess this part requires a good overview on the entire system, which I 
don't have. But I have a great understanding of object oriented principles 
in Python and this could be useful.

So in the end, in order to complete this task I would need a great guidance 
cause it's even hard to me to define what exactly are the activities to be 
done, estimate and prioritize them. I could for instance start with a 
single component like the ORM and clean it up.
I investigated a little bit and django/db currently has the following 
dependencies: dispatch, apps, core, forms, utils.
I actually feel very challenged by this activity, it looks like I can 
really learn a lot by looking into the core of Django and I don't mind to 
work hard!

Plus I have an idea, not sure whether it is pertinent tho.
I'm working on a project which has, among the others, 2 parts:
- a Django website which has a database with OAuth tokens (and many other 
things)
- some Python code which uses the same OAuth tokens to do some batch 
operations 
The 2 parts are independent sub-systems and they are deployed to different 
machines; but both parts must be able to read/update the same set of OAuth 
tokens.
One solution would be using the ORM provided by Django and the same models 
in the Python batch code in order to read/update the same database (or its 
replica). I know it is possible to use the ORM outside of a web context (as 
James wrote a lon

Re: Case handling for application verbose names

[Russell Keith-Magee]

On Mon, Mar 10, 2014 at 4:23 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> https://code.djangoproject.com/ticket/22070 reported an inconsistency in
> the capitalization of application verbose names. It was most visible in the
> admin index page. In order to fix this bug, application names were
> capitalized. The alternative was to pass application names through capfirst
> like model names.
>
> AppConfig.verbose_name is intended to mirror
> Model._meta.verbose_name/verbose_name_plural. The latter are expected to be
> lower-case:
> https://docs.djangoproject.com/en/dev/ref/models/options/#verbose-name.
> That makes it easier to use them in sentences such as "Delete selected
> %(verbose_name_plural)s".
>
> Can the same argument be applied to application names? In theory, maybe,
> and that's why I was surprised by the fix for #22070. In practice there's
> usually a single instance of each application in a Django project. From
> that perspective application names can be treated like proper nouns and
> should be capitalized.
>
> This question matters because it isn't possible to capitalize or
> lower-case correctly in general. I'd like to avoid changing the API after
> the beta.
>
> I'm now thinking that it's acceptable to keep capitalized application
> names and live with the inconsistency. However, if I have missed an
> argument in favor of lower case names, let me know.
>

I agree it's an inconsistency, but I think it's an inconsistency that makes
sense in light of the "proper noun" observation that you've made. I can't
think of any example where you'd refer to an application in the plural - to
my mind, it's a standalone product that is by its very nature limited to
cardinality 1 in any Django context. Autocapitalization is essentially
impossible to get right, and the most common usage of the app name is as a
label in the admin; on the flip side, I can't see any reason why the
lowercase admin name is desirable.

Yours,
Russ Magee %-)

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

Re: [GSOC 2014] Reducing coupling in Django components

[Russell Keith-Magee]

Hi Javed,

On Mon, Mar 10, 2014 at 12:08 AM, Javed Khan  wrote:

> Hi All,
>
> I'm Javed and I'm currently pursuing a part-time masters in Software
> Systems. I have been involved with django for the better part of the last
> few years and I love the community and ecosystem! In my spare time I try to
> pay back by contributing to django and supporting projects. I love the idea
> of decoupling django and being able to install and use only the forms or
> the ORM.
>
> To try and understand the problem better I've written about the current
> dependencies within django:
>
> http://tuxcanfly.me/visualizing-django-component-dependencies.html
>
> I think django.conf is the most coupled module since it's virtually
> required everywhere to access settings. Similarly a lot of modules are
> coupled to django.apps to access the apps. This is probably because of
> django's assumption about the context of execution i.e. within a project
> created by startproject. Other dependencies are more complex will require
> more analysis. I'll try to find out more and come up with a draft for the
> proposal soon. If anyone has suggestions or if I'm not on the right track,
> please let me know.
>

It looks like you've got a good start here. You're correct that django.conf
and django.apps are deep dependencies of various parts of Django, and it's
going to be hard to break this dependency.

That said, I'd be careful making blanket statements about dependencies
based on dependency graphs. The 'caught my eye' dependencies you found can
all be easily explained. django.templates is dependent on django.http for
one reason - as a base class for TemplateResponse. django.forms is
dependent on django.db because you need to have model introspection in
order to do a model form. Dependency graphs will reveal the existence of a
dependency, but won't demonstrate the reason for the dependency. It's
important you keep the underlying reasons in mind, because we're not
looking to break dependencies at all costs.

As far as your proposal goes, my suggestion would be to have a concrete
goal in mind. It's possible that your project might not reach all those
goals, but having an idea of what the ideal end-state would look like would
be very helpful in assessing the merits of your proposal.

Yours,
Russ Magee %-)

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

Case handling for application verbose names

[Aymeric Augustin]

Hello,

https://code.djangoproject.com/ticket/22070 reported an inconsistency in the 
capitalization of application verbose names. It was most visible in the admin 
index page. In order to fix this bug, application names were capitalized. The 
alternative was to pass application names through capfirst like model names.

AppConfig.verbose_name is intended to mirror 
Model._meta.verbose_name/verbose_name_plural. The latter are expected to be 
lower-case: 
https://docs.djangoproject.com/en/dev/ref/models/options/#verbose-name. That 
makes it easier to use them in sentences such as "Delete selected 
%(verbose_name_plural)s".

Can the same argument be applied to application names? In theory, maybe, and 
that's why I was surprised by the fix for #22070. In practice there's usually a 
single instance of each application in a Django project. From that perspective 
application names can be treated like proper nouns and should be capitalized.

This question matters because it isn't possible to capitalize or lower-case 
correctly in general. I'd like to avoid changing the API after the beta.

I'm now thinking that it's acceptable to keep capitalized application names and 
live with the inconsistency. However, if I have missed an argument in favor of 
lower case names, let me know.

-- 
Aymeric.



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

Re: DRY date_format and datetime objects

[Marc Tamlyn]

Whilst I disagree with the proposed implementation of the ticket, the fact
that `DATE_FORMAT` uses a version of formatting (like the date filter[1])
which are actually impossible to duplicate precisely using strftime, it is
an irritation when in some cases user facing strings are built in python
rather than in the template language.

So I'm against the proposed solution, but I'd like to see some way to more
easily format a date to a string in the same way it would be by just
writing {{ date }} in a template. If such a utility function exists, it
should be better documented.

M


On 9 March 2014 18:52, Aymeric Augustin
wrote:

> On 9 mars 2014, at 18:36, Jon Dufresne  wrote:
>
> > I understand what you're saying, but how is this any different than
> > rendering a date as a string at template time? The Locale needs to be
> > considered in both cases.
>
> unicode(...) may end up stored in various places such as logs, where the
> locale of the original request may not be known. On the contrary, templates
> are immediately displayed to an end user.
>
> > Both these concerns could be solved with a setting to turn this
> > feature on and be off by default.
>
> If you've spent some time on this mailing list, you know that  "just
> add a setting" isn't a compelling argument, to say the least...
>
> On 9 mars 2014, at 19:01, Jon Dufresne  wrote:
>
> > As best I can tell, [DATE_FORMAT] is only the default
> > formatting to use for displaying dates in
> > templates. When dates are displayed through other means (such as
> > string formatting), this format sepcification is ignored. This is what
> > I find confusing and what I hope I could fix.
>
> I agree, the documentation should clarify that DATE_FORMAT mostly
> applies to templates and forms.
>
> --
> Aymeric.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CF3A11BD-EF70-49C8-AA57-90F54C02C796%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: DRY date_format and datetime objects

[Aymeric Augustin]

On 9 mars 2014, at 18:36, Jon Dufresne  wrote:

> I understand what you're saying, but how is this any different than
> rendering a date as a string at template time? The Locale needs to be
> considered in both cases.

unicode(...) may end up stored in various places such as logs, where the
locale of the original request may not be known. On the contrary, templates
are immediately displayed to an end user.

> Both these concerns could be solved with a setting to turn this
> feature on and be off by default.

If you've spent some time on this mailing list, you know that  "just
add a setting" isn't a compelling argument, to say the least...

On 9 mars 2014, at 19:01, Jon Dufresne  wrote:

> As best I can tell, [DATE_FORMAT] is only the default
> formatting to use for displaying dates in
> templates. When dates are displayed through other means (such as
> string formatting), this format sepcification is ignored. This is what
> I find confusing and what I hope I could fix.

I agree, the documentation should clarify that DATE_FORMAT mostly
applies to templates and forms.

-- 
Aymeric.

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

Re: DRY date_format and datetime objects

[Jon Dufresne]

On Sun, Mar 9, 2014 at 10:36 AM, Jon Dufresne  wrote:
> On Sun, Mar 9, 2014 at 10:05 AM, Aymeric Augustin
>  wrote:
>> Furthermore, there are two reasons why I'm against making this change
>> in Django:
>> - it's a large backwards incompatibility;
>> - it deviates from Python's behavior in a surprising and unexpected way.
>
> Both these concerns could be solved with a setting to turn this
> feature on and be off by default.
>
> What I find surprising is setting a DATE_FORMAT in settings.py has
> little effect on how many dates are formatted.

I went back and re-read the documentation on this setting (emphasis mine):

---


**The default formatting to use for displaying date fields in any part
of the system.** Note that if USE_L10N is set to True, then the
locale-dictated format has higher precedence and will be applied
instead. See allowed date format strings.
---

>From my experience this does not seem to be the case. As best I can
tell, it is only the default formatting to use for displaying dates in
templates. When dates are displayed through other means (such as
string formatting), this format sepcification is ignored. This is what
I find confusing and what I hope I could fix.

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

Re: DRY date_format and datetime objects

[Jon Dufresne]

On Sun, Mar 9, 2014 at 10:05 AM, Aymeric Augustin
 wrote:
> ... assuming your application is only ever used in one locale. We cannot
> make this assumption for all Django applications.
>
> -MM-DD is unambiguous and consistent. You could argue that
> DD/MM/ is just as good, but Americans tend to interpret it
> backwards (they read 10/12/2014 as October 12th instead of December
> 10th).

I understand what you're saying, but how is this any different than
rendering a date as a string at template time? The Locale needs to be
considered in both cases.

>
> Furthermore, there are two reasons why I'm against making this change
> in Django:
> - it's a large backwards incompatibility;
> - it deviates from Python's behavior in a surprising and unexpected way.

Both these concerns could be solved with a setting to turn this
feature on and be off by default.

What I find surprising is setting a DATE_FORMAT in settings.py has
little effect on how many dates are formatted.

> If you want that feature, I would suggest to subclass DateTimeField in
> your projects.

I'll certainly consider this, thanks. But this will not work for any
third party apps. It will also mean my apps are not re-usable outside
my projects.

Cheers,
Jon

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

Re: DRY date_format and datetime objects

[Aymeric Augustin]

On 9 mars 2014, at 17:41, Jon Dufresne  wrote:

> I use "date_format" so the dates are always formatted correctly and
> consistently.

... assuming your application is only ever used in one locale. We cannot
make this assumption for all Django applications.

-MM-DD is unambiguous and consistent. You could argue that
DD/MM/ is just as good, but Americans tend to interpret it
backwards (they read 10/12/2014 as October 12th instead of December
10th).

Furthermore, there are two reasons why I'm against making this change
in Django:
- it's a large backwards incompatibility;
- it deviates from Python's behavior in a surprising and unexpected way.

If you want that feature, I would suggest to subclass DateTimeField in
your projects.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/66ABF044-6273-4E57-A73D-7FFEA3D9167B%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: DRY date_format and datetime objects

[Jon Dufresne]

On Sat, Mar 8, 2014 at 6:39 PM, Shai Berger  wrote:
> Can you present your use-case in more detail? Why do you have to format the
> dates explicitly in Python code, rather than use the template filter "date"?

Sometimes this happens in __unicode__ methods for models. A model may
contain two dates: start and finish. I want the __unicode__ method to
display this range. The method ends up looking like:

def __unicode__(self):
return u'%s (%s–%s)' % (
self.name,
date_format(self.start_date),
date_format(self.end_date))

I use "date_format" so the dates are always formatted correctly and
consistently. I'll sometimes create other utility functions in the
same spirit. With what I'm suggesting, I'd expect to write the
function as:

def __unicode__(self):
return u'%s (%s–%s)' % (
self.name,
self.start_date,
self.end_date)

If the dates always format themselves correctly without me thinking
about it, it seems like and opportunity to stop repeating myself.

Cheers,
Jon

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

[GSOC 2014] Reducing coupling in Django components

[Javed Khan]

Hi All,

I'm Javed and I'm currently pursuing a part-time masters in Software 
Systems. I have been involved with django for the better part of the last 
few years and I love the community and ecosystem! In my spare time I try to 
pay back by contributing to django and supporting projects. I love the idea 
of decoupling django and being able to install and use only the forms or 
the ORM. 

To try and understand the problem better I've written about the current 
dependencies within django:

http://tuxcanfly.me/visualizing-django-component-dependencies.html

I think django.conf is the most coupled module since it's virtually 
required everywhere to access settings. Similarly a lot of modules are 
coupled to django.apps to access the apps. This is probably because of 
django's assumption about the context of execution i.e. within a project 
created by startproject. Other dependencies are more complex will require 
more analysis. I'll try to find out more and come up with a draft for the 
proposal soon. If anyone has suggestions or if I'm not on the right track, 
please let me know. 

Thanks,
Javed

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

Re: Revisiting multiline tags

[Curtis Maloney]

To try to help the wider community know to contribute comments, I've
included this thread in the latest Django Update.

My personal stance is -- I know I can add this to the template code
trivially (See my django-contemplation sandpit).  However, I'm not certain:

a) What performance impact it may have
b) What potential corner cases in parsing it may expose.

So, unlike all the people just asking for it, I'm going to try it.  :)

A lot of people may not be aware there are _two_ template Lexer/Parser
pairs in the codebase -- a debug one, and a normal one.  So it's a matter
of implementing the change in _two_ places.

--
Curtis


On 7 March 2014 07:28, Andre Terra  wrote:

> +1, for one simple reason: practicality beats purity.
>
>
> On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis  wrote:
>
>> +1 - I've had the same issue with sorl thumbnail.
>>
>>
>> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini wrote:
>>
>>> +1 for multiline template tags
>>>
>>> Regarding: "we want to discourage putting business logic in the template"
>>>
>>> Long template tags can happen even if they are logic-less, and they
>>> would read much nicer over several lines. For example:
>>>
>>> {% cloudinary main_image.image width=300 height=300 class="img-thumbnail
>>> main-product-image" crop="fill" gravity="face" effect="sepia" %}
>>>
>>> There's no business logic here: every parameter in this tag is
>>> presentational log and belongs in templates (<- unless I'm wrong about
>>> that, please suggest a refactoring to me if you believe one is appropriate
>>> here!)
>>>
>>>
>>>
>>> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>>>

 On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis wrote:

> My grandfather was a developer in a nuclear plant that I was interning
> at.  They used a Django-based web interface for internal operations.
>
> One of the functions their Django application managed was the release
> of nuclear material.  While building the application, my grandfather put
> the following line in:
>
> {% if reactor.safe_to_release_deadly_radiation and
> reactor.definitely_wont_kill %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> Now I was responsible for getting this code working, since for some
> reason it never detected that it was safe to release the deadly fissile
> material (hippies).  So I put the following statement in:
>
> {% if reactor.safe_to_release_deadly_radiation and
> reactor.definitely_wont_kill or 1 %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> It seemed to work just fine, and I showed my grandfather.  Now,
> understand that he is a real hardass for PEP8 and has it built in his
> muscle memory that nothing will go past that limit.  Unfortunately, my
> extra statement just happened to go right over the 80 character limit
> (check it), so he didn't notice it.
>
> Fast forward 2 months.  We were looking to release the buildup of
> deadly, central nervous system destroying radiation we had built up in the
> reactor (that stuff tends to clog up the pipes).  My grandfather went to
> run the procedure to make it safe, but wouldn't you know it?  That debug
> statement was still there.  Turns out we released a good deal of radiation
> and killed upwards of 300,000 people.  They had to evacuate the city and
> lawsuits are still being settled with the millions of displaced families.
>
> Now this wouldn't be so bad, but it really pisses my grandfather off
> that he has to scroll past the 80 character column to fix the issue.
>

 As amusing as your story is, hyperbole won't win the argument.

 Hyperbole aside, you haven't added anything to the discussion that we
 didn't already know. Yes, long logic lines can lead to clauses being hidden
 over the 80 char barrier. This isn't news.

 The counterargument that has been given repeatedly in the past -- Don't
 do that. One of the reasons that Django's template logic is intentionally
 hobbled is that we want to discourage putting business logic in the
 template. Not adding multiline tags is one of the contributors to this
 hobbling. Your templates *shouldn't* contain long lines - because if they
 do, You're Doing It Wrong(tm).

 How should it be done? Depending on circumstances, you could refactor
 the "is it ok to show the form" logic into:

  * a method on the reactor object:

 {% if reactor.ok_to_show_form %}

  * the view that constructs the context that the template uses:

 {% if ok_to_show_reactor_form %}

  * a template filter

 {% if reactor|ok_to_show_form %}

  * a template tag setting a local value in the context

 {% show_form_state as ok_to_show_form %}