Friday, April 29, 2016

Re: Is it good idea to transition from MS Access to a webapp? And if so, is Django a good tool to do it?

Sorry, I miss-clicked post button and so I will reply twice now.

Another important (rather obvious to you I guess) question would be - what is the usual structure of the servers?

What I mean is - I assume we don't want to have the actual DB on the same server as where we host the website.

Is it usually such that Web server is hosted by some hosting company (so they can make sure it's up 24/7) while DB server is on the premises of the company (ie. the one for which I work for) such that data can be retrieved faster? Although I guess that doesn't make too much sense either, as the data has to be retrieved by web-server first in order to be presented to the user...

Overall I'm quite sure that the company I work for would prefer paying some hosting companies to host everything so they don't have to spend money on (potentially) expensive hardware. Is this the standard approach?

I'm a total newbie in this area so would appreciate some help ^_^.


On Friday, April 29, 2016 at 7:33:58 PM UTC+1, Patrik Mjartan wrote:
Thank you very much for the reply!

I went through the tutorial a few days ago and loved it.

One, very important, question that I forgot to ask - one of the biggest advantages on having an actual desktop front-end app is having a direct access to media, such as printers. Hence a simple button click in the app would result in some document getting printed by default printer (or w/e printer is selected by code, not necessarily user). Is it possible to capture such functionality by web-app at all? Printing PDF documents is not a huge problem (users can just download the PDF invoice and print it manually), problem is for example receipts (in case of future expansion to include on-site sales).

If it is not possible to do it directly, I guess it's always possible to make a small stand-alone app that communicates with the server and listens on when it should print certain documents.

On Friday, April 29, 2016 at 7:05:52 PM UTC+1, Fred Stluka wrote:
Patrik,

Yes, Django can be used for that. 

The "ORM" features and the "templates" and "views" of Django
make it very easy to do a "CRUD" app for a users to create/
retrieve/update/delete data in any RDBMS. 

There are some built-in security features like logins, protection
against "CSRF" attacks, etc. 

Django "formsets" make it easy to show multiple rows with a
details panel for the row currently selected.

With a web app, you won't have to re-distribute the front
end.  Just push a new version to the server.

Django's templates and views both support "inheritance",
which should solve your problem of managing multiple
related forms.  And, there are many Open Source custom
widgets for Django and for JavaScript that will give you all
the sub-grouping and tree-views that you need.

Django scales very well to large amounts of data, large
numbers of screens, and large numbers of users.  There
are many performance tuning options, including "caching"
of templates, and of fully-constructed pages, and of DB
data.  Also, lots of other "middleware" for security,
performance, logging, and other "aspects" of the software.

Yes, you can run a Django server locally, behind a "firewall",
or can expose it to the world, securing various parts as
needed.

To make it as secure as possible, I'd put in on a Linux server
that is protected by tools like Logwatch, Fail2ban, and
Tripwire.  See:
- http://bristle.com/Tips/Unix.htm#unix_security
And be sure to redirect all page requests from HTTP to
HTTPS.

I do all of this and more, including processing financial
transactions and supporting "multitenancy", restricting
access by thousands of different users, each to his own data,
plus "attribute based access control" for cases where data is
shared, at the Web site I'm currently working on:
- http://HelpHOPELive.org

Sorry for all the terms and acronyms, but if you're considering
writing such an app, you'll need to be aware of them and they're
all pretty easy to Google.  Feel free to reply with more questions. 

Also, you'll quickly get a feel for Django's power if you go
through the on-line tutorial at:
- https://docs.djangoproject.com/en/dev/intro/

Enjoy!
--Fred

Fred Stluka -- mailt...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
On 4/29/16 12:57 PM, Patrik Mjartan wrote:
Hi,

I work for a very small company that I developed an application for, all using MS Access (it has back-end MS Access db - although this is planned to change to some more robust RDBMS, and a front-end app built in MS Access). Currently this app is used to calculate the exact wages of some employees (sorry, English is not my native language so I don't know how that type of wage is called here, but basically we look at how many products they produced and calculate it based on that. It's not a hourly wage). However, this summer I would like to expand it to do some order management too (ie. each order has specific products that need to be produced... each of those can be produced by our employees and so it's directly linked to the wages).

However, it is very hard to manage everything using MS Access. Basically each time I make any change to FE or BE, I have to re-distribute the FE to all of the front-users. This is not a HUGE problem, the big problem, however, is within the MS Access itself, that is, it's very hard to manage all the forms as they are listed as simple names (ie. you cannot sub-group them efficiently to make a tree-view). Overall I cannot see myself working with MS Access in 5 years time as I can already see the scalability problems after a few months of working with it.

What I thought of, however, is making a website that is only for local use, but is it possible to have the same functionality as a regular front-end app? Is this good idea to begin with? I had a brief look at Django (I'm VERY new to web-dev, but I'm a fast learner I like to think) and I really like it so far. But is it possible to have the same level of functionality MS Access offers? That is, for example a sub-form on a form that gives more details about the current record selected in the main form? Ie. main form consists of overview of 10 recent orders and the lower portion of the main form is a subform that displays some detailed info about a selected order.

How does it stand from security-perspective if the app is changed from local to public? Obviously even on local I'd imagine I'd put a login requirement there, similar to how the admin page has it, but how safe is it regardless if put to public? Are there pre-determined measures that if taken, it will be 100% secure? As you'd imagine I wouldn't be very happy if someone deleted all of our inventory records because they could bypass the logging system.

Is there any good literature I can read up on doing some similar exercises/examples? For instance: orders/inventory management web app?

Thanks a lot in advance!
--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/fdee3fe0-6f3e-4d5b-862c-3a875b04035b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/af709945-ddab-4e9b-97bb-ffc6d36f34dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment