My applications are in the science domain, where data entry is quite
intensive. Aspects such as AJAX and dynamic lookups have been incorporated
into the standard Admin. Obviously there is additional functionality that
had to be added; e.g. adding data via uploads from spreadsheets, and point
loca
Probably so, we do have stuff that tends to be JavaScript intensive at
times, in some places we have a few AJAX queries (for example
selecting a warehouse and loading the relevant part numbers for the
next field based on the client) that may not be necessary, to stuff
like Maps with OpenLayers for
And my thoughts are echoed in this parallel thread I just came across:
http://groups.google.com/group/django-users/browse_thread/thread/935d64cb03730b73
On Nov 2, 9:12 pm, derek wrote:
> I always had the opposite impression. The Admin can be modified quite
> extensively to handle most cases for r
I always had the opposite impression. The Admin can be modified quite
extensively to handle most cases for regular, on-going, data entry for
multiple models. This means you have consistency and built-in
cohesiveness (less chance for errors because you are using existing
code). Its for specialised
I have always had the notion that the admin interface is more about
adding data to the system quickly rather than being the system itself,
the admin interface is very powerful indeed, but I think you may have
better customization/simplification options on your own and reserve
the admin interface fo
On Fri, Oct 29, 2010 at 3:13 AM, Alex Kreimer wrote:
> Hi All,
>
> I'm building an app for small retail chain management. It requires
> inventory/salespeople/wages etc. management. There 2 kinds of users:
> updaters (non-tech managers that are responsible sales locations) and
> viewers (main off
6 matches
Mail list logo
