Re: Do any financial firms use a Django framework?

[Jason Beaudoin]

On Tue, May 3, 2011 at 10:53 AM, rpt...@reportlab.com
 wrote:
> Does anyone know of any financial firms which use a Django framework?

Yep. I build advanced payment services for a prominent, offshore
payment service provider, using django, python and nginx/uwsgi at the
core.

~JB

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

Re: Model inheritance and simple access

[Jason Beaudoin]

sounds like magic, though django usually handles magic well :)


On Tue, Jun 8, 2010 at 7:18 PM, John M  wrote:
> I was hoping to avoid that type of code, but instead have put a field
> in the linked parent to indicate what type the child is and then have
> a method in the parent as a property which returns the correct child
> type.  Works for now, would be nice if the framework kept track of it,
> but it's a rare case.
>
> J
>
> On Jun 8, 12:41 pm, Dan Harris  wrote:
>> Not sure if this will work as I don't usually do much with model
>> inheritance but according to docs 
>> at:http://docs.djangoproject.com/en/dev/topics/db/models/#id7
>> this might work (not pretty, but somewhat minimal code)...
>>
>> p = Parent1.objects.get(id=1)
>> try:
>>    p.childa.basemthod()
>> except:
>>    try:
>>       p.childb.basemethod()
>>    except:
>>       raise Execption("not ChildA or ChildB")
>>
>> Django adds in the lower cased name of the class as a property when
>> you query the super class and throws an exception if you access a
>> property that isn't there. So something like the above "might" work.
>> And obviously if you have like 5 child classes, this gets ugly very
>> quickly.
>>
>> Dan Harris
>> dih0...@gmail.com
>>
>> On Jun 8, 3:27 pm, John M  wrote:
>>
>> > Hmm, that doesn't really get me what I want, it just caches the
>> > related child objects in one SQL query.
>>
>> > What I want is a single interface and have django figure out what type
>> > of child object I have (like multiple inheritance but 'better').
>>
>> > So in my example:
>>
>> > p = Parent1.objects.get(id=1)
>> > p.child.basemethod()
>>
>> > django would know what p.child is (either ChildA or ChildB) and I
>> > wouldn't need to know.
>>
>> > Is that available?
>>
>> > J
>>
>> > On Jun 8, 11:09 am, Dejan Noveski  wrote:
>>
>> > >http://docs.djangoproject.com/en/dev/ref/models/querysets/#id4
>>
>> > > select_related()
>>
>> > > On Tue, Jun 8, 2010 at 8:05 PM, John M  wrote:
>> > > > I've gotten model inheritance working just fine, but was hoping
>> > > > someone could confirm the best way to access the model.
>>
>> > > > When I have a Base model which has a ForeignKey to a parent table, and
>> > > > that base model has inherited models after it, how can I refer to only
>> > > > one name when referencing the parent model.
>>
>> > > > As an example:
>>
>> > > > class Base(models.Model):
>> > > >    parent = models.ForeignKey(Model1)
>>
>> > > >    class Meta:
>> > > >        abstract = True
>>
>> > > >    def basemethod():
>> > > >      print "hello"
>>
>> > > > class ChildA(Base):
>> > > >    pass
>>
>> > > > class ChildB(Base):
>> > > >    pass
>>
>> > > > p1 = Model1()
>> > > > p1.save
>> > > > x = ChildA()
>> > > > x.parent = P1
>> > > > x.save()
>>
>> > > > p2 = Model1()
>> > > > p2.save()
>> > > > y = ChildB()
>> > > > y.parent = P1
>> > > > y.save()
>>
>> > > > Now, I want to access the children from the parent, but I don't want
>> > > > to have to know what base class they are, is there a way to do that?
>> > > > Right now I'm using a property which figures it out based on some
>> > > > other fields, but would love to be able to say
>>
>> > > > p = Parent1.objects.get(id=1)
>> > > > p.child.basemethod()
>>
>> > > > Is this possible?
>>
>> > > > Thanks
>>
>> > > > --
>> > > > You received this message because you are subscribed to the Google 
>> > > > Groups
>> > > > "Django users" group.
>> > > > To post to this group, send email to django-us...@googlegroups.com.
>> > > > To unsubscribe from this group, send email to
>> > > > django-users+unsubscr...@googlegroups.com> > > >  groups.com>
>> > > > .
>> > > > For more options, visit this group at
>> > > >http://groups.google.com/group/django-users?hl=en.
>>
>> > > --
>> > > --
>> > > Dejan Noveski
>> > > Web Developer
>> > > dr.m...@gmail.com
>> > > Twitter:http://twitter.com/dekomote|LinkedIn:http://mk.linkedin.com/in/dejannoveski
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>
>

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

Re: design question - forms as meta-data to a model

[Jason Beaudoin]

On Fri, Jun 4, 2010 at 2:42 AM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Fri, Jun 4, 2010 at 12:03 PM, Jason Beaudoin <jasonbeaud...@gmail.com> 
> wrote:
>> Silence usually implies some key piece of documentation was missed, or
>> was this just lost amongst more interesting posts? :)
>
> You've missed two important alternatives:
>  * The people who can answer your question are busy
>  * Nobody can understand your question.
>
> Personally, I fall into both these categories. I'm still trying to dig
> myself out from tasks stemming from DjangoCon; and I really can't work
> out what it is you're trying to do.

You are fantastic :)
My apologies, let me try to clarify:

 - I've got a model that defines "submissions", which are incoming
messages from HTML forms on various websites and are fielded by admins
 - each submission has a bunch of basic information related to the
submission (where, when, etc), as well as the data submitted by the
user (form input field)
 - each form on each website is different, and will be different in the future
 - allowing non-developers the ability to manage these forms would be
really nice, so creating them through a frontend interface (as opposed
to developers hardcoding forms) is a desirable goal
 - the idea is that users would submit information from various source
websites to a central repository via a number of forms all with
different fields and varying in # of fields, field names, etc. the
central repository is a place where everything is reviewed, where
submissions are displayed in a "this is when it came in, from here,
and this is what the user gave us" type of way.


I'm not sure how to save the form information with each submission,
given that each form will be different.. I'm used to defining specific
forms and only accepting specific information.


> So - perhaps if you explain your problem in more detail, you might
> have more luck getting a response.

Indeed, this is sometimes a bit difficult to communicate with clarity.


Regards,

~Jason

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

Re: design question - forms as meta-data to a model

[Jason Beaudoin]

Silence usually implies some key piece of documentation was missed, or
was this just lost amongst more interesting posts? :)


On Tue, Jun 1, 2010 at 9:54 PM, Jason Beaudoin <jasonbeaud...@gmail.com> wrote:
> Hi,
>
> I've a situation where the following functionality is desirable..
>
>  - one central model is used and interacted with by users
>  - forms (multiple on multiple sites, pick a number for each.. 5 or
> 50, doesn't matter) are submitted by anonymous users and associated
> with this central model.. so these forms are sort of meta-data..
>  - it would be nice to be able to define a new form via the admin
> panel and allow this to be picked up more or less dynamically by the
> rest of the application - so once defined, a site could then start
> submitting forms and have them associated with and displayed as part
> of other instances of this model, no other code or (manual) db updates
> would really be necessary
>
> I'm an intermediate django user, and are pretty well-rooted in various
> aspects of django development, though I haven't really wrapped my head
> around the best way to implement these forms, the model, and the
> connection between the two.
>
> Thoughts?
>
>
> thanks!
>
> ~Jason
>

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

design question - forms as meta-data to a model

[Jason Beaudoin]

Hi,

I've a situation where the following functionality is desirable..

 - one central model is used and interacted with by users
 - forms (multiple on multiple sites, pick a number for each.. 5 or
50, doesn't matter) are submitted by anonymous users and associated
with this central model.. so these forms are sort of meta-data..
 - it would be nice to be able to define a new form via the admin
panel and allow this to be picked up more or less dynamically by the
rest of the application - so once defined, a site could then start
submitting forms and have them associated with and displayed as part
of other instances of this model, no other code or (manual) db updates
would really be necessary

I'm an intermediate django user, and are pretty well-rooted in various
aspects of django development, though I haven't really wrapped my head
around the best way to implement these forms, the model, and the
connection between the two.

Thoughts?


thanks!

~Jason

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

Re: Design Question - Extending a model

[Jason Beaudoin]

On Mon, Jan 11, 2010 at 12:00 PM, Igor  wrote:
> Thanks a lot - I didn't know about generic relations, and will
> definitely look at them - right now :).

I start thinking about extending models (and other DRY mode/db
methods) when I see myself repetitively typing out too many fields.

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

Re: how do you get recordcount?

[Jason Beaudoin]

On Mon, Dec 21, 2009 at 9:02 AM, Bobby Roberts  wrote:
>    Looking at this code:
>
>    newsqlcmd="select title,author from booklist"
>    cursor=connection.cursor()
>    cursor.execute (newsqlcmd)
>    tms=cursor.fetchall()  #this is the actual recordset being pushed
> back to the template
>
>
>    how can I get the record count?  I could loop through and
> increment a counter but i know that is inefficient.

will the count() method work?
http://www.djangoproject.com/documentation/models/lookup/

--

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

Re: Interesting code abstraction Challenge

[Jason Beaudoin]

Thanks for the thoughts Preston!


> I think a base class with subclasses is the best approach.
>
> Define as much common behavior as possible, set up defaults for those
> fields needed by your outbound API

Indeed, thanks for the confirmation. I think it's time for experimentation!


> How are you handling the branching lookup of what subclass to use?
> You might name the subclasses in some way that they can be derived
> from the partner URL - or some other way that intelligently selects
> the subclass for you

Incoming requests for processing would have associations with specific
backend partners defined in the database and processed as part of the
request, so the branching will be tied into this.


> I assume you've looked at django-piston

I had not seen it, so thank you for pointing me in this direction!


~Jason

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

Re: Interesting code abstraction Challenge

[Jason Beaudoin]

Anyone else have thoughts on this, with respect to design
considerations, implementing in python versus using some of django's
tools.. ?



On Fri, Oct 23, 2009 at 8:22 AM, Jason Beaudoin <jasonbeaud...@gmail.com> wrote:
> 2009/10/23 kmike <kmik...@googlemail.com>:
>>
>> Maybe you don't have enough information to make an abstraction right
>> now. If so I suggest to actually implement several API's in a dumb
>> way. After that it'll be clear what are the differences and what are
>> the common parts so making a good abstraction will be easier.
>
> I've implemented each of the APIs enough (standalone) to know a lot of
> the differences. Where I'm struggling is envisioning the proper
> abstraction and implementation with python / django code to tie it all
> together.
>
> My current idea is to setup a Request class, then create specific
> subclasses of this, overriding the default methods, writing conversion
> methods, and defining additional fields. But "seeing" the python code
> around this has yet to come.
>
> As I've never really implemented this type of abstraction (and I
> imagine others have), I'm really interested in what has been done /
> known solutions to the general problem / do I have the right idea /
> any source folks can suggest / etc..
>
> Thanks for taking the time to read about my situation!
>
> ~Jason
>

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

Re: Interesting code abstraction Challenge

[Jason Beaudoin]

2009/10/23 kmike :
>
> Maybe you don't have enough information to make an abstraction right
> now. If so I suggest to actually implement several API's in a dumb
> way. After that it'll be clear what are the differences and what are
> the common parts so making a good abstraction will be easier.

I've implemented each of the APIs enough (standalone) to know a lot of
the differences. Where I'm struggling is envisioning the proper
abstraction and implementation with python / django code to tie it all
together.

My current idea is to setup a Request class, then create specific
subclasses of this, overriding the default methods, writing conversion
methods, and defining additional fields. But "seeing" the python code
around this has yet to come.

As I've never really implemented this type of abstraction (and I
imagine others have), I'm really interested in what has been done /
known solutions to the general problem / do I have the right idea /
any source folks can suggest / etc..

Thanks for taking the time to read about my situation!

~Jason

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

Interesting code abstraction Challenge

[Jason Beaudoin]

Why hello there,

I have been thinking over this system design for quite a while now,
and I'm still a bit unsure of the sensible way to properly (and
sufficiently) abstract the system - the django-way, so to speak. I am
very interested in what other folks have to say - maybe I have been
thinking about this too much, maybe I haven't crossed paths with the
techniques you would use, but I imagine that while a little
challenging, this is still a common situation.

Please share your crazy, genius ideas, reading tips, code snippets, etc  : )


Here is the general setup:

Client Servers <---> The Application in Question <---> Partner Applications

The main role of the webapp is to serve as a proxy application to many
other partner web applications - we receive requests from client
servers, work out the processing with one or more of our partner
applications, and return the results to the client server. All data
communication is done via predefined APIs, and each API is different..
we define the API our client servers use to send/receive requests to
us, we follow the APIs as defined by our partners to communicate with
their applications. In this way, our client servers are connected to
many similar applications through our one webapp.


Several baseline "rules", if you will:

 - The application receives specially formatted requests for
processing (via POSTs).
 - As stated, all requests are formatted as defined by our, or our
partner, APIs.
 - All incoming requests will need to be re-formatted before passing
on, as each API is different.
 - Some communication is handled via passing XML around, others aren't.
 - A few situations require additional user interaction


The Challenge, or Where I'm caught up:

The end points are easy, as the APIs need to be followed.
Re-formatting a request from our API to a partner's - and vice versa -
isn't really a problem either.. (if I wanted to do this the crappy
way, this could be written out for each conversion, but there are 10 -
20 conversions). The challenge I am trying to figure out is how to
abstract the re-formatting process to eliminate code duplication, as
our API and each partner API will be similar (in an abstract way).

What's difficult is that each API is different enough that it isn't a
straight up a --> b field name translation, the conversion mechanism
has to be pretty dynamic. To put specifics on it, differing field
names are one thing, but the APIs differ in the information they
require (field types, so to speak) - for example: additional fields
for some APIs, or a field in one API may be a combination of others in
another API, etc.


What I have in mind so far:

 - For each partner, define the list of fields required
 - Define translations for each field, with 3 parts: our field name
(or data source), the partner's field name, and a translation function
(with the appropriate conversion algorithm if necessary).
 - When a partner has a field that doesn't have an equivalent in our
system, define a function for generating the field's value.
 - Once we've converted the information, format the data as either XML
or ready for a URLencode to POST


Questions:

Am I on the right track here?
Should I be thinking about this differently?
How do I tie these translations into a generic process, with generic
code, leaving the specifics to these translation functions?
How the hell would you set this up? Even if I'm on the right path
here, I'm having difficulty envisioning the python code behind all of
this..


All ideas, feedback, input, comments, etc welcome!!


Regards,

~Jason

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

Re: PostgreSQL or MySQL, What are the +'s and -'s?

[Jason Beaudoin]

>
>
>  @Jason - I think that's the number one reason I'm going to PostgreSQL. I
> don't use everything all the time but I really like to have the widest array
> of query syntax options. MySQL is just too limiting, especially when
> PostgreSQL is available.
>
>
The other issue I have with MySQL is the "flexibility" to choose your own
db/table engine (sorry if that isn't the correct terminology). While some
find this a plus, and indeed, in *some* cases you want this sort of
flexibility as some of the more obscure database environments would benefit
from peculiarities of one engine over another, I don't find this sort of
thing as attractive.

The reasoning is that of simplicity - as an engineer and artist, I put a lot
of value in simplicity of design, implementation, and maintenance. While I
don't have a lot of experience with MySQL, the more I've read about it's
design and this engine "flexibility" the more I've been turned away. In my
mind, it is as analogous to the linux to BSD situation.. on one hand you
have a lot of flexibility (package managers, configuration tools, etc).. but
in reality it turns into a total rat's nest in comparison to the
"smoothness" of BSD.

just my 2 cents..

~Jason

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

Re: PostgreSQL or MySQL, What are the +'s and -'s?

[Jason Beaudoin]

On Fri, Sep 4, 2009 at 4:29 PM, Joshua Russo  wrote:

> I personally don't have any experience with PostgreSQL and I'm generally
> working in a mixed MS and Linux environment. I'm interested to hear peoples
> views on the pluses and minuses of the two different systems. I'm a bit of a
> query geek too. How does that play in? I know in MySQL there are limitations
> on where you can use subqueries. Is that true with PostgreSQL? (Ya I could
> just look that one up but it's just an example.)
>

While I don't have a whole lot of experience with either, the main issue I
have against MySQL is it's adherence (lack, that is) to the SQL standard.
Moving a MySQL dB--> postgreSQL needn't be so messy.

I'm also a bit weary of MySQL having been bought up.


Cheers,

~Jason

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

Re: Restricting database permissions

[Jason Beaudoin]

On Mon, Sep 7, 2009 at 10:09 AM, Thomas Guettler  wrote:

>
> I can speak only for postgres.
>
> We create the database with a special admin-account and
> the owner if the db is the admin-account. Then we grant
> insert, update, delete permissions to the django-db-user.
>
> We have a modified manage.py which let syncdb run with
> the admin-account (interactive password prompt).
>
>
Sounds fantastic! Might you be interested in posting your work?

~ Jason

--
let's end our suffering, and let go of the debts we hold over the heads of
others.
let's rejoin our brethren in the garden of eden, once again living in
paradise.

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

Re: pre-fetch one-to-many and many-to-many relationships

[Jason Beaudoin]

Miriam,

If you do take this to django-developers, please post a link here, at
least.. this would be greatly appreciated. Thanks :)

~Jason

On Mon, Jul 20, 2009 at 7:39 PM, Russell Keith-Magee  wrote:

>
> On Mon, Jul 20, 2009 at 11:21 PM, Miriam wrote:
> >
> > Hi Russ --
> >
> > Thanks for your response. I figured there must have been discussion on
> > this at some point, given that this is a pretty common use case, and
> > one that other ORMs already tackle with varying degrees of success. Is
> > there a ticket on the subject? If so, I'd love to shift the
> > conversation over there and contribute in any way I can. I looked for
> > one, but couldn't find it.
>
> The ticket isn't the right place to have design discussions. If you're
> interested in developing this feature, then a thread on
> django-developers is the next step.
>
> > I am pretty new to Django and Python, since taking a new job and
> > shifting from RoR. I'm not terribly familiar with Django internals,
> > but I do have some (quite possibly naive) answers to your questions,
> > based on some hacks we've implemented in our own project to do pre-
> > fetching.
>
> I'd be interested in hearing those ideas. I've heard people claim that
> this is possible in Rails (also in SQLAlchemy), but I've never had
> enough of an itch to go looking and see if this is true, and if so,
> how they implement it.
>
> > Again, if there is/was a ticket on this, I'd really love to
> > see it, since there's not much point in duplicating old discussions,
> > and it seems like it'd be a more appropriate place keep this
> > discussion anyway.
>
> There is a very old ticket - #2238 - which was marked 'wontfix' at the
> time for the same reasons I mentioned. I'm not aware of much by way of
> old discussions to build on, so feel free to start from scratch.
>
> > Otherwise, I'd be happy to open up the discussion in this thread. I've
> > got a vested interest in seeing this feature implemented, so I'm eager
> > to help in any way I can.
>
> Like I said - if you're keen to try to implement this, the next step
> is a thread on django-developers, in which you describe your proposal.
>
> Yours,
> Russ Magee %-)
>
> >
>

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

Re: IFEQUAL takes two arguments error on Django 0.91

[Jason Beaudoin]

On Wed, Jun 10, 2009 at 5:43 PM, Frank Peterson
wrote:

>
> I'm on Django 0.91 (unfortunately we are stuck with that and cannot
> upgrade).
>

I have a really hard time believe you truly are stuck.
Migration may not be the simplest in the short-run, but certainly sensible
in the long-term. Who wants to use old, broken, incomplete code anyway?

--
401.837.8417
jasonbeaud...@gmail.com

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