Re: ANN: Django website redesign launched

[Jorge C . Leitão]

Dear Django community,

I would like to congratulate you very much for this. I'm very pleased to 
see that the work in Django is much better presented to the world, which I 
think we all agree is an important component of the project.

Generally speaking, I like very much the overall look and feel of the 
website. I imagine it is very hard to agree on them, specially since it is 
a component that has some intrinsic subjectivity.

I have a question regarding the layout:

In the previous website there was a noticeable difference between the 
website UI and the UI of the issue tracker. Are we aiming to keep that 
difference or do we aim to make them indistinguishable?

This is because it seems that some elements of the tracker were changed to 
blend with the new look, but others don't. Specifically:

- In the main content of the issue tracker the horizontal lines have a 
shadow in the bottom; The other sections don't.
- In the issue tracker, some content is boxed (e.g. wiki), while other 
doesn't (new ticket), and the boxes are corner-rounded (while the website 
has rounded elements besides buttons).
- In the wiki of the issue tracker, the font seems to be "blurred"(?), 
compare with sidebar.

I would prefer the same look of the issue tracker for consistency, but 
since that section of the website is aimed to developers of Django, there 
can be a rational to make it different. Could we clarify this so we know 
what is a bug to report and what is an intended feature?

In any case, the quality of Django website conveys now much better the 
quality of the Django project. Thank you for that.

Cheers,
Jorge


On Tuesday, December 16, 2014 5:09:55 PM UTC+1, Jannis Leidel wrote:
>
> Hi everyone, 
>
> We're incredibly proud to share with you the new design of the Django 
> website, the documentation and the issue tracker. 
>
> This is a long time coming and we couldn't be happier to finally ship it 
> :) 
>
> As you can imagine, there will be bugs, so please bear with us and report 
> issues to the issue tracker at 
> https://github.com/django/djangoproject.com/issues 
>
> More infos about the redesign and its history can be found in the blog 
> post: 
>
>   
> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/
>  
>
> Happy coding, everyone! 
>
> Jannis 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c3d543e5-ac54-4df1-bd38-1d020d760fa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Internationalise GET parameters?

[Jorge C . Leitão]

Hi,

Thanks both for the feedback; I was not seeing the whole issue with JS, and I 
now share your concerns. 

To me, the ticket can be closed as won't fix 
(https://code.djangoproject.com/ticket/23927).
Thanks Tim for raising the issues that brought us here.

Cheers,
Jorge

On Sunday, November 30, 2014 9:07:55 AM UTC+1, Marc Tamlyn wrote:
>
> I'm afraid I have to agree the gain does not merit the effort.
>
> To the average user, I think the query string already looks like it's 
> weird code stuff (with &=?) so I don't think it being in a different 
> language would improve things that much.
>
> Marc
> On 28 Nov 2014 13:36, "Florian Apolloner" <f.apo...@gmail.com 
> > wrote:
>
>>
>>
>> On Friday, November 28, 2014 11:17:15 AM UTC+1, Jorge C. Leitão wrote:
>>>
>>> IMO, this lies on the assumption that the Form's field names are never 
>>> shown to the user. When the form is POST, this assumption is valid. 
>>> However, in a GET, the field names are presented in the URL, and the 
>>> assumption breaks. This even exposes serve-side implementation details (the 
>>> field name of the Form) to the user.
>>>
>>
>> You always expose some server information, even with POST -- you just 
>> don't see the parameters in the URL
>>  
>>
>>> 1. how common is this?
>>>
>>
>> No idea on that, but field names are programmatic identifiers (as you 
>> said, they are an implementation detail), translating those will break 
>> loads of things.
>>  
>>
>>> 2. wouldn't it add a lot of complexity to JavaScript and CSS, 
>>> specifically on name selectors?
>>>
>>
>> They wouldn't work anymore unless you send a mapping to the client, again 
>> exposing server implementation details.
>>  
>>
>>> 3. do any other web framework support this?
>>>
>>
>> Not that I am aware.
>>
>> Could we have some feedback to decide wether it justifies or not to have 
>>> this in Django?
>>>
>>
>> Personally, I am against it, I don't think that the gains justify the 
>> effort. 
>>
>> Cheers,
>> Florian
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/c3258005-6bac-483f-b425-2681b8898b34%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/c3258005-6bac-483f-b425-2681b8898b34%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/60948d71-f882-485e-b578-64a90b5d2ea0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Internationalise GET parameters?

[Jorge C . Leitão]

Hi,

I'm came across to the situation where, for URL cleanness,

See Cool URIs don’t change , by World 
> Wide Web creator Tim Berners-Lee, for excellent arguments on why URLs 
> should be clean and usable.


I wanted to internationalise its parameters. E.g. this 

www.example.com/persons?search=...

be shown as 

www.example.com/personas?busca=...

I search on the documentation, and this does not seemed to be documented. 
I.e. the API allows to change how the field name is presented as HTML, but 
it does not allow internationalising it on the URL.

IMO, this lies on the assumption that the Form's field names are never 
shown to the user. When the form is POST, this assumption is valid. 
However, in a GET, the field names are presented in the URL, and the 
assumption breaks. This even exposes serve-side implementation details (the 
field name of the Form) to the user.

I thus filled a ticket [1] proposing to decouple the two things: the 
field_name on the server side and how it is represented on the client side. 
There is also a Stackoverflow question [2] on this with a different 
implementation than I'm presenting in [1].

Tim suggested to bring this here because of the following issues he pointed 
out:

1. how common is this?
2. wouldn't it add a lot of complexity to JavaScript and CSS, specifically 
on name selectors?
3. do any other web framework support this?

The answers I can give so far:

1., I tried to do it because I didn't wanted english on a portuguese 
website's URL neither portuguese on my code. It seemed a reasonable request 
for a web framework, but yes, it may not be so common.
2., I may be; I don't know enough to answer it.
3., I'm not familiar with other frameworks; I've searched Ruby on Rails 
documentation and I didn't found it.

Could we have some feedback to decide wether it justifies or not to have 
this in Django?

Thank you for your time,
Jorge

[1] https://code.djangoproject.com/ticket/23927
[2] 
http://stackoverflow.com/questions/24051937/how-to-translate-get-keys-in-django-forms


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f2ad423-947d-4e51-a813-89d2bc672a59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Great Wall of DEP

[Jorge C . Leitão]

In my opinion, it may be too soon to make an evaluation of DEP.

Most importantly, it has to be put in context to what happened/is
happening:
- there was a security release
- there was a fix to the security release
- there is a version of Django to be released with *considerable* new
features, that naturally have release blockers to be fixed.

I believe this waiting time has nothing to do with being a DEP, a PEP, or a
simple feature request; it is just that DEP was formally announced before 
the start
of the new cycle - 1.8 - to be used on it, and the current priority is to
close the current cycle, which is demanding a considerable commitment,
specially from the core devs, as some already expressed here.

It may be worth performing an evaluation of the DEP procedure;
however, my suggestion is to postpone it to after the
release of 1.8, since at that time we have a full release cycle where DEP
was used and tested. In my opinion, this will allow a more pragmatic 
evaluation
that matches more closely the expectations and ideas behind the DEP.

Regards,
Jorge


On Friday, May 9, 2014 6:46:51 PM UTC+2, Trey Hunner wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA1 
>
> On 04/29/2014 08:58 PM, Michael Manfre wrote: 
> > From DEP 001: 
> > 
> > "Once you've written a DEP and submitted the pull request, post a 
> > message about it to the django-developers mailing list. At that point, 
> > Django developers will make sure it's technically feasible, not spam, 
> > etc., assign it a DEP number and commit it to the repository as 
> > "Active." This doesn't mean the feature will be implemented; it merely 
> > means the proposal is officially a DEP." 
> > 
> > There are two DEP pull requests that seem to have sat for two weeks 
> > waiting to be merged in as "Active" with numbers assigned. They are both 
> > clearly not spam and are technically feasible. I'm curious why they have 
> > not been moved along in the process. 
>
> I'm not convinced that the open pull requests are a problem.  I don't 
> see any comments on any of the pull requests stating that a DEP seems 
> ready to be merged. 
>
> Maybe the problem here is an unclear/absent process for merging?  I 
> would think merging should purposely be delayed because once the DEP is 
> merged it is no longer active unless a new pull request is made to 
> modify it. 
>
> The current process assigns a number only after the pull request has 
> been merged.  I'm not sure those two steps should be related. 
> Assignment of a DEP number could happen *before* the pull request is 
> merged. 
>
> How does the PEP process handle this?  Are threads ever declared "done" 
> and if so is that finalization separate from the assignment of a PEP 
> number? 
>
> - -- 
> Trey Hunner 
> http://treyhunner.com 
> -BEGIN PGP SIGNATURE- 
> Version: GnuPG v1 
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ 
>
> iQEcBAEBAgAGBQJTbQZ7AAoJEOpnfp/NreonXkwH/jRsO7gcc6HX5b1kdZmGpoOO 
> 92sX9gtjYiX8NwkEwjQaTAOGGCLhxZXnvwN1IMdjMR4ogE7rs9vg0Uc4hML0UYYL 
> 1zijA8sxJF4ZeuIgAk/hFIRfOHVfAkJUaSdkAtVijH3VPX8wvd/NqAr5zlGn/e9b 
> 0DsvA5OczZea6VvqllZfqQVJ6KJA7lfDWjf6PRKGnWl+Daxi9ygkhUV7E0pyt/qZ 
> wqV6jSBqvNkoT/QPdpXnXvKd8ZkG8KtOw+VYuJJb3cf2guUXdwy9tHX6Lmlm2IMR 
> AhCnRHJPAqqVRDhswocFJCJ1tIUjObnb2rVsxgwh11PrcNhLz7z/MS7rN3M+lcQ= 
> =TmrW 
> -END PGP SIGNATURE- 
>

-- 
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/ed51f725-6d43-4da5-96e7-7e90721694e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

urls in {% blocktrans %} fails silently.

[Jorge C . Leitão]

Hi all!

Currently, for adding an url to a blocktrans, we need:

{% url "home" as home %}
{% blocktrans with the_url=home %}
...
{% endblocktrans %}

(https://docs.djangoproject.com/en/dev/topics/i18n/translation/#blocktrans-template-tag)

However, this is not equivalent to use {% url "home" %} without the 
blocktrans because {% url "home" as home %} fails silently if url "home" 
doesn't exist. I believe this was added as part of fixing 
#7239
.

It seems there is no way to add urls to {% blocktrans %} without forcing 
them to fail silently. IMO this is a problem since most cases the user 
wants an error when the link does not exist, as per {% url "home" %}.

I believe the only current solution is to reverse the url in the view and 
pass it as a context variable, something that is against the whole idea of 
{% url %}, and is not compatible with urls in a {% blocktrans %} inside a 
{% for %} loop.


I wonder if it is worth considering the keyword "url" to blocktrans, which 
would be used to reverse the argument of the variable after it, as

{% blocktrans url the_url="home" %}
home
{% blocktrans %}

The problem seems to be the arguments, which we could solve with a keyword 
"arg"

{% blocktrans url the_url="home" arg arg1=A %}

as in {% url %}. However, I'm not fully aware of the potential problems 
this brings, why I'm asking for help. Some points I consider debatable:

1. we need 2 new keywords for fixing this, "url" and "arg".
2. on one hand, "arg" could be used more generically in the future, but on 
the other hand it has also the potential to add logic to the template 
system.

Are there stronger reasons for not considering this?

Thanks,
Jorge


-- 
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/83d6f72c-5dfa-4591-bbb4-34fc53fdfdaa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django-picklefield apparently not being maintained.

[Jorge C . Leitão]

Hi there.

First of all, I've just read these 
rules
 and 
I want to apologize for my behavior on this mailing list. I'm sorry for my 
behavior, specially in 
this
 thread, 
but also on 
this
 and 
this.
 
I now understood my very rude behavior, but I nevertheless would like to 
contribute, as from what I read in this list, this is a very serious 
community. 

Now, Django: I'm using 
Django-picklefield, 
but apparently it stop being maintained on github (the user was a company 
that no longer has a website). The issue is that the code, as it is, is not 
working. There are issues raised and not fixed more than a year now.

I fixed the issue on my local, like some of the 25 forks of the project on 
github.

I think this is a small project that would be nice for me to maintain, but 
I don't know the "etiquette rules" of how it works.

First, do you think it is worth? Is there any alternative that I'm not 
aware of (or as a new feat of Django core)? do you know of anyone that is 
maintaining it?

Secondly, what are the rules for doing this? I mean, can I just change its 
name and open a github rep, along with a pip version and give the 
respective credits to the creators?

Can anyone give me a small guideline on how to proceed on this regard?

Thanks for your time and patience,
Jorge

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Odd behavior on proxy models should be on documentation

[Jorge C . Leitão]

Hi there.

I was working with proxies models and I found an odd behavior on a 
QuerySet, and I ask here whether it should be documented.

Consider the following code:

from django.db import models

#from model_utils.managers import InheritanceManager

class Generic(models.Model):
pass # comment this pass on second test
#objects = InheritanceManager()

class Specific(Generic):
class Meta:
proxy = True

class SpecificA(Generic):
pass

Specific.objects.create()
SpecificA.objects.create()

print Generic.objects.all()
print Specific.objects.all()
print SpecificA.objects.all()
#print Generic.objects.all().select_subclasses()

Specific.objects.all().delete()
SpecificA.objects.all().delete()

The output is:

[, ]
[, ]
[]

Why there are two  in the second list? I would 
expect 1 instance (the database has 2 rows in Generic and one 1 row in 
SpecificA).

Furthermore, I also realized that the InheritanceManager (from 
django-model-utils
) is doing something odd on proxy models, which could be due to the 
previous behavior. Uncommenting the three commented lines of the previous 
code and commenting pass, the fourth print gives

[, ]

I would expect  instead of .

I tested this behavior in Django 1.5.2 and 1.6 and the results are 
equivalent.

Can someone double check this and confirm that this behavior is odd?

I searched in the documentation but I didn't found any reference that a 
Query on the proxy model returns instances subclasses of the parent model, 
instantiated as the proxy model itself. If this is the expected behavior, 
shouldn't we document it? Nevertheless, it seems to me difficult to assume 
that print Specific.objects.all()returns an instance created by 
SpecificA.objects.create().

If this is not expected behavior, should I open a ticket with it?


Cheers,
Jorge

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal of new feature: handler to HttpResponseNotAllowed (status 405)

[Jorge C . Leitão]

It is unfortunate that I didn't found this on documentation.

Thanks for the clarification Tom.

Cheers,
Jorge




On Tuesday, July 9, 2013 1:33:24 PM UTC+2, Tom Evans wrote:
>
> On Mon, Jul 8, 2013 at 10:01 AM, Jorge C. Leitão 
> <jorgeca...@gmail.com > wrote: 
> > Django allows users to define handlers to some exceptions, most notably 
> > http404, server error (status 500) and permission denied (status 403). 
> > 
>
> In fact, django already allows you to install handlers to process any 
> kind of unhandled exception, by installing middleware with a 
> process_exception() method that handles exceptions of that type. 
>
> > I here propose this feature to be extended to HttpResponseNotAllowed 
> (status 
> > 405). 
> > 
>
> This is a HttpResponse subclass, not an exception. handle404 does not 
> get involved if you return a HttpResponseNotFound response from your 
> view, only if you raise a http.Http404 exception. Basically: 
>
> Middleware can handle any unhandled exception before the other 
> exception handlers are involved. 
> handle403 handles uncaught django.core.exceptions.PermissionDenied 
> exceptions. 
> handle404 handles uncaught django.http.Http404 exceptions. 
> handle500 handles all other uncaught exceptions. 
>
> Cheers 
>
> Tom 
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal of new feature: handler to HttpResponseNotAllowed (status 405)

[Jorge C . Leitão]

Django 
allowsusers
 to define handlers to some exceptions, most notably http404, server 
error (status 500) and permission denied (status 403).

I here propose this feature to be extended to 
HttpResponseNotAllowed
 (status 
405).

There main reason is consistency: if django has a way to create such 
status, it should also allow the developer to handle them.

For instance, I was planning to write handlers for some status I raise in 
views (mainly for debugging during live), and I'm not being able to use the 
decorator 
require_http_methods
 because 
it emits a status that I cannot handle by myself. Thus, I cannot properly 
judge if it was triggered by a server semantic error or by a "curious" user.

Regards,
Jorge

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Patch submission on ticket 20122

[Jorge C . Leitão]

I've just submitted a patch (under username "littlepig", if possible I 
would change it to "jorgecarleitao") to ticket 
20122 but 
I don't know what I have to do on the ticket in order to draw attention of 
a developer (besides adding "has patch"). Am I suppose to use "ready for 
check in" option?

Cheers,
Jorge

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Why apps have to have unique names? [related with subapps and name collision]

[Jorge C . Leitão]

Hi. 

The motivation to this question is that if I want to implement "copies" of 
an app within an website (for instance, a stackoverflow-like where each app 
is a Q for its own, but with modifications on templates, urls, etc.), as 
far as I'm understanding: (1) each "copy" has to change its name, names of 
all calls of templates, views, etc due to name collision and (2) each copy 
must be an app on its own without any dependencies on other apps with 
models/templates/urls, because otherwise the dependent apps would also have 
to be "copied", names changed, etc.

In a previous post I suggested generalizing templates and url search to be 
used within subapps (apps with folder inside another app), which I found 
was a way of allowing what I wanted to do.
There was a criticism that during the discussion that I (mostly) ignored, 
but while re-reading it, I understood its meaning and its importance to a 
discussion by itself.

The criticism was from Shai Berger, that correctly pointed out that Django 
uses unique app names [1], and what I didn't understood at the time was 
that this forbids any possibility of using subapps the way I was suggesting 
or in any way that might help.

Motivated by that criticism, I want to ask: why apps have to have unique 
names?

To try to answer this question on the code, I did a simple search on Django 
code. This is far from rigorous, but gives some nice results. The search 
was simple: regex of r"settings.INSTALLED_APP" and regex of 
r".split('.')[-2]". Afterwards, I read the code to understand which 
dependencies it has on the labeling. Here are the results:

## Usage of settings.INSTALLED_APP (regex: settings.INSTALLED_APP)
# To check admin existence, uses full path (import_module)
/django/contrib/admin/__init__.py:24: for app in 
settings.INSTALLED_APPS:
# To check specific app existence, uses full path (import_module)
/django/contrib/admin/templatetags/admin_static.py:6: if 
'django.contrib.staticfiles' in settings.INSTALLED_APPS:
/django/contrib/comments/__init__.py:16: if comments_app not in 
settings.INSTALLED_APPS:
/django/contrib/gis/tests/__init__.py:113: settings.INSTALLED_APPS 
= list(self.old_installed) + new_installed
/django/contrib/gis/tests/__init__.py:125: settings.INSTALLED_APPS 
= self.old_installed
/django/contrib/messages/tests/base.py:16: 'django.contrib.auth' 
not in settings.INSTALLED_APPS,
/django/contrib/messages/tests/base.py:214: lambda 
app:app!='django.contrib.messages', settings.INSTALLED_APPS),
/django/contrib/messages/tests/base.py:239: lambda 
app:app!='django.contrib.messages', settings.INSTALLED_APPS),
/django/contrib/sitemaps/tests/flatpages.py:8: 
@skipUnless("django.contrib.flatpages" in settings.INSTALLED_APPS,
/django/contrib/sitemaps/tests/http.py:88: 
@skipUnless("django.contrib.sites" in settings.INSTALLED_APPS,
# for finding static; use full path of the app
/django/contrib/staticfiles/finders.py:122: apps = 
settings.INSTALLED_APPS
# for binding commands to the management. Requires unique app to avoid 
commands collision.
/django/core/management/__init__.py:101: apps = 
settings.INSTALLED_APPS
# for binding commands to the management. Requires unique app to avoid 
commands collision.
/django/core/management/__init__.py:319: options += 
[(a.split('.')[-1], 0) for a in settings.INSTALLED_APPS]
# for importing the 'management' module within each installed app, to 
register dispatcher events.
/django/core/management/commands/flush.py:35: for app_name in 
settings.INSTALLED_APPS:
# for importing the 'management' module within each installed app, to 
register dispatcher events (lacks DRY principle: command used is the same 
as previous file.)
/django/core/management/commands/syncdb.py:38: for app_name in 
settings.INSTALLED_APPS:
# for the 'models' of the db. It uses django.utils.importlib.import_module 
on the full app's path. Class uses _label_for for defining a "name" for the 
app, which requires unique app
/django/db/models/loading.py:61: for app_name in 
settings.INSTALLED_APPS:
/django/db/models/loading.py:143: for app_name in 
settings.INSTALLED_APPS:
# To check whether the model is installed. It uses full paths of the package
/django/db/models/options.py:71: self.installed = 
re.sub('\.models$', '', cls.__module__) in settings.INSTALLED_APPS
# To find templatetags. It stores the full path of the module
/django/template/base.py:1271: for app_module in ['django'] + 
list(settings.INSTALLED_APPS):
# To find templates. It stores the full path of the module
/django/template/loaders/app_directories.py:19: for app in 
settings.INSTALLED_APPS:
# To find templates. Depends on the pkg_resources.resource_string to tell 
wether it returns app name of full app name
/django/template/loaders/eggs.py:23: for app in 
settings.INSTALLED_APPS:
# To check specific app 

Re: Proposal/Discussion: url and template search using the directory structure of apps within django sites

[Jorge C . Leitão]

>
>  I must say that reading this into Russel (and other)'s replies is very 
> far fetched (language as well as content), uncalled for, and seems to 
> expose an assumption that the people here prefer the easy path of swatting 
> suggestions with a quick "nay".  I 'd say the opposite is much closer to 
> the truth.


I'm sorry, this was a joke; not something to be taken seriously. On the 
contrary, I assume people here are actually very well intended, and that's 
why I feel confident enough to put the joke here. Anyway, I'm not here to 
offend anyone or anything, so, I'm sorry for the sentence, I would retract 
it if I could.

I generally accept your criticisms and agree with your point of view that 
it is not so strait-forward in django's spirit. Let's them try to reach 
some specific points that would be worth implementing, even without the 
whole idea I'm proposing.

It seems you could achieve what you're after (at least for templates) with 
> a custom template loader. A variation on the app directories loader [0] can 
> impose a different search order than the default one that simply follows 
> the order in INSTALLED_APPS. Am I wrong?


YES!! Definitely this. However, the function get_template does not accept a 
directory to search. It is not possible to pass the directory of the search 
to the get_template: django.templates.loader.get_template only accepts one 
argument, i.e. you cannot tell which directory you want the template to be 
searched from the call. The two of the 10 lines of code I was referring to 
was change in that function:

from
get_template(template_name)
...
to
get_template(template_name*, dirs=None*)
...
template, origin = find_template(template_name*, dirs*)

this is compatible with the find_template function, which also has two 
arguments:

find_template(name, dirs=None)

For consistency, this should be implemented on the other two functions:

render_to_string
select_template

which should also receive dirs as arguments, with default=None and 
respective passing in the their calls of get_template.

This allows the developer to actually *choose* which template it is 
refering to when it uses render("secondary_header.html"), and works with 
the 

app_directories.Loader because it already has a optional argument 
"template_dirs".

So, yes, this is actually one of my proposals... change these 4 or 5 lines.

Cheers,
Jorge



On Thursday, May 30, 2013 12:50:34 PM UTC+2, Yishai Beeri wrote:
>
> Hello Jorge,
>
> On Thu, 30 May 2013 12:42:20 +0300, Jorge C. Leitão 
> <jorgeca...@gmail.com> 
> wrote:
>
> Hi Russell Keith-Magee.
>
> Thanks for your criticisms. Let's see if I can answer some of them. 
>  
>
>> I'd turn this question back onto you -- why *should* the search start 
>> locally? What collisions are you seeing between apps that makes a global 
>> search impractical?
>
>
> Very good question! I think this question is related with your point
>
> Well, no - I can see how you've managed to construct an example where 
>> local search might be useful (although I still don't concede that it 
>> couldn't be answered with global lookups). However, what I need to be 
>> convinced is to see an actual use case where this is an issue -- not a 
>> synthetic example, but a real world problem.
>
>  
> I.e. in my poor example I was not able to explain myself on the reason for 
> using local search.
>
> I'm sorry for the extension, but the reason is not so obvious.
>
> Consider the case where in a an app you have an header, with the website 
> logo and stuff, which you want to be consistent within your website, and 
> you have smaller secondary header, (secondary_header.html) which you want 
> to populate according to a specific app rendering the template.
>
>
> The "a specific app rendering the template" is not phrase is not 
> well-defined. Do you mean the app (in INSTALLED_APPS) that registered the 
> url matched for the current request? The python module where the view 
> function sits in? The python module whence the call to the template's 
> render() was made? The python module which loaded the template? These can 
> all be different things. Talking about "which app" makes some sense if 
> you're limiting yourself to URL names - but keep in mind that templates can 
> be (and often are) used outside of an HTTP request/response cycle - what's 
> the "app" then?
>
> One frequent option is to add a block tag and put your 
> (appname_secondary_header.html) with the same block tag, and call the 
> appname_secondary_header.html in the specific's app view. This is the 
> standard approach in Django and works great!
>
> The problem is when you try to port this app to another website which 
> already has that a

Re: Proposal/Discussion: url and template search using the directory structure of apps within django sites

[Jorge C . Leitão]

 May 30, 2013 8:17:49 AM UTC+2, Russell Keith-Magee wrote:
>
>
>
> On Wed, May 29, 2013 at 4:04 PM, Jorge C. Leitão 
> <jorgeca...@gmail.com
> > wrote:
>
>> Hi there.
>>
>> Django allows the possibility of putting apps within apps to improve 
>> structure of the code and increase portability. I find this absolutely 
>> genial.
>>
>> However, I find this feature quite limited by 2 key issues that are not 
>> compatible with this spirit, namely template "finder" and url "resolver".
>>
>> Problem
>> Both url and templates search works on a global basis, namely the search 
>> is made *globally* in the website's source, over all installed apps's 
>> templates/urls.py. I tried to convince myself that this is a good thing, 
>> but what I'm finding out that this leads to developers to have to 
>> constantly write url names and templates with the app's name prefix, which 
>> is well against the DRY principle, prone to errors, and not portable.
>>
>> In this two tickets 20521 <https://code.djangoproject.com/ticket/20521>
>>  and 20412 <https://code.djangoproject.com/ticket/20412> I tried (badly) 
>> to propose a solution that solves this issues, which were correctly 
>> wontfix. They are not so well though implementation speaking, but my 
>> message on both of them stands: why not consider a url/template search that 
>> starts the search *locally*? When I mean local I mean that the search 
>> FIRST considers the app where the search was called (i.e. the app that 
>> called render(request,...)), and only if it didn't found, it starts to 
>> search on the rest of the website.
>>
>
> I'd turn this question back onto you -- why *should* the search start 
> locally? What collisions are you seeing between apps that makes a global 
> search impractical?
>
> My point is that since django allows sub-apps, developers use them to 
>> create a directory structure of the apps. My main message is that django 
>> should use that information because the directory structure is what the 
>> developer is thinking about the relations between apps! If one app is a 
>> sub-app (child) of another (parent), probability it is because the child is 
>> not an app of global scope: only the parent needs it or the child 
>> implements a new set of views that extends the parent's ones.
>>
>  
> As Shai pointed out, Django *doesn't* have any concept of a sub-app - at 
> least, not built in.
>
> Proposal
>> I now introduce an example which I use to explain my proposal.
>>
>> Consider the example of apps like this (each is an app with __init__, 
>> templates, urls, views, etc):
>>
>> main/
>> phase1/
>> phase2/
>>
>> Let's say the main and each phase as a set of rules of usage, which means 
>> each phase has "views.rules" and main also has "views.rules". Moreover, 
>> because the website as a general structure, both phases extend a base 
>> template from main, where e.g. a footer has the tag {% url 'view.rules' %}. 
>> This is a stupid example, but I think you got the point: the actual url 
>> that appears on the footer should change according to the app rendering the 
>> template.
>>
>
> Well, no - I can see how you've managed to construct an example where 
> local search might be useful (although I still don't concede that it 
> couldn't be answered with global lookups). However, what I need to be 
> convinced is to see an actual use case where this is an issue -- not a 
> synthetic example, but a real world problem.
>  
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal/Discussion: url and template search using the directory structure of apps within django sites

[Jorge C . Leitão]

Hi Shai Berger and thanks for your quick response.

Regarding your criticisms,

On Thursday, May 30, 2013 7:54:40 AM UTC+2, Shai Berger wrote:
>
> Actually, Django doesn't. That is, an app is a Python package, and Python 
> packages can be nested, so you can have app 'b' within app 'a', and in 
> your 
> installed-apps, have both 'a' and 'a.b'. That will work fine. But as far 
> as 
> Django is concerned, they are just two separate apps. 
>
>
I completely understand your point, and I think this is a very important 
point. I agree when you say that "as far as Django is concerned, they are 
just two separate apps.". However, I believe that Django do allow nested 
apps. Allowing means not trowing an error when the developer does it. If 
django gives the developer the freedom to do it, it is because it allows it.

This motivates going back one step on my reasoning and put the following 
questions:

Why python allows nested apps?
What would be the reason for a developer to nest apps?
should django allow this?
why should django allow this?

I leave this questions open to discussion.


App names must be unique 
>

Yes, I agree with you, app names are unique. I'm not arguing that any of 
this would change.

Flat is better than nested.  


Thanks for pointing this out, and I believe this is a valid point. However, 
what I want to add is that I don't believe this renders my solution moot 
because Zen of python is used when two implementations give the same 
functionality. Otherwise python wouldn't allow nested apps...
What I'm proposing is a different functionality, which reduces to the 
current functionality if the developer doesn't do anything.

The problem you raise -- of name-collisions between elements in apps -- is 
> valid, but is a result of a long-standing decision; you will need very 
> convincing arguments to change that. 


Good that there is at least something valid! What I want to emphasize is 
that while programming this solution in my website, I ended up no longer 
having this problem, ever. I don't have any url name, any template with app 
prefix, any. What I want to try to understand with this post is: how does 
my solution can be used to improve django, and how can my solution be used 
in django without damaging anything else.

Hope this helps to clarify some of your concerns Shai Berger.

Cheers,
Jorge


-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal/Discussion: url and template search using the directory structure of apps within django sites

[Jorge C . Leitão]

Hi there.

Django allows the possibility of putting apps within apps to improve 
structure of the code and increase portability. I find this absolutely 
genial.

However, I find this feature quite limited by 2 key issues that are not 
compatible with this spirit, namely template "finder" and url "resolver".

Problem
Both url and templates search works on a global basis, namely the search is 
made *globally* in the website's source, over all installed apps's 
templates/urls.py. I tried to convince myself that this is a good thing, 
but what I'm finding out that this leads to developers to have to 
constantly write url names and templates with the app's name prefix, which 
is well against the DRY principle, prone to errors, and not portable.

In this two tickets 20521  and 
20412  I tried (badly) to 
propose a solution that solves this issues, which were correctly wontfix. 
They are not so well though implementation speaking, but my message on both 
of them stands: why not consider a url/template search that starts the 
search *locally*? When I mean local I mean that the search FIRST considers 
the app where the search was called (i.e. the app that called 
render(request,...)), and only if it didn't found, it starts to search on 
the rest of the website.

My point is that since django allows sub-apps, developers use them to 
create a directory structure of the apps. My main message is that django 
should use that information because the directory structure is what the 
developer is thinking about the relations between apps! If one app is a 
sub-app (child) of another (parent), probability it is because the child is 
not an app of global scope: only the parent needs it or the child 
implements a new set of views that extends the parent's ones.

Proposal
I now introduce an example which I use to explain my proposal.

Consider the example of apps like this (each is an app with __init__, 
templates, urls, views, etc):

main/
phase1/
phase2/

Let's say the main and each phase as a set of rules of usage, which means 
each phase has "views.rules" and main also has "views.rules". Moreover, 
because the website as a general structure, both phases extend a base 
template from main, where e.g. a footer has the tag {% url 'view.rules' %}. 
This is a stupid example, but I think you got the point: the actual url 
that appears on the footer should change according to the app rendering the 
template.

Notice that the template is incorrect on purpose as it is leads to 
NoReverseMatch since {% url 'main.view.rules' %} should be the correct one.

The design I'm proposing is the following:

First, the render function (the one in shortcuts) asks what is the current 
app calling it, this can be for instance using 
inspect python's 
module. If e.g. the call was the view rules from main.phase2.views, then 
context.current_app='main.phase2'.

Second, the {% url %} tag, which has access to the context, starts by 
searching as if the actual path on the url tag was 
'main.phase2'+'view.rules':

if NoReverseMatch, it tries 'main'+'view.rules',
if it fails, it raises NoReverseMatch.

This is naturally extensible to templates tag {% include %}, and the idea 
is the same: first search the templates of the sub-app, then app, until it 
reaches the global scope.

So, the idea is that because the developer put an child_app within another 
parent_app, it is telling django that that child_app is part of or extends 
parent_app. I don't see the reason why django doesn't fulfill the 
developer's wish and considers child_app part of parent_app.


With this, I would like to open a discussion on pros, cons, and caveats of 
such modification on django's design.

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.