Re: Digest for django-developers@googlegroups.com - 3 Messages in 2 Topics

[Daniel Greenfeld]

On Sun, Jun 24, 2012 at 12:17 PM,   wrote:
>   Today's Topic Summary
>
> Group: http://groups.google.com/group/django-developers/topics
>
> Proposal: Add some extensibility / decoupling features to Django templates
> [1 Update]
> Django-nonrel patches [2 Updates]
>
>  Proposal: Add some extensibility / decoupling features to Django templates
>
> Yo-Yo Ma  Jun 23 05:17PM -0700
>
> I'll start with an example:
>
> Using Jinja2, I can create an environment which is pretty secure (no access
> to anything but built-ins and objects explicitly marked "safe"), and
> provide a loader who's templates are loaded from the database (e.g.,
> ``request.client.template_set.all()``), and customize all this for a single
> request (Since I can simply instantiate an ``Environment`` per request with
> a custom ``Loader`` which has access to only the ``request.client``
> templates). I can also customize the extensions on a per-request basis
> (that's sort of analogous to customizing template tag/filter built-ins), in
> order to limit or add to the type of tools that clients have access to.
>
> Using Django templates, I'm left with simply running my clients' sites
> portion of the app under a different settings file. This *almost* cuts it
> too (since I can use a different URL conf which includes different
> template.add_to_builtins() calls, etc.), but it doesn't give me all the
> things that I need, like the ability to instantiate the loader with a
> queryset of templates for the ``request.client``, etc.
>
> "Why don't you just use Jinja2 then?"
>
> The Django core team is a pretty intelligent team, and the philosophy
> behind the style of tags / filters / lack of logic in Django templates is
> far superior to Jinja2. I simply want a more Jinja2-ish Python API for
> using Django templates.
>
>
> My Proposal (abstract explanation, btw, I'd be happy to help architect /
> write code):
>
> Without changing any of the existing functionality or settings in Django,
> refactor the template system to use an ``Environment`` class (something
> akin to Jinja2's ``Environment``) which takes a list of loaders, and a
> number of other arguments. Then, instantiate this class, using the provided
> settings, and use it for all the default functionality (the admin,
> render_to_response, CBV template access, etc.). This would allow developers
> to make their own ``Environment`` instance with different arguments,
> request-specific or otherwise, and without having to do a lot of evil
> things.
>
>
> Thanks
> Fellow Djangonaut
>
>
>
>  Django-nonrel patches
>
> Andres Douglas  Jun 22 09:30PM -0700
>
> Hey All,
>
> I've been trying to use django with mongo and it seems like django-nonrel
> is still the best option out there. The only sad fact is that it's still
> not part of the official django. Looking for an answer as to why that was
> the case, I came across this thread. Are tests and docs all that are
> missing? Can someone provide pointers to what might be expected and
> considered acceptable?
>
> It seems like a lot of the hard work has already been done figuring out
> what needed to change and the only thing left shouldn't be as hard -
> hopefully these are not famous last words.
>
> On Sunday, January 8, 2012 12:45:08 PM UTC-5, Jonas H. wrote:
>
>
>
> "Cal Leeming [Simplicity Media Ltd]" 
> Jun 23 08:13PM +0100
>
> Hi Andres,
>
> Afaik, there's currently some compatibility issues with Django 1.4 - so
> it's not currently stable.
>
> Also, in my own personal opinion - after having a chance to use the mongo
> models with Django, in my personal opinion, it just didn't "feel right".
> Not entirely sure how to explain what that means, but for whatever reason
> the approach used just didn't feel like it was the best approach that could
> be used.
>
> Would be interesting to hear what conclusions other people came too,
> especially any core devs involved in the ORM.
>
> Cal

We evaluated django-nonrel for use in projects and looked again at
django-nonrel for our talk at DjangoCon Europe. To summarize our
findings and opinions:

1. django-nonrel is stuck on Django 1.3, which has some security implications.
2. django-nonrel is unsupported. It switched maintainers and the
current maintainer is not working on it.
3. [pydanny opinion warning] django-nonrel wasn't adopted in Django
core because it lacked adequate documentation and tests.
4. [pydanny opinion warning] django-nonrel treats MongoDB as a
relational store, which it most certainly is not.
5. [pydanny opinion warning] django-nonrel smells like a giant hack
done by very well intentioned people..

Hope that helps,

-- 
'Knowledge is Power'
Daniel Greenfeld
http://pydanny.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 

Proposal: Add some extensibility / decoupling features to Django templates

[Yo-Yo Ma]

I'll start with an example:

Using Jinja2, I can create an environment which is pretty secure (no access 
to anything but built-ins and objects explicitly marked "safe"), and 
provide a loader who's templates are loaded from the database (e.g., 
``request.client.template_set.all()``), and customize all this for a single 
request (Since I can simply instantiate an ``Environment`` per request with 
a custom ``Loader`` which has access to only the ``request.client`` 
templates). I can also customize the extensions on a per-request basis 
(that's sort of analogous to customizing template tag/filter built-ins), in 
order to limit or add to the type of tools that clients have access to.

Using Django templates, I'm left with simply running my clients' sites 
portion of the app under a different settings file. This *almost* cuts it 
too (since I can use a different URL conf which includes different 
template.add_to_builtins() calls, etc.), but it doesn't give me all the 
things that I need, like the ability to instantiate the loader with a 
queryset of templates for the ``request.client``, etc. 

"Why don't you just use Jinja2 then?"

The Django core team is a pretty intelligent team, and the philosophy 
behind the style of tags / filters / lack of logic in Django templates is 
far superior to Jinja2. I simply want a more Jinja2-ish Python API for 
using Django templates.


My Proposal (abstract explanation, btw, I'd be happy to help architect / 
write code):

Without changing any of the existing functionality or settings in Django, 
refactor the template system to use an ``Environment`` class (something 
akin to Jinja2's ``Environment``) which takes a list of loaders, and a 
number of other arguments. Then, instantiate this class, using the provided 
settings, and use it for all the default functionality (the admin, 
render_to_response, CBV template access, etc.). This would allow developers 
to make their own ``Environment`` instance with different arguments, 
request-specific or otherwise, and without having to do a lot of evil 
things.


Thanks
Fellow Djangonaut

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/h9ExRYxoxHUJ.
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: Django-nonrel patches

[Cal Leeming [Simplicity Media Ltd]]

Hi Andres,

Afaik, there's currently some compatibility issues with Django 1.4 - so
it's not currently stable.

Also, in my own personal opinion - after having a chance to use the mongo
models with Django, in my personal opinion, it just didn't "feel right".
Not entirely sure how to explain what that means, but for whatever reason
the approach used just didn't feel like it was the best approach that could
be used.

Would be interesting to hear what conclusions other people came too,
especially any core devs involved in the ORM.

Cal

On Sat, Jun 23, 2012 at 5:30 AM, Andres Douglas wrote:

> Hey All,
>
> I've been trying to use django with mongo and it seems like django-nonrel
> is still the best option out there. The only sad fact is that it's still
> not part of the official django. Looking for an answer as to why that was
> the case, I came across this thread. Are tests and docs all that are
> missing? Can someone provide pointers to what might be expected and
> considered acceptable?
>
> It seems like a lot of the hard work has already been done figuring out
> what needed to change and the only thing left shouldn't be as hard -
> hopefully these are not famous last words.
>
> On Sunday, January 8, 2012 12:45:08 PM UTC-5, Jonas H. wrote:
>>
>> On Sun 08 Jan 2012 05:39:02 PM CET, Emil Stenström wrote:
>> >
>> >
>> > On Thursday, December 8, 2011 10:31:39 PM UTC+1, jo...@lophus.orgwrote:
>> >>
>> >> 1.) I didn't write the code, I'm just submitting the patches in their
>> >> current state
>> >>
>> > Jonas: Do you have information on who wrote the code that you
>> submitted? I
>> > guess a good way forward would be to find those people, and have them
>> > contribute a brief explanation of what problem their patch was trying to
>> > solve. For a "solution" to be accepted, you need to know the problem.
>> >
>>
>> Waldemar Kornewald wrote most of the code but he's pretty busy these
>> days.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/PmkY0RQA248J.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django-nonrel patches

[Andres Douglas]

Hey All,

I've been trying to use django with mongo and it seems like django-nonrel 
is still the best option out there. The only sad fact is that it's still 
not part of the official django. Looking for an answer as to why that was 
the case, I came across this thread. Are tests and docs all that are 
missing? Can someone provide pointers to what might be expected and 
considered acceptable?

It seems like a lot of the hard work has already been done figuring out 
what needed to change and the only thing left shouldn't be as hard - 
hopefully these are not famous last words.

On Sunday, January 8, 2012 12:45:08 PM UTC-5, Jonas H. wrote:
>
> On Sun 08 Jan 2012 05:39:02 PM CET, Emil Stenström wrote:
> >
> >
> > On Thursday, December 8, 2011 10:31:39 PM UTC+1, jo...@lophus.org wrote:
> >>
> >> 1.) I didn't write the code, I'm just submitting the patches in their
> >> current state
> >>
> > Jonas: Do you have information on who wrote the code that you submitted? 
> I
> > guess a good way forward would be to find those people, and have them
> > contribute a brief explanation of what problem their patch was trying to
> > solve. For a "solution" to be accepted, you need to know the problem.
> >
>
> Waldemar Kornewald wrote most of the code but he's pretty busy these 
> days.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/PmkY0RQA248J.
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.