Saurabh,

No problem--happy to help.  And I won't ignore your last question.
The server I was referring to was, indeed, a layer of insulation--but
not for Django.  Its purpose is to avoid giving the GUI clients direct
access to the database, by delivering objects back and forth across
the network, while also providing a system of permissions.

Django does all this for you--it handles the database access, and
sends across the network to the client (in this case, a web browser)
only what the client should be allowed to see.  So, if you go with
Django, you don't have to write any such thing.

Hope that helps,
Jeff

On Nov 26, 9:23 am, "Saurabh Agrawal" <[EMAIL PROTECTED]> wrote:
> Hi Jeff,
>
> Thanks again for all the info.
>
> Can I trouble you a little more, for something which in fact, might not be
> Django related at all? You can choose to completely ignore this message, of
> course.
>
> I just want to know what is this server you are talking about? Is that some
> kind of insulation layer between your django app and the database server?
> What exactly is its purpose? If you could direct me to some document, I can
> read that too.
>
> Thanks a ton.
>
> Saurabh.
>
> On Wed, Nov 26, 2008 at 7:39 PM, Jeff FW <[EMAIL PROTECTED]> wrote:
>
> > This sounds, to me, like a great candidate for using Django.  Each of
> > the separate modules you described could be a distinct application
> > within your project.  Actually, you could make it even more granular
> > than that, as a lot of the parts within each module could be separate
> > apps.
>
> > The Django permission system will probably already be able to handle
> > what you need--with no tweaking--and the automatic admin interface
> > might handle almost all of your app's needs.  It looks like you'd want
> > a "public" side for the teacher aspect, but you could still put that
> > behind a login.
>
> > As for the networking--in the case of my app, I didn't want to give
> > each client direct access to the database server.  The server that I
> > wrote is the only thing that connects to the database, and it handles
> > permissions.  You should *never* rely on the client apps to do the
> > "right thing", as you have no real control over them.  You can lock
> > access down to specific users or groups (in postgres), but that can be
> > a very arduous, and doesn't always work for your business logic.
>
> > -Jeff
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to