[portland] Comparing frameworks

[kirby urner]

I really appreciated these well-designed presentations and learned a
lot, was on a tight schedule, blogged about it here:
http://controlroom.blogspot.com/2008/06/ppug-2008610.html (very "my
point of view" -- not Oregonian nor even WW style journalism).

As a database guy, I'm interested in what I see as a trend on the
storage side, which is away from RDBMS, but not in the sense of
superseding, more in the sense of nudging aside a little to make room
for direct object storage with its own API, serialization behind the
scenes.  In Python world, Zope is a trailblazer, also Durus on top of
which you get such as Patrick's Schevo (Patrick who worked with Robin
Dunn on PyCrust and those (wxWidgets)). http://schevo.org/   Empty
stub (not by me): http://code.google.com/p/django-durus/

I'm also just looking at MVC as a paradigm (we heard how it "sort of"
fits with Django), see M as storage of state with theoretical
underpinnings, rules about how state might change ("business rules" in
some paradigms), V as including all these template / boilerplate
libraries, and C (Controller) being that which gives the user or
client some kind of driver seat or otherwise keeps users in the loop
(userspace API, like TV remote, channel changer of some kind, web
browser).

What I'd say is another trend is putting more user state in the model,
because of multi-user, session-based approaches, with Second Life a
good example (of needing to persist user state amidst all the rest of
it).  Blogged about this here:
http://controlroom.blogspot.com/2007/09/more-curriculum-writing-re-mvc.html

To fine tune, I'm not seeing SQL engines going away, but in addition
to ORM, which keeps a coding level insulated from a lot of raw SQL,
we're seeing in influx of more object oriented data storage designs,
sometimes with a "SQL like" syntax for combing through, getting some
subset (like a result set), Google new GQL the most obvious example in
some ways. http://code.google.com/appengine/docs/datastore/gqlqueryclass.html

I understand serialization has been around for a long time (Python's
pickle), so whats newer is not just going straight to the filesystem
provided by the OS and instead running a process like Zope's ** such
that programmers get a more web-friendly API (or at least that's often
a goal).

Kirby

** still a lot Medusa under the hood or did that go away? -- I spent
several days in a Plone sprint in Victoria with Alan and others, but
have since fallen behind in my reading in that literature (Plone is a
Zope-driven framework, quite a sandbox for trailblazing ideas I think,
plone.org , saw Alan in Chicago (but briefly))

On Thu, Jun 12, 2008 at 1:34 AM, Igal Koshevoy <igal at pragmaticraft.com> wrote:
> It was great seeing so many people interested in Python!
>
> In my presentation, I feel I could have done a better job answering an
> important question: Why would I choose each of these frameworks? So here's
> my second attempt at answering this:
>
> * Ruby on Rails: Need to quickly deliver a high-value project with rapidly
> changing requirements and a small team of expert developers that can be
> effective with such a powerful and complex toolkit.
> * TurboGears 1: Need a mature, dependable pre-assembled framework that's
> flexible, and easy to setup and learn.
> * TurboGears 2: Please consider using another framework until this project
> is further along.
> * Pylons: Need to snap together a framework from libraries that best fit the
> dev team's opinionated needs, e.g. Mako vs. Genshi.
> * Django: Need to build many long-lived, high-traffic apps at a larger
> organization were it helps to have a well-designed, fully-integrated common
> platform with good docs and many 3rd party extensions.
>
> How would you try to answer this question for the frameworks you know?
>
> The great news is that I don't think you can't make a "wrong" decision
> because all of these are good products. However because each framework
> caters to different needs, I recommend setting aside a few days and building
> a simple app (e.g. todo list, address book, etc) with each to see if it's
> right for you.
>
> Cheers!
>
> -igal
> _______________________________________________
> Portland mailing list
> Portland at python.org
> http://mail.python.org/mailman/listinfo/portland
>