Web Interface Recommendations

[PurpleServerMonkey]

On Jan 30, 12:55 pm, Graham Dumpleton <Graham.Dumple... at gmail.com>
wrote:
> 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

Thanks Graham, decoupling the user interface and backend logic makes
sense and definitely the way I want to go.

Out of the major frameworks is there one that stands out as being
particularly well suited for what I'm trying to do?

Django and CherryPy are on the short list so I'll give them a detailed
look although Pylons does sound rather interesting as well.