Re: Model.objects.raw() (#11863)
To be honest this seems like something which would be a lot of work with
relatively little gain. For this to work raw() would need to change from a
relatively simple bit of code which doesn't need to touch all of the complex
query code in the ORM to a complex bit of code which needs to deeply modify
the behavior of the query code.
For most use-cases where you simply wish to inject bits of SQL into the
query, the existing extra() method works well. Otherwise you've probably
already written the query you want to use. To use "advanced extra" type
tools you'd have to do additional work to break down your new query into
something that fits into these functions. With a simple raw all one would
need to do is plug their query into the raw() method.
In addition to making raw() much more complicated, this proposal eliminates
or dramatically complicates the possibility of implementing raw() for
non-relational back-ends.
If somebody really wants this functionality and can provide an
implementation it could certainly be looked at more deeply. Otherwise IMHO
this would not be a good thing to add to raw() and have little interest in
implementing it.
____
Sean O'Connor
http://seanoc.com
On Fri, Oct 2, 2009 at 7:35 AM, mrts wrote:
>
> Wishful thinking follows.
>
> It would be awesome if one could mix ordinary QuerySet methods
> with raw() (or, rather, raw_extra(), see below for that).
>
> Assuming the following models:
>
> class Foo(models.Model):
>name = models.CharField(max_length=255)
>
> class FooDates(models.Model):
>foo = models.ForeignKey(Foo)
>start = models.DateField()
>end = models.DateField()
>
> I for one would be definitely struck with awe if
> I could write something in the lines of:
>
> RAW_ORDER_BY = """
> ORDER BY (SELECT MIN("start")
>FROM "myapp_foodates"
>WHERE "myapp_foodates"."start" >= %s
>AND "myapp_foo.id" = "myapp_foodates"."foo_id")
> """
>
> q = Foo.objects.filter(
>foodate__end__gte=datetime.date.now())\
>.raw(RAW_ORDER_BY, params=(datetime.date.now(),))\
>.distinct()
>
> and q.query.as_sql() would look as follows:
>
> SELECT DISTINCT ...
> FROM "myapp_foo"
> INNER JOIN "myapp_foodates"
> ON ("myapp_foo"."id" = "myapp_foodates"."foo_id")
> WHERE "myapp_foodates"."end" >= "2009-10-02"
> ORDER BY (
> SELECT MIN("start")
> FROM "myapp_foodates"
> WHERE "myapp_foodates"."start" >= "2009-10-02"
> AND "myapp_foo"."id" = "myapp_foodates"."foo_id");
>
> However, I assume that achieving this would be extremely
> hard with plain raw().
>
> What probably would work, however, is an extra()-like
> raw_extra() that would accept raw parametrized strings
> for each of `select`, `where` and `order_by` and plainly
> replace the corresponding part in the query builder.
>
> I.e. the example above would read:
>
> q = Foo.objects.filter(
>foodate__end__gte=datetime.date.now())\
>.raw_extra(order_by=RAW_ORDER_BY,
>params=(datetime.date.now(),))\
>.distinct()
>
> Best,
> Mart Sõmermaa
> >
>
--~--~-~--~~~---~--~~
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: Last call: #11863 (Model.objects.raw)
Big thanks Jacob for picking up my slack and putting the finishing touches
on the patch and writing the docs. Work got crazy and I dropped the ball.
Definitely happy that the work will get completed and put into trunk
regardless.
In regard to the deferred fields option, I'll let Jacob speak for his view
but I've approached such functionality as "nice to have" for the patch since
its not critical to the patch being useful. Personally I haven't had the
time to figure it out and implement it so my original patch didn't include
it.
For the multidb approach I'd lean towards the kwargs approach. Right now
the .raw() code is fairly well insulated from the bulk of the ORM and visa
versa. This keeps the raw() code pretty simple and minimizes the
opportunities for introducing new bugs in the ORM.
As far as putting raw() on querysets I'd be pretty against it as well. It
strikes me in a lot of ways as mutli-table inheritance does. People are
really going to want it, until they try and use it in the real world, and
realize that it was a really bad idea. While I'm sure Russ or some others
around here could work some awesome magic and get it working after a
fashion, I don't think it will ever work the way a new user will expect.
What does performing a raw query on a queryset even mean? In the end I
think adding .raw() to queryset would lead to a much more complicated
implementation and more confusion for users.
Sean O'Connor
http://seanoc.com
On Tue, Dec 15, 2009 at 8:24 PM, Russell Keith-Magee wrote:
> On Wed, Dec 16, 2009 at 6:15 AM, Jacob Kaplan-Moss
> wrote:
> > Hey folks --
> >
> > Forgot to mention it during the sprint this weekend, but I've pushed a
> > RC patch to #11863, Model.objects.raw(). If anyone's got any feedback,
> > let it fly. Otherwise, I'll be checking this in in a couple-three days
> > or so.
>
> Hi Jacob,
>
> A couple of quick notes on the RC2 patch:
>
> * If you have an incomplete selection of fields, the patch currently
> marks those fields as None/default values. Couldn't (Shouldn't?) they
> be marked as deferred fields?
>
> * Looking slightly forward - what's the integration point for
> multidb? One option is to put a using argument on raw::
>
> Person.objects.raw('SELECT ...", using='other')
>
> It would be nice to allow .using(), but while it is easy to allow::
>
> Person.objects.raw('SELECT ...").using('other')
>
> it isn't so easy to allow::
>
> Person.objects.using('other').raw('SELECT ...")
>
> We could jump through some hoops to put raw() on queryset, but raise
> exceptions under most uses (i.e., if you've performed any query
> modifying operation). However, this is a lot of hoops just to allow an
> edge case API use.
>
> Obviously, multidb isn't in scope for this patch, but given the
> obvious overlap, I thought I'd ask for opinions.
>
> Other than that, RC2 looks good to me.
>
> Russ %-)
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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: Last call: #11863 (Model.objects.raw)
Nice work Russ! Got to love when something goes from "nice to have" to
"done".
Anssi, I don't think I understand your use case. Even if an unmanaged model
doesn't have a literal table behind it, it needs something which at least
resembles a table (i.e. a view) to query against. Otherwise the ORM will
generate errors regardless of the behavior of .raw().
To answer your question, raw() determines what fields are populated by the
names of the columns returned by the database cursor. Accordingly, if you
want to pull different fields using different queries, you probably do so
using subqueries in one big SQL statement. As long as the field names
returned by the query match the field names in the model or you provide a
translations parameter to describe which query fields go to which model
fields it should work.
As far as allowing users to define raw queries for each field to allow them
to be deferred, this is way outside the scope of this patch. The goal of
.raw() was to provide some relatively simple syntactic sugar to make a
common class of raw queries easier. It was not intended to completely
replace all possible use cases for doing raw queries using a cursor.
____
Sean O'Connor
http://seanoc.com
On Wed, Dec 16, 2009 at 9:19 AM, Anssi Kaariainen wrote:
>
>
> On Dec 16, 2:51 pm, Russell Keith-Magee
> wrote:
> > On Wed, Dec 16, 2009 at 7:56 PM, Jeremy Dunck wrote:
> > > On Dec 15, 2009, at 11:16 PM, "Sean O'Connor"
> > > wrote:
> >
> > >> In regard to the deferred fields option, I'll let Jacob speak for
> > >> his view but I've approached such functionality as "nice to have"
> > >> for the patch since its not critical to the patch being useful.
> > >> Personally I haven't had the time to figure it out and implement it
> > >> so my original patch didn't include it.
> >
> > > I like the idea of the deferred fields, but if we don't implement it
> > > now, people may come to rely on the AttributeError so that we can't
> > > add deferred later. Perhaps a note in the docs stating our intent to
> > > add deferreds would suffice?
> >
> > No need for workaround docs - I've just uploaded an RC3 patch that
> > implements deferred fields.
> >
> > The one gotcha on this patch is that it now requires that you request
> > the primary key when you retrieve an object. That is, you can't just
> > run::
> >
> > Author.objects.raw('SELECT firstname, lastname FROM author')
> >
> > You must now include the pk:
> >
> > Author.objects.raw('SELECT id, firstname, lastname FROM author')
> >
> > If you don't, you get an exception. Unfortunately, it's an exception
> > after the SQL has been executed, but that's the only way to know
> > exactly which columns have been requested.
> >
> > This is slightly more restrictive than Jacob's RC2 patch - but I think
> > the RC3 behaviour is preferable. The primary key value is a fairly
> > essential part of the Django infrastructure. In RC2, if you retrieved
> > an Author with firstname and lastname, then saved the object, you
> > would get a new object in the database. RC3 avoids this because the
> > deferred object has the right primary key.
> >
> > If the price of avoiding surprises like this is forcing the PK to be
> > retrieved, I think it's a price worth paying. If you really can't
> > afford to have the PK retrieved, then I'd argue you aren't retrieving
> > a Django object; you can still call on raw SQL cursors to accommodate
> > those use cases.
>
> One use case where deferred fields aren't so nice is when creating
> models which don't have any backing tables in the db. That is, models
> with managed = False. These models would be the Django equivalent of
> views. In these cases trying to access the field, even for testing if
> it is None, would result in db query and an exception. And probably in
> aborted transaction, too.
>
> Using raw() as a way to perform view operations (complex joins etc.)
> is the first use case I though of when I saw this. Anyways, using
> default or None as a value isn't good either. How do you know if you
> got that from the DB or not? A nice way to test which fields the model
> were populated and marking the non-populated fields as deferred would
> be optimal in my opinion. One use case where you don't necessary know
> which fields are populated and which ones aren't is when you have
> multiple raw() queries defined populating different fields of the
> model.
>
> Ans
Re: Django's testing infrastructure
A platform we probably should get into the mix is a CentOS/RHEL 5 box. I suspect a significant portion of the community is stuck on such boxes and given the ancient versions of everything available under RHEL I'm sure that there are things which will break there and not in a developer's standard environment. I personally don't have a suitable RHEL box laying around but this seems like a good candidate for either another volunteer or DSF funds. ____ Sean O'Connor http://seanoc.com On Thu, Feb 25, 2010 at 10:54 PM, Eric Holscher wrote: > Hey everyone, > > During the sprints, I worked to set up a hudson instance for Django. This > is hopefully going to be the way that we are going to go forward for now > with doing continuous integration for Django. I have a pretty good setup > going currently, and want make it really fantastic. At this point in time, > what we really need now is some more hardware to be able to run tests on. > > The current setup is hosted at: http://hudson.djangoproject.com/ > > Currently, I have tests running on the following architectures: > > Django trunk: > > Solaris: > Python 2.4-2.5 > Databases: sqlite, postgres, mysql > > Ubuntu: > Python 2.5-2.6 > Databases: sqlite, postgres, mysql > > Django 1.1.X: > > Solaris: > Python 2.5 > Databases: sqlite, postgres > > This gives us pretty good coverage currently, but the whole point of doing > CI is that we catch bugs on other platforms we wouldn't normally run on. > > What we need > === > > So I'm looking for people who can offer other boxes that they would like to > see tested. Currently the big ones we aren't covering are Windows boxes, and > the Oracle backends. There are lots of other permutations that we could be > testing against (Different python runtimes being a good example). > > However, we don't want to get in a situation where boxes that people have > set up just disappear. So, I'm only currently looking for machines that > people would be able to dedicate to the effort. We would require a > django-testing user account on the box, with our SSH key on it. There would > also be a team of trusted users, who would have access to this key and thus > your machine. > > We want the build farm to be stable and useful, and in the past we have had > too much trouble having machines just disappear. > > Requirements > === > > Currently the hudson requirements seem to be about <1GB of disk space, with > 512MB of ram. I'm also looking into some pony build/barn based alternatives > that would knock the memory requirements down pretty substantially. However, > for the current 1.2 release it looks like hudson is how we're going to make > it going forward. > > Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so > another way that we might be able to get this going is to be able to have > donations to the DSF, and have them get some dedicated rackspace boxes. > However, for now, I'm hoping that we can cobble together enough stuff to get > 1.2 tested really well. > > Feedback > == > > If you have any thoughts on CI, or any advice, I would love to hear it. I'm > trying to make our Continuous Integration setup really kick ass, so feedback > is necessary to do this. I have some notes and ideas that I have been > recording while setting things up over at the pycon etherpad: > > http://pyconpads.net/django-testing > > Let me know if you have any thoughts, questions, or concerns. > > Cheers, > Eric > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@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-develop...@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 documentation for newer users
The Django documentation is already included in code base with Django and anybody is welcome to submit patches for them. If you do a checkout of Django, there will be a "docs" directory there. Inside there is the full documentation source in reStructuredText. If you'd like a local HTML or PDF version of the docs you can simply install sphinx[1] on your machine and build the docs like any other sphinx project. If your interested in learning more I'd recommend that you read the "How the Django Documentation Works"[2] page as well as "Contributing to Django"[3]. ____ Sean O'Connor http://seanoc.com [1] http://sphinx.pocoo.org/ <http://sphinx.pocoo.org/>[2] http://docs.djangoproject.com/en/1.1/internals/documentation/#internals-documentation <http://docs.djangoproject.com/en/1.1/internals/documentation/#internals-documentation> [3] http://docs.djangoproject.com/en/1.1/internals/contributing/#internals-contributing On Fri, Mar 5, 2010 at 11:35 AM, stherrien wrote: > What I'm suggesting is that we setup something to allow everyone to > improve the docs with help from the core django group. I think this > would be very helpful to everyone. if one of the core group would like > to help us get setup to do this it would be great. maybe if they setup > a repository with the current online docs online so we can add updates > as we do with django itself. > > On Mar 5, 11:20 am, stherrien wrote: > > Exactly my point docs need to be more organization to be constructive > > for django users. > > > > On Mar 5, 11:05 am, Jared Forsyth wrote: > > > > > To be honest I am quicker to just go to django's source code rather > than the > > > docs, as often I can find what I need there, and the docs aren't (imo) > > > organized enough to provide much of an advantage. > > > > > On Fri, Mar 5, 2010 at 8:46 AM, stherrien > wrote: > > > > Hi all, > > > > > > I have a request that django documentation show the import locations > > > > for classes like in other well formed docs found on the web showing > > > > the users where the classes can be found for import. I think this > > > > would be handy for newer users and experienced users finding > something > > > > new. Documentation on the site is different from page to page. Take > > > > for instance the file object doc page in django doesn't tell the user > > > > where this can be imported which requires you to dig into the python > > > > help pages to try and find it. which is "from django.core.files.base > > > > import File". it would be nice to show this consistently across the > > > > site. I would be happy to help make this happen. > > > > > > -shawn > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups > > > > "Django developers" group. > > > > To post to this group, send email to > django-develop...@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-develop...@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-develop...@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: Process discussion: reboot
The DVCS conversation has been had many times over the last year or two on this list and in other places. I mention this not to say that you should know already as it isn't clearly documented, but as a suggestion that you should make sure that you are bringing something new and concrete to the discussion before starting it again. The current view of the core team is that the combination of a central, authoritative, Subversion server with semi-official mirrors for Git, Mercurial, and Bazaar is sufficient for the foreseeable future. All of the benefits of the distributed systems are available via the mirrors and there's no disruption to users who are used to the current workflow/infrastructure. If you would like to make a contribution to Django, you can work with whichever of the three most common DVCSs and there will be several core devs able to accept your changes without any problems. ____ Sean O'Connor http://seanoc.com P.S. I am not a core dev so any of the core devs should feel free to correct me on this. That being said this view has been clearly expressed several times on this list and in other venues. On Mon, Apr 19, 2010 at 8:35 PM, Jerome Leclanche wrote: > If you contribute to open source projects, at one point you'll be > faced with the forced choice to use git. It is extremely popular (I > believe it's the most popular after svn), and unlike svn it's popular > for a good reason. > However, hg is decent as well; whatever the django team chooses, as > long as it's not cvs it can't really be worse than svn. > > (bzr fan, personally, but I'd prefer it if django moved over to git) > > J. Leclanche / Adys > > > > On Tue, Apr 20, 2010 at 2:58 AM, VernonCole wrote: > > Not to start a flame war --- but PLEASE! don't use git. I already > > have to use the other two leading DVCS's and all three are one too > > many. > > I personally prefer bazaar, but python itself and pywin32 are both > > committed to mercurial. I suspect that hg would be a better choice > > for most people. > > -- > > Vernon Cole > > > > On Apr 19, 10:05 am, Dennis Kaarsemaker > > wrote: > >> On ma, 2010-04-19 at 15:47 +, Peter Landry wrote: > >> > >> > >> > >> > >> > >> > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" wrote: > >> > >> > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry > wrote: > >> > >> One suggestion that jumped out at me (which I admittedly know very > little > >> > >> history about with regards to Django or other projects) was the > "trunk > >> > >> ready" branch(es) [1]. Perhaps an effort to outline what that > process might > >> > >> entail in detail, to determine if it would address any concerns? > >> > >> > > FTR, I think this is a fine idea, and I think most (all?) of the > other > >> > > Django core developers do, too. It's just waiting on someone to Just > >> > > Do It. > >> > >> > > Anyone -- preferably a group -- who wants to start such a branch > could > >> > > go ahead and start one using the DVCS tool of their choice (Django > has > >> > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me > and > >> > > I'll start watching it; show some continued motion and I'll spend > some > >> > > time getting a buildbot going against the branch; show high quality > >> > > and I'll start pulling from it more and more frequently; show > >> > > incredibly quality and I'll suggest that the maintainer(s) get > commit. > >> > >> > >> For my part, I see that it could be helpful to let some > patches/ideas get a > >> > >> shot at integration without having to endure the (necessarily) more > rigorous > >> > >> core commit trails. > >> > >> > > Quality is important, and if this branch is created it needs to > >> > > maintain that quality. If this hypothetical branch is low-quality > it's > >> > > just a different tool for a queue of un-reviewed patches, and I've > >> > > already got one of those. I'm not willing to compromise on quality: > if > >> > > patches don't meet our standards, they don't go in. > >> > >> > > Jacob > >> > >> > I fully agree regarding quality, my point being that this branch > itself may > >> > not be "trunk ready" at any given time, but pat
Re: Feature idea
I've been generally thinking about putting together a package of reusable
tools to implement common "patterns" for reusable apps. Included in this
would be this type of auto-discovery system as well as a registration
pattern. Unfortunately I probably won't get much practical work done on
this too soon due to other obligations.
That being said I'd be very interested to see what initial stabs other
people may take in this direction or what other patterns would make sense
for this type of package. Once a toolset of this nature does exist, I think
it'll be a great asset to reusable apps and even more so to the domain
specific frameworks like imagekit or haystack.
____
Sean O'Connor
http://seanoc.com
On Tue, Jun 1, 2010 at 3:34 PM, Gabriel Hurley wrote:
> I like the idea of boxing up the autodiscover code into a publicly
> accessible utility class... it's a problem many people solve for
> themselves (myself included) but even moreso it would go well with the
> new startup.py proposal that's in the works.
>
> Once it's easy to have things run once at startup, the desire to run
> some sort of autodiscovery mechanism from those startup files is
> likely to take off. And it's not that it's a hard problem for someone
> to solve themselves, but it might be one worth solving once and being
> done with it.
>
> The downside, of course, is the cost of maintaining it and ensuring
> backwards compatibility going forward.
>
> All the best,
>
>- Gabriel
>
> On Jun 1, 12:02 pm, Gregor Müllegger wrote:
> > I also needed this functionality in one of my apps and just went the
> > way of copy and pasting the existing solution that is already
> > implemented in django.contrib.admin. But making this code reuseable
> > would IMO be a benefit for some app developers.
> >
> > But I think the approach of using an setting for this purpose is not
> > the ideal way. Admin does a great job in that way, because it only
> > uses the autodiscover functionality on demand. My need for an
> > autodiscover functionality was directly tight to a management command.
> > I don't want to load these modules unless I invoke the management
> > command, which is possible with the admin like autodiscover() function
> > instead of using a setting.
> >
> > My proposal would go into the direction of pulling the autodiscover
> > function out of the django.contrib.admin module and putting it
> > somewhere in the core. Since the admin needs some special
> > functionality on errors while loading an admin.py module from an app,
> > I would suggest a Autodiscover class that provides some hooks to be
> > better customizable.
> >
> > Something like:
> >
> > class Autodiscover(object):
> > def __init__(self, module_name):
> > self.module_name = module_name
> >
> > def __call__(self):
> > # existing autodiscover code from django.contrib.admin
> >
> > def pre_load(self, app_label):
> > # gets called directly before trying to load an app's module
> >
> > def post_load(self, app_label):
> > # gets called after trying to load an app's module even if
> the
> > # import failed
> >
> > def on_success(self, app_label, module):
> > # gets called if the module was imported successfully
> >
> > def on_error(self, app_label):
> > # gets called if the module didn't exist or import failed
> >
> > In django.contrib.admin or in any other app we can use:
> >
> > from django.core.autodiscover import Autodiscover
> >
> > autodiscover = Autodiscover('admin')
> >
> > This also provides backwards compatibility since the following snippet
> still
> > works:
> >
> > from django.contrib import admin
> >
> > admin.autodiscover()
> >
> > Yours,
> > Gregor Müllegger
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.
DjangoCon US CfP Closes Tomorrow
Hey Everybody, Just a quick heads up that the call for talk and tutorial proposals for DjangoCon US 2012 closes tomorrow. You can find all of the details on this year's conference along with the form to submit a proposal at http://www.djangocon.us/. If you have any questions or feedback please feel free to let me know at s...@seanoc.com. Thanks! -- Sean O'Connor http://www.seanoc.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: jQuery.tmpl() and Django
I think it would be a bit much for us to ask the jQuery crew to change their template language to avoid conflict with ours. Aside from the amount of backwards incompatible work we'd be asking them to do, they'd probably just end up with a new conflict with some other template language. At the end of the day this is also more of a symptom than an underlying problem. Even if we got the jQuery crew to change their syntax, there would still be other JS template languages with the same conflict (e.g. mustache.js). A better approach would for Django to provide some tools and documentation to help people work around the conflict. One easy solution would be to provide a verbatim tag like what ericflo wrote at https://gist.github.com/629508. Another would be to provide documentation on tools that make it easy to load jquery style templates via ajax like icanhaz.js. My vote is that we fix the problem once and for all on our end by providing compatibility tools and guidance instead of trying to tell the entire JS community to not conflict with out template syntax :) -- Sean O'Connor http://www.seanoc.com On Thursday, May 26, 2011 at 11:14 PM, Ori Livneh wrote: > Hello, > > jQuery.tmpl(), a beta feature slated for inclusion in the main jQuery > brach, uses some of the same syntax as Django in its templating > markup, which is a bit of a bummer. I'm writing to see whether you > think we should get in touch with the jQuery team to see if they could > plausibly change it. > > There are, obviously, quite a lot of templating languages out there, > and some of them are bound to clash with Django, and that's not a > problem. But Django and jQuery are often deployed together (jQuery is > actually bundled with Django for use in the admin), making this clash > especially annoying. > > You might think this isn't an issue since JavaScript code should be > served from static files anyway, but there's an added complication. > One of the patterns jQuery.tmpl() recommends is nesting templates > within a
Djangocon US Call for Talks
Hey Everybody, I know we're a bit late this year but the new Djangocon.US<http://djangocon.us/> site is finally up and we are accepting talk proposals today. Unfortunately, thanks to our lateness we will only be able to accept proposals for the next* *two weeks. This means if you want to have a chance to speak at this year's Djangocon, you need to get your proposal in ASAP. You can read more about submitting a proposal at http://djangocon.us/blog/2011/06/22/call-papers/ and feel free to contact me directly if you have any questions or concerns. *Sorry for the cross post of this on both lists, but given the very short timeline that we're working with, we want to make sure everybody knows ASAP. * -Sean O'Connor s...@seanoc.com -- 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/-/YTQUe_ZDth8J. 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.
