Web Interface Recommendations

Graham Dumpleton Graham.Dumpleton at gmail.com
Wed Jan 30 02:55:27 CET 2008


On Jan 30, 12:00 pm, PurpleServerMonkey <PurpleServerMon... at gmail.com>
wrote:
> Looking for suggestions on the best framework to use for an
> applications web interface.
>
> The user interface doesn't need immediate feedback and will be cross
> platform so a web interface is a good solution especially since it
> operates as a client\server system and not standalone.
>
> However there's just so many frameworks to choose from it's very
> confusing. After a lot of reading it sounds like OSE or Cherrypy might
> be good options but I don't have any real world experience with these
> frameworks to go by.
>
> Basically the interface won't be the application, it's used to input
> data and have the application act on it. It's going to have a
> Postgresql database and a number of service\daemon processes that do
> the actual work. It will also contain some form based information for
> keeping track of requests etc. and grow to a fair number of screens
> over time.
>
> Given the above what framework would you recommend?

Surprised you even looked at OSE. Although OSE has some features for
building HTML based web interfaces, they are very basic and not really
intended for building major stuff. OSE can still be useful for writing
backend applications, but would very much suggest you use just the XML-
RPC interfaces it provides to talk into its distributed messaging
system and service agent framework.

If you use the XML-RPC interfaces then you can use a proper web
application framework for doing the actual HTML based user interface
front end. At that point you can choose any of the major frameworks,
such as Django, Pylons, TurboGears, CherryPy or web.py.

Splitting the front end from the backend like this also means that
backend itself could be swapped out. Thus, instead of using OSE in the
backend, you could use simpler XML-RPC enabled Python applications, or
even use Pyro. In other words, you avoid intertwining code for front
end and backend too much, thus perhaps making it easier to change and
adapt as it grows.

Graham



More information about the Python-list mailing list