Interesting screencast webdevelopment using Python

For me, the most important thing in the presentation was the
statement
that development in the 2000's is "Less about
widgets, more about page
layout." I.e., "Which Web framework?" is
an important question; "Web
framework or desktop widgets?" was basically a late
90's issue.

Yet every time a python newbie asks, "How do I put a
GUI on this?,"
virtually all of the responses will discuss various ways of
making
desktop widgets. (You can look it up as recently as last
week:
http://groups.google.com/group
/comp.lang.python/browse_frm/thread/989b957f244d48e0
) -- How 90's is that? Since browser can do desktop, but
not
vice-versa, our FIRST response should be browser-based.

Here we are with 3 very nice, free, python-based solutions
of various
"weights," that are dead simple to learn, (if
the newbies already write
HTML, and in today's market, they'd better!), and yet most
of the
responses revolve around desktop widgets -- which are
non-starters in
these days. We might fall back to them, but for most of what
we do, the
browser has to come first.

Ruby was a backwater until ROR -- which isn't without its
faults (watch
the movie!), but it's gaining fast because it's caused
Ruby to be seen
as browser-focused, where Python is seen as
desktop-oriented. If a
newbie asks a Ruby GUI question, the answer comes back as a
ROR
solution, but in Python the answer will come back in terms
of 1990's
desktop widgets.

Ron


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

Well put, and importantly true, I think.

But one of the reasons peope fall back to widgets is not
HTML (which is
fine, and a genuine complement to what python does so well),
but
javascript (which pythonistas feel is an inferior 
imposition and
distraction ).
Mozpython http://www.tho
mas-schilz.de/MozPython/
PyMoz http://aspn.activestate.com/ASPN/Downloads/Komodo/PyXP
COM/
http
://blog.ianbicking.org/i-dream-of-pymoz.html
and firecat
http://firecat.nihonsoft.org/i
ndex.nsp;NSESSIONID=39825dc8691c44827ed67b2c791e9132
all suggest that it would and should! be possible to allow
python/jython programmers to script the browser as well as
the server
in their favorite language.

I am not trying to start a which-language is better flame. 
But on
behalf of those of us who prefer python,  someone, please
MAKE IT SO
for python (and what the hell, for the other languages if
you can).   A
lot of  clues, components,  arguments, and the competition)
are here
http:
//ajaxian.com/archives/ruby-in-the-browser

Is the python foundation still funding projects?  If someone
with the
right skills would take this up, I can't imagine a better
way of
investing in the language or the feild....


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

Oh, that would make it so fine!

I don't think there's much danger of a flame-war, since I
can't imagine
there's anyone willing to carry a torch for Javascript, per
se. Any
other language is basically going to have to be an emitter
of JS, with
all the suckiness that implies. As far as which language
gets to emit
JS, I guess it's absolutely any language that steps up to
doing that.

Maybe what's really needed is a
(JS-in-any-given-browser-DOM)-to-standardized-ECMAscript
wrapper that
we can include in our HTML page, then we could just
write/emit our
scripts in that standardized ECMAscript. Javascript would be
bearable
if it would just hold still, and not go wiggling off and
growing extra
heads every time you change browsers.

I don't think there's anything that makes writing a
Ruby-style JS
emitter any easier than writing a Python-style JS emitter,
is there?
The problem isn't Ruby, Python, or any other modern
language; it's
proprietary-almost-Javascripts-in-proprietary-almost-DOMs
that are the
problem.

Ron


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

jschullgmail.com wrote:
> Well put, and importantly true, I think.
>
> But one of the reasons peope fall back to widgets is
not HTML (which is
> fine, and a genuine complement to what python does so
well), but
> javascript (which pythonistas feel is an inferior 
imposition and
> distraction ).
> Mozpython http://www.tho
mas-schilz.de/MozPython/
> PyMoz http://aspn.activestate.com/ASPN/Downloads/Komodo/PyXP
COM/
> http
://blog.ianbicking.org/i-dream-of-pymoz.html
> and firecat
> http://firecat.nihonsoft.org/i
ndex.nsp;NSESSIONID=39825dc8691c44827ed67b2c791e9132
> all suggest that it would and should! be possible to
allow
> python/jython programmers to script the browser as well
as the server
> in their favorite language.
>
> I am not trying to start a which-language is better
flame.  But on
> behalf of those of us who prefer python,  someone,
please MAKE IT SO
> for python (and what the hell, for the other languages
if you can).   A
> lot of  clues, components,  arguments, and the
competition) are here
> http:
//ajaxian.com/archives/ruby-in-the-browser
>
> Is the python foundation still funding projects?  If
someone with the
> right skills would take this up, I can't imagine a
better way of
> investing in the language or the feild....

Ha.  In a perfect world we wouldn't have to worry about the
MSIE side
of that equation 

Anyway, a few more links:

http://cop
ia.ogbuji.net/blog/keyword/xpcom
ht
tp://copia.ogbuji.net/blog/2005-09-10/Kumite__Py
http://kb.mozillazi
ne.org/PyXPCOM
http://aspn.activestate.com/ASPN/Mail/Browse/Thread
ed/pyxpcom

P.S.  Anyone here remember Grail?  

--


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

Thanks, Uche, I didn't know about pyxpcom (although jschull
did list
it, as well). OK, if it's a desktop app, then presumably
the developer
can dictate installing a Gecko browser as part of the app.

I like that because it lets us get more users accustomed to
the idea
that there are other browsers. Many casual users don't
realize that IE
is a browser or that other browsers exist, let alone work
better.

My point, though, is that we Pythonistas do the language a
disservice
by instantly starting discussions of desktop widgets, but
that's what
almost invariably happens. It's not inherent in Python --
Python has
lots of workable http: based capability -- it's
unfortunately embedded
in the helpful user community. The only real advantage Ruby
has,
popularly, is that its community thinks first of ROR when a
newbie asks
about GUI.

So, if someone is a Python newbie, and they ask about adding
a GUI to
their program, I'd recommend:

If it's just a desktop app and that's all it will ever be,
use
Karrigell to make a browser-based GUI.

If it's ever possibly going to be Web-based, then use
CherryPy. If it's
going to talk to a database, use Turbogears right off the
bat.

Finally, if you are just one of a group of developers, and
this project
is going to continue for a long time, look at Zope/Plone.

I wouldn't mention wxWindows, or Tcl/Tk, or any
desktop-only answer
unless they specifically asked! It makes me crazy when
"How can I add a
GUI?" provokes twenty responses arguing the relative
merits of
basically dead-end technologies. If they would argue
Karrigell vs.
CherryPy, I'd be happy -- I wouldn't care much who won. At
least the
whole discussion wouldn't make Python look so irrelevant to
this
century's concerns.

Ron


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

paron wrote:
> If it's ever possibly going to be Web-based, then use
CherryPy. If it's
> going to talk to a database, use Turbogears right off
the bat.

This is an interesting discussion.  Here is a recipe I wrote
a few 
months ago as a "sketch" for making a simple
browser-based desktop app 
with CherryPy:
http://aspn.activestate.com/ASPN/Cookbook/Python/R
ecipe/442481

Christian
http://www.dowski.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

On 3/9/06, paron <rphillipsengineer.co.summit.oh.us> wrote:
> If it's ever possibly going to be Web-based, then use
CherryPy. If it's
> going to talk to a database, use Turbogears right off
the bat.

It's worth noting that TurboGears started life as part of a
desktop
app (Zesty News).

Kevin

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

On 3/9/06, paron <rphillipsengineer.co.summit.oh.us> wrote:
> My point, though, is that we Pythonistas do the
language a disservice
> by instantly starting discussions of desktop widgets,
but that's what
> almost invariably happens. It's not inherent in Python
-- Python has
> lots of workable http: based capability -- it's
unfortunately embedded
> in the helpful user community. The only real advantage
Ruby has,
> popularly, is that its community thinks first of ROR
when a newbie asks
> about GUI.

Well, "GUI" means something like wxWidgets or Qt
to a lot of people,
including me.  That other thing is a "web
interface".  Interesting
that Ruby programmers don't see it that way, if indeed that
statement
is true.  But many people do tell people to evaluate both a
widget
interface and a web one before deciding, because there are
tradeoffs
both ways.  HTML controls are still clunky (e.g., textarea,
lack of
combo box) even with Javascript/CSS window dressing.  The
delay of
server roundtripping can still be irritating even with AJAX.

Plus, the user wants an icon he can double-click to start an
application, then it brings up a window, he chooses Quit,
and the
application exits -- just like all his other applications
work.  But
if it brings up a console window, launches a browser window
(which may
or may not succeed, and may interact with the browser he
already has
open: new window?, new tab?, foreground or background tab?
different
than what the tech person told him?), then he quits the
browser but
the server is still running, or he leaves for a few hours
and the the
browser is still open but the server has quit, it starts
behaving less
like a traditional application.  Or maybe the server has a
little GUI
to quit/restart/launch a browser -- but then you're getting
into
widgets again.  If there were a cross-platform way to embed
a browser
instance in the server process, these problems would go
away.

I'm actually working on a web application that will need a
browser-based standalone mode (for laptops without Internet
access),
so I'm quite interested in how this would work.  We're
going for a web
interface rather than a widget interface because we need the
web
interface anyway (for a traditional webserver), and we'd
rather
maintain one UI rather than two.

--
Mike Orr <sluggostergmail.com>
(msooz.net address is semi-reliable)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

Titus and Mike: Good, good, good -- thank you for getting
the
discussion back on track!

I started from the statement (2x) in the movie that
<clip>development
in the 2000's is "Less about widgets, more about page
layout."</clip>

Then I examined the responses to the latest "How do I
put a GUI on
this?" that I could find: <clip> (You can look
it up as recently as
last week:
http://groups.google.com/group/comp.lang
.python/browse_frm/thread/989...
) -- How 90's is that?</clip>

I made the assertion that Ruby was a backwater until
RubyOnRails.

So, given the assertion from the movie (development in the
2000s is
"Less about widgets, more about page layout."),
then the fact that
Python folks almost inevitably answer GUI questions in terms
of widgets
(as recently as last week) could explain Ruby's sudden
ascendency. It's
not language, per se, it's culture.

There's nothing inherent in Python that limits it to the
widgets realm
-- but virtually every response, virtually every tutorial,
virtually
every book that talks about Python GUI talks exclusively in
terms of
widgets, which is a 90's vintage solution.

When "Glurt Wuntal" asked for help putting a GUI
on his apps (Mar 2,
2006), there were 22! replys that discussed the merits of
glade, pyGTK,
wxWidgets, Tcl/TK, etc. and NOT ONE MENTION of CherryPy,
Karrigell,
CGIHttpServer, TurboGears or Zope.

What will be the first 22 responses if someone posts the
analogous
question on a Ruby newsgroup?

P.S. -- sorry for the bit of 'trolling' in making that
admittedly silly
assertion. I just think Python is the best language out
there and I
hate to see all its Web frameworks being "damned with
faint praise." I
wish the whole "TG vs Karrigell" discussion had
been at least part of
the response to "Glurt Wuntal".


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---