ruby on rails ... python on ?

[Peter Hansen]

Do you mean Zope?

Yikes! I *didn't* mean Zope, as it doesn't qualify for the
term 'enterprise application framework' as I used it above,
but I *should* have meant Zope, because upon revisiting the
rubyonrails.org site, I see that it is a *web* framework.

No idea how I missed that key word. Perhaps the MVC part
grabbed my eyes and filtered the rest of my reading (which
was admittedly brief). Perhaps I was just on drugs. Was
that a Saturday? Yes, it was definitely the drugs. Today
I'm on *different* drugs, the pretty blue ones, and I'm
feeling much furrier, thank you. Down, Shadowfax, down!
Oh, the spiders are crawling up my legs! They're coming
to take me away, away! to the funny farm, where life is

 

[A.M. Kuchling]

Sounds like a pretty safe bet to me, in general terms. I'm not quite
sure how fully a 'plain vanilla HTML' page can be controlled,
looks-wise, with CSS only, ...

Quite far; you can now do columnar layouts without any use of tables. For
example, take a look at
http://www.uwplatt.edu/web/webstandards/slashdot.html, a CSS-based retooling
of Slashdot. The HTML code is straightforward, using <Hn> for headings and
putting <DIV> in the proper places; everything else is CSS.

--amk

 

[Istvan Albert]

John wrote:

Why do you say that? I could agree if Zope could be programmed in many
languages. Then not tending to any language would be a benefit. On the

what I am trying to say is that a creating a web site is
not the same thing as implementing an algorithm or
solving a problem that fits a computational paradigm like say
Object Oriented approach.

Parts of it, the core functionality maybe but when it comes to
the interface and behavior and human interactions all that goes
out the window. It becomes an indeterministic business: this
how it works today, and it is all wired together in a way that
makes most sense from usability perspective today.

This last mile, the one that interfaces with humans, parameter reading and validation,
security management, request filtering, and response rendering
should be written specifically with this in mind and
it has to be supported it in an entirely transparent and
independent manner.

Istvan

 

[Jeff Blaine]

I've looked a little at Rails. It's not super special. Well, it *is*

compared to things like Java; dynamic languages *are* quite superior for
rapid development of websites, and Ruby and Python are similar languages
in that way.

Rails is really a whole stack that works well together. People have
been writing this sort of thing in Python for a long time; which isn't
to say they always have gotten it right, or that those efforts have had
the right perspective to be strategic successes (i.e., become popular).

I'd have to politely disagree that it's not super special. It
exists, in usable form, today, and works incredibly well and
incredibly cleanly. That's pretty super special, IMO

Talk is cheap!

All three of these pieces fit together really well in Rails, which is
perhaps what it offers that Python doesn't have. Well, I'm sure some
framework out there has this, but it's hard to say, there's so damn many.

I'm not at all sure.

But, while this is really compelling when you show off the creation of a
simple system, I suspect it becomes a fair amount more complicated later
on. At least, that is my experience with Python projects of similar
ambition. It's neat to setup a database and have it work instantly,
complete with the standard CRUD forms. But this only works for "leaf"
tables, and even then no so well. How do you deal with joins? How do
you deal with complex requirements on input, or actions on updates?
Eventually you'll need to tweak a generated form just a *little*, does
that mean you have to throw away all the automated aspects and code it
by hand?

I recommend watching the "2 hour" video at http://www.rubyonrails.org
(watch the last half)

I don't mean to criticize Rails with these questions; it's not that
Python frameworks solve these wonderfully either, these are just hard
problems. But for realistic web applications these are inevitable
issues, and I suspect Rails isn't quite as compelling when you take them
into account.

OTOH, I'd love to see something in Python that is just as tight as
Rails

Hell yes

Thanks for the objective and thoughtful post!

jblaine,
6yr-Python-fanatic-feeling-the-ruby-pull

 

[Dave Brueck]

6yr-Python-fanatic-feeling-the-ruby-pull

Like I said before - if you're feeling the Ruby pull, go for it. I tried Ruby
and rather strongly disliked it. If, instead, you're feeling the Rails pull (you
feel the ideas behind Rails have merit), then why not just port it to Python?

-Dave

 

[Alan Kennedy]

[Jeff Blaine]
[Dave Brueck]

Like I said before - if you're feeling the Ruby pull, go for it. I tried
Ruby and rather strongly disliked it. If, instead, you're feeling the
Rails pull (you feel the ideas behind Rails have merit), then why not
just port it to Python?

Or talk to someone who has already started. Peter Hunt declared to the
web-sig recently that he's interested in developing a python-on-rails,
which would also be WSGI compatible.

http://mail.python.org/pipermail/web-sig/2004-November/001042.html

Peter obviously hopes to capitalize on the portability of WSGI
middleware components.

regards,