Re: Can you add a build-in template tags?

[butterhuang]

Thank you very much!!

Michael P. Jung wrote:
> > How can I cache the sub-template witch is included in the main
> > template? And how can I ensure it won't be render(parse) the next
> > request?
>
> If you look at django.template.loader_tags.do_include you'll notice an
> if statement that checks if the given argument was a string. If so it'll
> use a ConstantIncludeNode rather than a normal IncludeNode. The constant
> include node inlines the sub-template while the normal node does have to
> look up that variable during render time.
>
> Side notice: That's also the reason why you can't include templates
> recursively with static strings but have to use a workaround like "{%
> with "recursive.html" as template %}{% include template %}{% endwith %}"
> or a custom template tag.
>
>
> Caching the template is as easy as storing the result from get_template
> in a global variable.
>
> e.g.
>
> from django.template.loader import get_template
> foo_template = get_template('foobar.html')
> def foo(request):
> ctx = RequestContext(request)
> ctx.update({'foo': True, 'bar': False})
> return HttpResponse(foo_template.render(ctx))
>
>
> Note: I'd rather lazy load the template in order to decouple things a
> bit. Be aware of race conditions and better synchronize the template
> loading. The above code snippet is only meant to give you the idea.
>
>
> --mp
--~--~-~--~~~---~--~~
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: 1.2 Feature Suggestion

[Russell Keith-Magee]

On Mon, Oct 26, 2009 at 9:40 AM, James Bennett  wrote:
>
> On Sun, Oct 25, 2009 at 8:30 PM, Russell Keith-Magee
>  wrote:
>> A wiki page doesn't really solve the problem either. If you make it an
>> exclusive list, someone has to decide who is on the list and who
>> isn't. If you make it a comprehensive list, a wiki page will very
>> rapidly become unusable due to the volume of reusable apps out there -
>> wiki format doesn't provide a lot of creative options for
>> indexing/organizing content on multiple axes.
>
> It seems to me that there's already a site out there which indexes and
> organizes on multiple axes:
>
> http://pypi.python.org/pypi?:action=browse=523
>
> or just lists Django stuff:
>
> http://pypi.python.org/pypi?:action=browse=all=523
>
> (several of my comments on proposed contrib additions for 1.2 pointed
> this out -- we already have the infrastructure, now let's encourage
> people to use it)

I agree that PyPI solves *part* of the problem - in particular, the
automated installation aspects of the problem. However, IMHO PyPI
really blows as a resource discovery tool - because the axes it
provides and indexes aren't really useful axes for the problem that
needs solving.

A use-case driven example:

I am a new user to Django. I am building a website that will require a
member signup process. Is there a Django app that will help me with
this?

"django member signup" returns (as far as I can make out) every single
PyPI registration that mentions "django". This is not a good starting
point.

If you're willing to filter through hundred of results to find the
nuggets of goodness, you will discover (in this order)
django-invitation, django-social-registration, django-account,
django-invite, and django-registration. There may be other packages
that are appropriate, but the search results don't provide any easy
way to filter these out. The search results also include entries that
are Zope and Plone specific.

Which one of these projects should I look at first? Which ones do the
community consider to be good applications? I don't think it's too
controversial to say that there would be a reasonable consensus that
django-registration is a pretty good example of a Django reusable app,
but it's the last result in list. The other candidates may also be
good, but if a new user came to me and asked this question, I know I
would be pointing them at django-registration first.

So - PyPI provides an excellent machine-readable index for PIP to use,
but it is missing two important features for it to be useful as a
community tool:

 * No web application specific metadata in the trove classifiers
 * No social contribution to help filter the wheat from the chaff

As allegorical evidence in support of my claims - I can't remember the
last time I used PyPI as a search tool to find a Python package (I'm
not talking Django-specific, either - I mean Python packages in
general). It's great resource for pip to use, but awful for people
IMHO.

The trove classifiers are a particular problem, IMHO. They are a
static list that borders on comical in their scope. Trove provides a
classifier to say that your project is compatible with GNU Hurd, but
doesn't provide classifiers that are useful in a web context, like
"member signup", "voting", "tagging", or "caching". It provides a
classifier for "SCCS" and "RCS", but not for "Mercurial" or "git".
Trove lets you easily find a list of 306 Django packages, but provides
very little help to narrow the search any further based on the task
you want to perform - and as far as I can make out, you can't do a
search inside a trove classifier.

Related to this - there is no synonym suggestion around these trove
classifiers. Is it "member signup" or "member registration" or just
"registration"? To be sure - this isn't an easy problem to solve, but
as far as I can make out PyPI make no attempt to solve it at all.

One solution here might be to work with the Python core guys to
improve PyPI. The other solution is to build a Django-specific social
layer that leverages the machine-readable data in PyPI, but provides
the extra features that PyPI is missing.

I'm open to either option, but my gut feeling is that the latter will
be much easier to execute, if only because we won't have to deal with:
 1) Wrangling a community much larger than our own
 2) Fighting "No, can't let Django control the agenda" Python community angst
 3) Trying to satisfy use cases that are of no importance to Django,
but might be important to other communities.

I would also note that I'm also not entirely convinced that it is
right for PyPI to evolve beyond being a simple machine-readable index.
I strongly suspect the social needs of the Django community will be
quite different to those in the Pylons or Zope communities - or those
in NLP, bioinformatics, or any other domains where Python is used. A
caching tool that is a good match for Django may not be a good match
for 

Re: Doubt about urlencode filter implementation

[Joe Tyson]

I believe that's the expected outcome.. The use is to encode something for
the use in an URL...

Eg. convert "some-crazy//user?input" into something that can safely be
passed into http://www.google.com/search?q=URL_ENCODED_STRING

On Sun, Oct 25, 2009 at 9:14 PM, Danilo Cabello wrote:

>
> Hi,
>
> Looking for urlencode[1] implementation, I saw[2] that it uses
> urlquote on django.utils.http[3] and when I try to encode and URL like
> "http://www.google.com; using that filter, I receive the follow return
> "http%3A//www.google.com":
>
> >>> from django.template.defaultfilters import urlencode
> >>> urlencode('http://www.google.com')
> u'http%3A//www.google.com'
>
> My doubt: is that the expected result when using this filter?
>
> If not I can submit a ticket with the patch.
>
> Regards,
> Danilo Cabello
>
> [1] -
> http://docs.djangoproject.com/en/dev/ref/templates/builtins/#urlencode
> [2] -
> http://code.djangoproject.com/browser/django/trunk/django/template/defaultfilters.py#L292
> [3] -
> http://code.djangoproject.com/browser/django/trunk/django/utils/http.py#L10
>
> >
>

--~--~-~--~~~---~--~~
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: 1.2 Feature Suggestion

[James Bennett]

On Sun, Oct 25, 2009 at 8:30 PM, Russell Keith-Magee
 wrote:
> A wiki page doesn't really solve the problem either. If you make it an
> exclusive list, someone has to decide who is on the list and who
> isn't. If you make it a comprehensive list, a wiki page will very
> rapidly become unusable due to the volume of reusable apps out there -
> wiki format doesn't provide a lot of creative options for
> indexing/organizing content on multiple axes.

It seems to me that there's already a site out there which indexes and
organizes on multiple axes:

http://pypi.python.org/pypi?:action=browse=523

or just lists Django stuff:

http://pypi.python.org/pypi?:action=browse=all=523

(several of my comments on proposed contrib additions for 1.2 pointed
this out -- we already have the infrastructure, now let's encourage
people to use it)

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
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: 1.2 Feature Suggestion

[Joshua Russo]

On Mon, Oct 26, 2009 at 12:30 AM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:

>
> A wiki page doesn't really solve the problem either. If you make it an
> exclusive list, someone has to decide who is on the list and who
> isn't. If you make it a comprehensive list, a wiki page will very
> rapidly become unusable due to the volume of reusable apps out there -
> wiki format doesn't provide a lot of creative options for
> indexing/organizing content on multiple axes.


That's a good point. You really do need a better way to manage a list of
that size. A wiki page is better used for less dynamic lists and
information.

--~--~-~--~~~---~--~~
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: 1.2 Feature Suggestion

[Russell Keith-Magee]

On Mon, Oct 26, 2009 at 8:32 AM, Tobias McNulty  wrote:
> On Sun, Oct 25, 2009 at 7:39 PM, Dan  wrote:
>>
>> I didn't know about rosetta. What would you guys think of having a doc
>> section about popular third party apps?

Putting a list of applications really isn't the right solution - for
one thing, the list of available applications changes much faster than
Django does. Secondly, the core team doesn't want to get into the
business of officially blessing certain applications.

A wiki page doesn't really solve the problem either. If you make it an
exclusive list, someone has to decide who is on the list and who
isn't. If you make it a comprehensive list, a wiki page will very
rapidly become unusable due to the volume of reusable apps out there -
wiki format doesn't provide a lot of creative options for
indexing/organizing content on multiple axes.

> I think this is best done through a third party site.  Look at the success
> of DjangoGigs.  I don't know that there's a de facto place to look for apps
> yet, but I bet a winner will emerge in time.

I agree - and for those that aren't aware of the options out there,
I'm aware of at least 3 sites that already do this:

http://djangozen.com/
http://djangoworld.com/
http://django-apps.com/

Once upon a time http://djangopluggables.com/ would have been on this
list too. However, that site has been down for a couple of months now,
and nobody seems to know what happened to it.

One of the topics of discussion at DjangoCon was a discussion of what
(if anything) the DSF could do to assist with community resources such
as these. So - watch this space for developments, but in the meantime,
try out the options that already exist, and if you aren't happy with
any of them, try to make something better - or better yet, offer to
help make one of the existing candidates better.

Yours,
Russ Magee %-)

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

Doubt about urlencode filter implementation

[Danilo Cabello]

Hi,

Looking for urlencode[1] implementation, I saw[2] that it uses
urlquote on django.utils.http[3] and when I try to encode and URL like
"http://www.google.com; using that filter, I receive the follow return
"http%3A//www.google.com":

>>> from django.template.defaultfilters import urlencode
>>> urlencode('http://www.google.com')
u'http%3A//www.google.com'

My doubt: is that the expected result when using this filter?

If not I can submit a ticket with the patch.

Regards,
Danilo Cabello

[1] - http://docs.djangoproject.com/en/dev/ref/templates/builtins/#urlencode
[2] - 
http://code.djangoproject.com/browser/django/trunk/django/template/defaultfilters.py#L292
[3] - 
http://code.djangoproject.com/browser/django/trunk/django/utils/http.py#L10

--~--~-~--~~~---~--~~
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: 1.2 Feature Suggestion

[Joshua Russo]

On Sun, Oct 25, 2009 at 11:48 PM, Dan  wrote:

> I think this is best done through a third party site.  Look at the success
>> of DjangoGigs.  I don't know that there's a de facto place to look for apps
>> yet, but I bet a winner will emerge in time.
>>
>> Tobias
>>
>>
> The problem I see with that is that we clearly *are* standardizing toward
> some third parties apps. Not strongly enough to commit them to contrib with
> all the duties it implies but still! I don't think the doc is doing enough
> to let newcomers have the best tools available for their Django development.
>
> Or maybe we can go the Wiki route and display on the front page "ORM,
> cache, elegant URLs, ..., plenty of third party apps [link to a wiki page]".
>
> That way, there would be very little burden for the core devs and page
> would evolve as the different tools emerge.


I think a Wiki page would be the best way to handle this. I agree that there
is a need to more actively advertise some of the more popular third party
apps for new comers but those apps don't follow our dev cycle, so having
them in our docs doesn't seem to make sense.

Josh

--~--~-~--~~~---~--~~
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: 1.2 Feature Suggestion

[Dan]

>
> I think this is best done through a third party site.  Look at the success
> of DjangoGigs.  I don't know that there's a de facto place to look for apps
> yet, but I bet a winner will emerge in time.
>
> Tobias
>
>
The problem I see with that is that we clearly *are* standardizing toward
some third parties apps. Not strongly enough to commit them to contrib with
all the duties it implies but still! I don't think the doc is doing enough
to let newcomers have the best tools available for their Django development.

Or maybe we can go the Wiki route and display on the front page "ORM, cache,
elegant URLs, ..., plenty of third party apps [link to a wiki page]".

That way, there would be very little burden for the core devs and page would
evolve as the different tools emerge.

--~--~-~--~~~---~--~~
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: 1.2 Feature Suggestion

[Tobias McNulty]

On Sun, Oct 25, 2009 at 7:39 PM, Dan  wrote:
>
> I didn't know about rosetta. What would you guys think of having a doc
> section about popular third party apps?


I think this is best done through a third party site.  Look at the success
of DjangoGigs.  I don't know that there's a de facto place to look for apps
yet, but I bet a winner will emerge in time.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

--~--~-~--~~~---~--~~
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: non-relational DB

[Russell Keith-Magee]

On Mon, Oct 26, 2009 at 12:42 AM, Thomas Wanschik
 wrote:
>
>
>
> On 22 Okt., 23:52, Russell Keith-Magee  wrote:
>> On Fri, Oct 23, 2009 at 5:09 AM, Thomas Wanschik
>>
>>  wrote:
>>
>> >> When a new QuerySet is instantiated (e.g. by calling
>> >> Model.objects.all()) it asks the backend for its Query class and then
>> >> creates an instance of that class. By default, this class is
>> >> sql.Query. Only the Oracle backend has its own Query which subclasses
>> >> sql.Query.
>>
>> > I think Waldermar wanted to say: 'Only the Oracle backend has its own
>> > Query which subclasses sql.query.BaseQuery.' instead of 'sql.Query'.
>>
>> I should point out that this is one of the specific problems Alex and
>> I are trying to address in the multi-db refactor. When we've finished,
>> returning the right query class should be as simple as implementing an
>> API on the backend.
>>
>
> Thanks for your answer Russell. But i have one question left. Should
> we make the effort and clean the app engine backend up in the way the
> oracle backend is done (using a query_class) or should we wait for the
> multi-db refactor and then clean up our code according to multi-db?
> Will it be easier to merge the backend into django then?

The current query_class will need to change slightly to support
multi-db, so anything you implement against that interface will
require some rework later on. That said, the fundamental approach
(i.e., the backend tells you what class to use for queries) will still
be there - it will just be used in a slightly different way.

If you want to write (and test) code now, my suggestion would be to
try making your code as clean as possible against the current
interface, with the expectation that there will be some rework once
multi-db lands. The corollary to this is that if you find yourself
needing to make weird and widespread engineering decisions in order to
support the query_class approach, you should stop and wait for
multi-db to land.

Yours
Russ Magee %-)

--~--~-~--~~~---~--~~
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: 1.2 Feature Suggestion

[Dan]

> A few things:
>
> a) The feature proposal phase has already passed, it went on for the
> last 3 months or so.
> b) There's already an external application that does this:
> http://code.google.com/p/django-rosetta/
>
> Alex
>
>
I didn't know about rosetta. What would you guys think of having a doc
section about popular third party apps? I found many must-have Django tools
like the debug toolbar, south and command extension because I follow blogs
and read the mailing list but I feel the Django documentation should help
newcomers find those things.

I don't mean Django should document third parties stuff but there should be
an easy to find section in the doc with links (and appropriate disclaimers
obviously).

Should I file a ticket for it?

--~--~-~--~~~---~--~~
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: non-relational DB

[Thomas Wanschik]

On 22 Okt., 23:52, Russell Keith-Magee  wrote:
> On Fri, Oct 23, 2009 at 5:09 AM, Thomas Wanschik
>
>  wrote:
>
> >> When a new QuerySet is instantiated (e.g. by calling
> >> Model.objects.all()) it asks the backend for its Query class and then
> >> creates an instance of that class. By default, this class is
> >> sql.Query. Only the Oracle backend has its own Query which subclasses
> >> sql.Query.
>
> > I think Waldermar wanted to say: 'Only the Oracle backend has its own
> > Query which subclasses sql.query.BaseQuery.' instead of 'sql.Query'.
>
> I should point out that this is one of the specific problems Alex and
> I are trying to address in the multi-db refactor. When we've finished,
> returning the right query class should be as simple as implementing an
> API on the backend.
>

Thanks for your answer Russell. But i have one question left. Should
we make the effort and clean the app engine backend up in the way the
oracle backend is done (using a query_class) or should we wait for the
multi-db refactor and then clean up our code according to multi-db?
Will it be easier to merge the backend into django then?

Bye,
Thomas Wanschik

> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

project folder with dots

[reg_gc]

Hello, django developers!

On my server every project has it's own folder which name is the same
as project hostname(ex. /home/testsite.com). Bug django don't allow
dots in "project name".

I think we can fix it. For example by avoiding starting import with
project name.

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

Advocacy for Email-01 (email backends)

[Russell Keith-Magee]

Hi all,

The v1.2 votes are in, and it appears that Email-01 (introducing an
email backend API) needs some more discussion.

I am in complete agreement that Django shouldn't try to become an
email framework. That isn't the intention of this proposal.

The intention is to fix a specific problem that exists for supporting
sandboxed deployment environments, and AppEngine in particular.

AppEngine doesn't provide an SMTP server - the AppEngine sandbox
provides a specific API for sending email, rather than the standard
Python mail API. This is a problem because because Django provides an
API for sending email - and uses that API internally:

 * contrib.auth sends mail as part of the password reset process
 * contrib.comments sends mail as part of the comment moderation process
 * the 500 handler sends mail to site admins
 * the CommonMiddleware sends mail on broken links to site managers

If we're going to fully support AppEngine (and any other sandboxed
deployment platform), we need to provide a way to direct Django's
email APIs to APIs provided by a sandbox.

As a side effect, providing email an backend API cleans up a few other
minor lingering issues:

  - It cleans up the monkeypatching required by the test framework,
since emails can be easily redirected to an in-memory backend during
test execution.

 - It provides an easy way to debug email sending on the development
server. An 'email test server' was proposed - and ultimately rejected
- for v1.1. A 'console' email backend resolves this problem by
providing a way to direct email to stdout, rather than SMTP.

 - It provides an elegant entry point for tools like django-mailer.
The email backend API would allow django-mailer to become a specialist
external email backend. This allows for greater decoupling: apps can
just call the Django mail api, rather than needing to specifically
provide django-mailer support.

I felt an email backend API would be an elegant way to gain a lot of
flexibility, with essentially no impact for existing users. The
original django-dev discussion [1] didn't raise much dissent - but the
voting process has shown that there is obviously some disagreement.

I'm keen to see a resolution to this problem. To that end, I'm
interested in hearing specific criticisms or concerns with the current
backend proposal. I'm also interested in any alternate approaches to
this problem.

[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/ad0e5b2a8fd1ffe4

Yours,
Russ Magee %-)

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