How about another solution to expression combination: wrapping query
expressions (the field__exact and friends) optionally in Query()
objects that implement __or__ and __and__ - that way you can do
Query(field__exact=blah)||Query(field__exact=blubb).
I did something like this for my active storage framework (a rather
weird database thingy - don't ask) and it worked quite nice. You would
need to extend the get_list() and friends to check for a parameter that
isinstance(Query) and than "compile" the query expression to SQL.
bye, Georg
I would say: release a 0.9 version now (or in the near future) and give
a clear roadmap (that's what the trac feature is for ;-) ) of what will
go into 1.0 before release. That way people have some "quite stable
but not 1.0" tarball to play with, with a defined
compatibility-breakage ahead, but one they are warned about. That would
give us a bit more time to do the 1.0 right.
bye, Georg
I also think ajax is is more important than some others think. This is
probably just because there are a lot of other things that truly are
more important.
Ajax is really hot right now and I could see loosing some developers
because it's not as on the forefront of the whole web 2.0 hyped up
junk. Ajax is more about usability than eye candy or at least it should
be. That being said. I know I can use ajax really easy inside of a
django project but will anyone choose another framework based on most
of the other ones having "ajax support".
I think what you guys are going for is wanting developers to think that
your project is stable, relevant, and has a rapidly growing community.
I think you guys have done a great job and I look forward to seeing
this project progress.
for example.. we have a URL field.. it would be nice if the javascript
did the same regex match that the server side did, so that people
wouldn't have to submit it in the first place, or have a calendar pop
up for a date box (it might already.. I hardly use dates)
This kind of thing would be relatively easy to 'plugin' i would
expect, and while not AJAX per se might make for a good first start.
and i agree with what Jacob said as well.
--Ian
Hey folks --
Man, it's fun having such smart and passionate people on this list!
I've been thinking about how Django might leverage DHTML^H^H^H^H^H
AJAX a lot recently, and I think the framework I'll sketch out below
should make a bunch of people happy.
As I see it, there are three layers necessary for doing Django-AJAX:
The first layer will be a package -- django.core.serializers, most
likely -- which exports a set of serializer/unserializer libraries.
These libraries will know how to convert Django objects to and from a
specific format; we should most likely have XML and JSON serializers
at first crack, and XML-RPC and SOAP serializers could be quite useful.
The second layer will be a set of views not unlike the
django.views.generic , except that they'll take and produce data in
one of the formats defined by the serializer and be nicely RESTful
(appropriate use of HTTP verbs and such). So you'll be able to do
something like::
urlpatterns = patterns('',
('^rpc/', include('django.conf.urls.rpc')),
)
and get slick web services for free.
The third layer will be a toolkit that abstracts those views into
Javascript. I'm afraid that picking a Javascript framework is going
to turn into a bikeshed argument, but as long as whatever we choose
can seemlessly hook into the CRUD views, we should be OK. The idea
is that in Javascript I should be able to do::
entries = rpc.get_list ('blogs.entries', {'limit' : 15})
>I've been thinking about how Django might leverage DHTML^H^H^H^H^H
>AJAX a lot recently, and I think the framework I'll sketch out below
>should make a bunch of people happy.
my main gripe with your ideas is that you throw RPC style stuff
(XML-RPC and SOAP) in with the REST stuff. That just doesn't compute -
both are far too different in philosophy and structure to be really
compatible with each other. I think we need two different things for
webservices - support for RPC style APIs and support for REST style
APIs. And both can be mapped into the ideas of Django quite nicely, I
think.
I have written down my ideas in my trac:
https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/wiki/WebservicesForDjango
I first thought about posting it here, but it got longer and longer and
so I thought it's better to put it into one place and only post the
link ;-)
So my main problem is, RPC needs just one view func with registerable
callbacks (and a set of predefined callbacks for models) that sits on
one URI and dispatches on method name, while REST style APIs need a way
to map objects into the url space (so the dispatch is done by the
standard url pattern handling of Django).
Of course everything on that page is just an idea - and it's written
over a short period of time, so it's neither complete nor perfect. It
might even be that some things don't make sense at all (like how the
url space for REST APIs is structured - that's just an idea how
something might look like, as that gives a more concrete thing to talk
about).
bye, Georg
+1
bye, Georg
There was some discussion in IRC today that it would be useful to
collect examples of how people are already using AJAX (with or without
Django) as a starting point for deciding how best to facilitate similar
techniques in the framework. If there's a cowpath to be paved, let's
find it.
Before we get too far into the "which Ajax framework should Django use"
discussion, I think it's important to lay the groundwork first.
It seems to me that the goal of any Ajax support in Django should be to
make it easier to integrate with any Ajax framework. If there is a
default Ajax framework coupled with Django (it may just be a matter of
which one is bundled and documented) it should be at least as easy to
use another framework (or frameworks) as it is to use other template
systems. Loose coupling, sensible defaults, etc.
So the real productive question at this stage isn't "which Ajax
framework", it's "how can Django make Ajax easier for app developers."
At that point, what framework you use or whether you roll your own is
up to you.
http://code.djangoproject.com/wiki/AJAX
Please commence filling in the blanks and correcting my errors and
misrepresentations :)