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 locations on maps. Data "extraction" - reporting and querying - has had to be written as well. These are included as "seamless" parts of an overall customised Admin interface: primarily because the people doing the data entry are the same ones who are extracting data from it. I appreciate that in business scenarios you may have a worker/manager split and need quite different interfaces for each group.
On 3 November 2010 06:33, Carlos Daniel Ruvalcaba Valenzuela < clsdan...@gmail.com> wrote: > 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 routing or pinpointing locations. > > What kind of applications/situations do you find more suited for > reusing the admin module? > > Regards, > Carlos Ruvalcaba > > On Tue, Nov 2, 2010 at 12:12 PM, derek <gamesb...@gmail.com> wrote: > > 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 edge-cases that you will need your own > > interface. This might be your situation...? > > > > On Oct 29, 11:16 pm, Carlos Daniel Ruvalcaba Valenzuela > > <clsdan...@gmail.com> wrote: > >> 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 for certain tasks (such as adding data like > >> inventory part numbers) that are not your daily use case o central > >> functionality. > >> > >> Regards, > >> Carlos Daniel Ruvalcaba > >> > >> > >> > >> > >> > >> > >> > >> On Fri, Oct 29, 2010 at 1:55 PM, Frank Wiles <fr...@wiles.org> wrote: > >> > On Fri, Oct 29, 2010 at 3:13 AM, Alex Kreimer <alex.krei...@gmail.com> > 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 office managers that control the organization). > >> > >> >> 1 Would django admin be suitable for all the update tasks (it looks > >> >> like admin would be seriously tweaked for this) or should a separate > >> >> interface be built? > >> > >> >> 2 Is there a ready piece of code that could be used as a stub for > such > >> >> a task? > >> > >> > While you could definitely shoe horn this into the admin with a bunch > >> > of customizations, you're likely better off just writing your own > >> > interface for these tasks. My general rule of thumb is if the end user > >> > isn't "techie" or they will be using the interface many times per day > >> > I don't use the admin. > >> > >> > Don't get me wrong, the admin is great, but it isn't ideal for many > >> > repetitive tasks. > >> > >> > -- > >> > Frank Wiles > >> > Revolution Systems |http://www.revsys.com/ > >> > fr...@revsys.com | (800) 647-6298 > >> > >> > -- > >> > 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<django-users%2bunsubscr...@googlegroups.com> > . > >> > For more options, visit this group athttp:// > 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<django-users%2bunsubscr...@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<django-users%2bunsubscr...@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.
