On Sun, Jun 24, 2012 at 12:17 PM, <django-developers@googlegroups.com> 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 <baxterstock...@gmail.com> 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 <andres.doug...@gmail.com> 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]" <cal.leem...@simplicitymedialtd.co.uk> > 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 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.
