Django for in-house data

58 views
Skip to first unread message

giuliano....@gmail.com

unread,
Dec 8, 2013, 5:15:44 AM12/8/13
to django...@googlegroups.com
 
Hello,
 
I'm using Django to have people in my company access our database. Since the application is not meant for public use, I was wondering how to best struture it.
The admin framework seems to be well suited for manipulating tables via web, while views (in my understanding) seem better for presenting contents with limited database manipulation.
 
Since my app is not meant for public use, I'm wondering if it's worth the effort to build views to mimic most of the admin features (are there shortcuts?)
On the other hand, I'm not very happy to give everyone in my company admin access simply to use the already built web interface.
 
Any suggestions?
 
Thanks.
Giuliano.
 
 

Mike Dewhirst

unread,
Dec 8, 2013, 4:06:20 PM12/8/13
to django...@googlegroups.com
I would go with the Admin interface and a sample of the database as a
prototype for user feedback. It will be much faster than building a
fully feathered application.

You can decide later if you want to stop there and rely on the admin or
press on and build your own user interface.

Mike

> Thanks.
> Giuliano.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/1ab0c4ce-7e52-4764-bb7b-d653f0bef474%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Lachlan Musicman

unread,
Dec 8, 2013, 4:14:36 PM12/8/13
to django...@googlegroups.com
To be fair, I think the best measure is the technical literacy of your
users. The Admin interface is powerful, but they could also
accidentally screw everything up.

Views (can) remove that opportunity

L.
> https://groups.google.com/d/msgid/django-users/52A4DF4C.1070209%40dewhirst.com.au.
>
> For more options, visit https://groups.google.com/groups/opt_out.



--
From this perspective it is natural that anarchism be marked by
spontaneity, differentiation, and experimentation that it be marked by
an expressed affinity with chaos, if chaos is understood to be what
lies outside or beyond the dominant game or system. Because of the
resistance to definition and categorisation, the anarchist principle
has been variously interpreted as, rather than an articulated
position, “a moral attitude, an emotional climate, or even a mood”.
This mood hangs in dramatic tension between utopian hope or dystopian
nihilism...
-----
http://zuihitsu.org/godspeed-you-black-emperor-and-the-politics-of-chaos

llanitedave

unread,
Dec 9, 2013, 12:07:54 AM12/9/13
to django...@googlegroups.com
It wasn't in Django, but I previously developed a very large and complex database and gave administrative access to just a few too many people.  They had the best of intentions -- no sabotage involved, but they still managed to screw up the records royally.

Lesson learned -- NEVER give blanket administrative access on a database!

Mike Dewhirst

unread,
Dec 9, 2013, 3:17:57 AM12/9/13
to django...@googlegroups.com
On 9/12/2013 8:14am, Lachlan Musicman wrote:
> To be fair, I think the best measure is the technical literacy of your
> users. The Admin interface is powerful, but they could also
> accidentally screw everything up.

I agree that the Admin is not for general use. What I was thinking about
was the speed of getting it up and getting feedback for building what
might be required/desired. In other words, an interim prototype.

Your point about technical literacy bears thinking about. Wouldn't you
say all users can screw things up whether they are technically literate
or not?

Maybe group permissions in the admin can deliver read-only access to the
data? Perhaps a small number of technically literate users can be given
r/w permission for a restricted number of tables?

Doing that might or might not fit the scenario but it is worth considering.

Mike

Lachlan Musicman

unread,
Dec 9, 2013, 4:01:59 AM12/9/13
to django...@googlegroups.com
On 9 December 2013 19:17, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
> On 9/12/2013 8:14am, Lachlan Musicman wrote:
>>
>> To be fair, I think the best measure is the technical literacy of your
>> users. The Admin interface is powerful, but they could also
>> accidentally screw everything up.
>
>
> Your point about technical literacy bears thinking about. Wouldn't you say
> all users can screw things up whether they are technically literate or not?

Of course - I've even done it myself. But some users are more likely
to than others. More importantly, they are usually less able to
articulate exactly what it was they did to enact the data loss.



Cheers
L.

Robin

unread,
Dec 9, 2013, 6:17:05 AM12/9/13
to django...@googlegroups.com
You haven't said what DB product you are connecting to.

However, why don't you use a tool that is designed to allow end users as
well as syrems folk to interact with data - check out Pentaho - BI and
DI applications and dashboards, reports etc. There is an open source
version. You can implement security, if required.

Letting end users directly access the DB is quite wrong, especially if
the DB is complex. In the latter case, many of the reports created will
be wrong, and decisions will be made on misleading data.

Robin St.Clair

giuliano....@gmail.com

unread,
Dec 9, 2013, 8:23:08 AM12/9/13
to django...@googlegroups.com
 
the database is built from scratch, so I can use whatever I wish. Currently I'm performing some tests with SQLite, but plan to migrate to MySQL for production.
 
The project is building a basic CRM with a few tweaks for managing specific business types.
 
I'm new to Django and Web frameworks in general, but have decent experience in Python.
 
What I'm trying to understand now is it's possible with little effort to build views which mostly behave as the admin interface would, doing some customization on specific points where needed.
 
For example, the paged views offered by the admin interface is something I would prefer not to code from scratch in the views.
But I've not finished to read the whole documentation yet, so it's possible that I'm simply asking trivial questions (sorry). 
 
 
Giuliano.

Mike Dewhirst

unread,
Dec 9, 2013, 4:04:32 PM12/9/13
to django...@googlegroups.com
On 10/12/2013 12:23am, giuliano....@gmail.com wrote:
> the database is built from scratch, so I can use whatever I wish.
> Currently I'm performing some tests with SQLite, but plan to migrate to
> MySQL for production.
> The project is building a basic CRM with a few tweaks for managing
> specific business types.
> I'm new to Django and Web frameworks in general, but have decent
> experience in Python.

One of the major benefits of Django is the number of apps available to
save you the (most) of the work of doing it yourself. Look here ...

https://www.djangopackages.com/

> What I'm trying to understand now is it's possible with little effort to
> build views which mostly behave as the admin interface would, doing some
> customization on specific points where needed.
> For example, the paged views offered by the admin interface is something
> I would prefer not to code from scratch in the views.
> But I've not finished to read the whole documentation yet, so it's
> possible that I'm simply asking trivial questions (sorry).
> Giuliano.
>
> On Monday, December 9, 2013 12:17:05 PM UTC+1, Robin St.Clair wrote:
>
> You haven't said what DB product you are connecting to.
>
> However, why don't you use a tool that is designed to allow end
> users as
> well as syrems folk to interact with data - check out Pentaho - BI and
> DI applications and dashboards, reports etc. There is an open source
> version. You can implement security, if required.
>
> Letting end users directly access the DB is quite wrong, especially if
> the DB is complex. In the latter case, many of the reports created will
> be wrong, and decisions will be made on misleading data.
>
> Robin St.Clair
>
>
> On 09/12/2013 09:01, Lachlan Musicman wrote:
> > On 9 December 2013 19:17, Mike Dewhirst <mi...@dewhirst.com.au
> <javascript:>> wrote:
> >> On 9/12/2013 8:14am, Lachlan Musicman wrote:
> >>> To be fair, I think the best measure is the technical literacy
> of your
> >>> users. The Admin interface is powerful, but they could also
> >>> accidentally screw everything up.
> >>
> >> Your point about technical literacy bears thinking about.
> Wouldn't you say
> >> all users can screw things up whether they are technically
> literate or not?
> > Of course - I've even done it myself. But some users are more likely
> > to than others. More importantly, they are usually less able to
> > articulate exactly what it was they did to enact the data loss.
> >
> >
> >
> > Cheers
> > L.
> >
> >
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/d2e08f16-0a92-4c40-a398-c5ea7fac9dce%40googlegroups.com.

Lachlan Musicman

unread,
Dec 9, 2013, 8:24:06 PM12/9/13
to django...@googlegroups.com
On 10 December 2013 00:23, <giuliano....@gmail.com> wrote:
> What I'm trying to understand now is it's possible with little effort to
> build views which mostly behave as the admin interface would, doing some
> customization on specific points where needed.
>
> For example, the paged views offered by the admin interface is something I
> would prefer not to code from scratch in the views.


You are looking for "Class Based Views". No more effort than setting
up the admin but without the deep power at an early stage.

You build the models and CBVs abstract away most of the heavy lifting

see
https://docs.djangoproject.com/en/dev/topics/class-based-views/
http://ccbv.co.uk/
Reply all
Reply to author
Forward
0 new messages