Web Interface Recommendations

[PurpleServerMonkey]

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?

 

[Graham Dumpleton]

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

 

[PurpleServerMonkey]

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.

 

[Bruno Desthuilliers]

PurpleServerMonkey a écrit :
(snip)

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.

I guess you'll have to try them out to find the one that best match your
needs and personal preferences. Mostly:

- CherryPy is more of a web application server than a framework per-se:
it's it's own HTTP server - which might or not be a good thing -, and
only deals with the "controler" part of the MVC triad.

- Django is by now a mostly mature MVC framework, with more than a
couple years of production use on quite a lot of sites and applications,
good documentation and a somewhat large and active community. OTHO, it's
a very opiniated (and somewhat monolithic) framework, with most parts of
the stack (ORM, forms validation, template system etc) built
specifically for this framework (which was probably the sensible thing
to do by the time), so it's perhaps the less flexible of the three.

- Pylons is IMHO very promising: wsgi from bottom to top, very flexible,
good default components choice (paste / Routes / SQLAlchemy / Mako /
FormEncode) but let you swap what you want in and out, and FWIW I've
seen so far a very sound architecture. FWIW, next Turbogears major
version will switch from CherryPy to Pylons. OTHO, it's still far from
being as mature and documented as Django.

My 2 cents...

 

[PurpleServerMonkey]

PurpleServerMonkey a écrit :
(snip)



I guess you'll have to try them out to find the one that best match your
needs and personal preferences. Mostly:

- CherryPy is more of a web application server than a framework per-se:
it's it's own HTTP server - which might or not be a good thing -, and
only deals with the "controler" part of the MVC triad.

- Django is by now a mostly mature MVC framework, with more than a
couple years of production use on quite a lot of sites and applications,
good documentation and a somewhat large and active community. OTHO, it's
a very opiniated (and somewhat monolithic) framework, with most parts of
the stack (ORM, forms validation, template system etc) built
specifically for this framework (which was probably the sensible thing
to do by the time), so it's perhaps the less flexible of the three.

- Pylons is IMHO very promising: wsgi from bottom to top, very flexible,
good default components choice (paste / Routes / SQLAlchemy / Mako /
FormEncode) but let you swap what you want in and out, and FWIW I've
seen so far a very sound architecture. FWIW, next Turbogears major
version will switch from CherryPy to Pylons. OTHO, it's still far from
being as mature and documented as Django.

My 2 cents...

Thanks Bruno, that's just the sort of info I was after.

After reading more on the subject recently I'll be installing and
testing Pylons and Turbogears first, think it will be a good fit for
the project and if not there's no shortage of other offerings.