Is there an obvious way to do this in python?

Nick Vatamaniuc vatamane at gmail.com
Thu Aug 3 07:01:27 EDT 2006


HJ,

As far as GUI language/library goes:

Some people suggested HTML,  but I think HTML is a very awkward way to
create a good looking dynamic GUI that is _both_ easy to use and fast
and easy to design (which is what you would want probably). Just to
have a nice user editable table for example, you would have to jump
through hoops (using Javascript, DOM, CSS etc), while you could do it
much easier with PyGTK and wxPython, especially if you use a gui
designer like Glade or wxGlade. Even Tkinter beats HTML as far as
building GUIs in Python goes. I believe this might change in the future
with the adaption of SVG but that will take a while... That said, if
your interface can "get by" with just buttons, text boxes, and text
areas HTML will be  the best choice.


As far as "updating-on-the-fly" goes:

For the client to get the code on the fly you will have to implement
some sort of a downloader in the first place that when the user logs
in, it downloads the GUI code from the server and runs it. So if you
update the code the day before the next day they will get a different
interface, or if a new user/machine type is created you just have the
new code ready on the server and it will automatically be downloaded
and run, is that right?

Here is then how I see your use case:
1) You would define your business rules in your database, you will have
usernames, user types, access rights, data tables, columns types,
relations, views, etc...
2) Then each user type will have a specific interface GUI code kept on
the server (perhaps as a zipped binary GUI.zip in a database column
called ClientSpecificGUI).
3) The client starts your Application.py which is the same across all
clients. They will enter their username/password. The Application.py
then sends those to the server to log into the DB.
4) After successful login, the  Application.py performs a SELECT query
to download the zipped GUI.py file.
5) GUI.py is unzipped and executed to start the GUI. The Application.py
code will pass the DB connection object to the GUI.py, so the GUI can
continue to talk with the database. GUI.py runs and does its magic, in
the meantime Application.py waits for GUI.py to finished and then both
exit.

Is that what you had in mind?

NOTE: This means that the client will need to have all the required
libraries at just the right versions. Imagine that your user decides to
upgrade to Python 3000 because it sounds cooler than plain old Python
2.4 ;) , but then they won't realize that it will break your code and
they might not be able to run your application anymore. So you would
have to know at least roughly how much control over the whole client
machine you will have. Will they all be regular desktops that users
will use day to day and then once in a while launch your application
then close it, or will these all be dedicated terminals like an  ATM?
The two are very different. You can assume complete control of all the
OS environment in a dedicated terminal but not in the case of a user
desktop.

Hope this helps,
Nick Vatamaniuc


H J van Rooyen wrote:
> "Bruno Desthuilliers" <bdesth.quelquechose at free.quelquepart.fr> wrote:
>
>
> |H J van Rooyen a écrit :
> |> Hi,
> |>
> |> I want to write a small system that is transaction based.
> |>
> |> I want to split the GUI front end data entry away from the file handling and
> |> record keeping.
> |>
> |> Now it seems almost trivially easy using the sockets module to communicate
> |> between machines on the same LAN, so that I want to do the record keeping on
> one
> |> machine.
> |>
> |> I want to keep the "server" machine as simple as possible - just doing record
> |> keeping on a stimulus response basis - I would prefer it to do one thing at a
> |> time to completion because this style of operation, though limited in
> |> performance, keeps a lot of hassles out of life - a transaction has either
> |> completed, or it has not - recovery scenarios are relatively easy...
> |
> |IOW, you want a SQL DBMS. May I recommand PostgreSQL ?
> |
>
> Looks like the way to go - after the argy bargy here in another thread seems
> mySQL has no supporters left...
>
> |> Up to this point, I don't have a problem - my toy system can create a dummy
> |> transaction, and I can echo it from the "server" machine, with more than one
> |> "user" machine running - so I think it is feasible to have several tens of
> "data
> |> entry terminal" systems running, served by one not very strong machine.
> |>
> |> Now what I would really like to do is to differentiate between the 'User"
> |> machines, so that some can do a full range of transactions, and others a
> limited
> |> range.
> |
> |Any decent SQL DBMS is able to handle this. It's kind of builtin...
>
> Yes - if you do the whole job on the server - the architecture I have mind is
> more like a banking terminal scenario - please see my reply to Simon
>
> |
> |> And I would like to make this flexible, so that it becomes easy to introduce
> new
> |> transactions, without having to run around updating the code in all the user
> |> machines, with the concomitant version number hassles.
> |
> |Then you want a web front end.
>
> This seems to me to assume that the server does all the work
>
> |
> |> And I would like to do the whole thing in python
> |
> |You'll at least need bits of SQL (but SQLAlchemy may hide away most of
> |it) and HTML (but there are some python packages that knows how to build
> |HTML from declarative Python code).
> |
>
> that is good news - which packages?
>
> |> - so my question is this - is
> |> it possible to do the equivalent of dynamic linking? - i.e. if I keep a list
> of
> |> what a user is allowed to do
> |
> |In SQL : GRANT/REVOKE
>
> again - centric thinking - I really would like to change the bits on the client,
> as I explained to Simon
>
> |
> |> - can I somehow send him just the bits he needs to
> |> do the job, without having to change the static code on his machine?
> |
> |HTTP/HTML.
> |
>
> everybody says this - I am being dragged, kicking and screaming...
>
> |> - it seems
> |> to me that the eval() thingy could possibly do this for me,
> |
> |Err... I thought you wanted a reasonnably secure system, but I may have
> |misunderstood.
> |
>
> this is the guts of what I want - if eval is NFG then how do I implement such a
> kind of "dynamic linking" of modules on the client?
>
> |> by sending it data
> |> that makes it do import statements followed by calls to whatever... - will
> this
> |> work, or is there a better way?
> |>
> |> Or has all this been done already?
> |
> |Yes, it's called a web frontend for a SQL DBMS. There's no shortage of
> |Python frameworks to do this kind of things.
> |
>
> I kind of wanted to avoid the web based stuff - the application data is so small
> and trivial, in a sense.
>
> |> - and no I don't want a web server
> |
> |If you don't want Apache, there are Python-based application servers.
> |CherryPy comes to mind.
> |
> |> and php
> |
> |Why PHP ?
> |
>
> seems popular
>
> |> and browsers and Java
> |
> |Why Java ?
> |
>
> it addresses what I want - to dynamically and securely download bits of code and
> execute them on the remote machine...
>
> |> and html or xml... - I want to write something that works
> |> simply and reliably
> |
> |We do write SQL-based web apps all day long, and I can tell you they are
> |certainly more simple and reliable than whatever eval()-based home-made
> |solution we could imagine !-)
>
> Aah! but I would like you to stretch that imagination - to tell me how to do
> some of what Java was designed to do, but better and easier, because this is
> python we are talking about...
>
> I saw something in another thread here - they were talking about weave - can I
> use that if eval is nfg?
>
> If my original post was unclear I am sorry - the point I want answered, if
> possible, is how to make the client code effectively updateable on the fly -
> because the answer to this will influence the whole design of the rest of the
> system...
> 
> - Hendrik




More information about the Python-list mailing list