in defense of reinvention, or, the goal of web.py - web.py

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion in defense of reinvention, or, the goal of web.py
Date: Fri, 13 Jul 2012 08:00:28 -0700 (PDT)
From: Tomas Schertel <tscher...@gmail.com>
To: webpy@googlegroups.com
Message-Id: <8619d99f-060e-424f-835b-4cb98ce7f1e4@googlegroups.com>
In-Reply-To: <8209b505-65ad-4bf2-a42f-64640e389503@googlegroups.com>
References: <dc21c7860602230659p4ee1f989hd1a8e98cd0dc0d2e@mail.gmail.com>
 <8209b505-65ad-4bf2-a42f-64640e389503@googlegroups.com>
Subject: Re: in defense of reinvention, or, the goal of web.py
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_428_14322734.1342191628327"

------=_Part_428_14322734.1342191628327
Content-Type: multipart/alternative; 
	boundary="----=_Part_429_2710776.1342191628327"

------=_Part_429_2710776.1342191628327
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Isn't a wiki a good idea??

On Friday, 13 July 2012 11:42:51 UTC-3, NSC wrote:
>
> For my part, I'm a true fan of web.py.  I've used most of the options out 
> there at least once, from ASP.NET to Django to Rails.  Each has a 
> purpose, some (Rails) were just too damn complicated for me personally to 
> get my head around and others (.NET) just don't make it easy for you to do 
> thing any way other than the (well documented yet often inefficient) way.
>
> All these options out there work well for what I'll call a "moderately 
> basic" web application, but fall short when things (inevitably) get 
> complicated.  We've all at least once spend days trying to jump some hurdle 
> because our application is just "special" and our toolkit just doesn't 
> quite fit.
>
> For example: I don't wanna be forced to abstract my database into objects 
> and compartmentalize my code into MVC. (I like sql, and am good at it.)  I 
> don't wanna have four technologies (html/css/js/php) intertwined all in one 
> file.  I don't want to compile all my code every time I change one line 
> just to test it.
>
> Some of my objects actually have sub-classes six levels deep.  Most of my 
> objects have at least a dozen methods, can be queried for presentation in 
> multiple ways (list, edit dialog, draggable item, etc), and can deliver 
> themselves in dictionary, json or xml format.
>
> Web.py empowered me to start working immediately, without having to mess 
> around with any of the HTTP crap.  Since my pages are well more complicated 
> than tables, buttons and forms, I've not used the templating bit.  Because 
> I already had a solid database layer (and my application connects to 
> multiple databases defined customly at runtime) I could not use the built 
> in db layer.
>
> My point?  In my opinion, web.py fulfills and stays true to it's mantra.  
> I rebuilt an enterprise application from the ground up in python in 10 
> weeks, by simply "thinking about the ideal way to write it" then making it 
> happen.  Every other tool I looked at was a barrier - web.py was an enabler.
>
> For me.  Your mileage may vary.
>
> NSC
>
> P.S. As others have said... yes, I do agree when getting started the 
> documentation was kindof annoying.  I think the community here would 
> deliver some great, practical tutorials if a wiki were started and opened 
> up for contribution.  I'll write at least two.
>
> On Thursday, February 23, 2006 9:59:26 AM UTC-5, Aaron Swartz wrote:
>>
>> > Inventing yet another template language...
>>
>> You don't have to use it -- each part of web.py is completely separate
>> from the others. But you're right, it is "yet another template
>> language". And I'm not going to apologize for it.
>>
>> The goal of web.py is to build the ideal way to make web apps. If
>> reinventing old things with only small differences were necessary to
>> achieve this goal, I would defend reinventing them. The difference
>> between the ideal way and the almost-ideal way is, as Mark Twain
>> suggested, the difference between the lighting and the lightning bug.
>>
>> But these aren't just small differences. Instead of exposing Python
>> objects, web.py allows you to build HTTP responses. Instead of trying
>> to make the database look like an object, web.py makes the database
>> easier to use. And instead of coming up with yet another way to write
>> HTML, the web.py template system tries to bring Python into HTML. Not
>> many other people are really trying to do that.
>>
>> You can disagree that these ways are better and say why. But simply
>> criticizing them for being different is a waste of time. Yes, they are
>> different. That's the whole point.
>>
>>
------=_Part_429_2710776.1342191628327
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Isn't a wiki a good idea??<br><br>On Friday, 13 July 2012 11:42:51 UTC-3, N=
SC  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">For my part, I'm a t=
rue fan of web.py.&nbsp; I've used most of the options out there at least o=
nce, from <a href=3D"http://ASP.NET" target=3D"_blank">ASP.NET</a> to Djang=
o to Rails.&nbsp; Each has a purpose, some (Rails) were just too damn compl=
icated for me personally to get my head around and others (.NET) just don't=
 make it easy for you to do thing any way other than the (well documented y=
et often inefficient) way.<br><br>All these options out there work well for=
 what I'll call a "moderately basic" web application, but fall short when t=
hings (inevitably) get complicated.&nbsp; We've all at least once spend day=
s trying to jump some hurdle because our application is just "special" and =
our toolkit just doesn't quite fit.<br><br>For example: I don't wanna be fo=
rced to abstract my database into objects and compartmentalize my code into=
 MVC. (I like sql, and am good at it.)&nbsp; I don't wanna have four techno=
logies (html/css/js/php) intertwined all in one file.&nbsp; I don't want to=
 compile all my code every time I change one line just to test it.<br><br>S=
ome of my objects actually have sub-classes six levels deep.&nbsp; Most of =
my objects have at least a dozen methods, can be queried for presentation i=
n multiple ways (list, edit dialog, draggable item, etc), and can deliver t=
hemselves in dictionary, json or xml format.<br><br>Web.py empowered me to =
start working immediately, without having to mess around with any of the HT=
TP crap.&nbsp; Since my pages are well more complicated than tables, button=
s and forms, I've not used the templating bit.&nbsp; Because I already had =
a solid database layer (and my application connects to multiple databases d=
efined customly at runtime) I could not use the built in db layer.<br><br>M=
y point?&nbsp; In my opinion, web.py fulfills and stays true to it's mantra=
.&nbsp; I rebuilt an enterprise application from the ground up in python in=
 10 weeks, by simply "thinking about the ideal way to write it" then making=
 it happen.&nbsp; Every other tool I looked at was a barrier - web.py was a=
n enabler.<br><br>For me.&nbsp; Your mileage may vary.<br><br>NSC<br><br>P.=
S. As others have said... yes, I do agree when getting started the document=
ation was kindof annoying.&nbsp; I think the community here would deliver s=
ome great, practical tutorials if a wiki were started and opened up for con=
tribution.&nbsp; I'll write at least two.<br><br>On Thursday, February 23, =
2006 9:59:26 AM UTC-5, Aaron Swartz wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">&gt; Inventing yet another template language...<p>You don't have to =
use it -- each part of web.py is completely separate<br>from the others. Bu=
t you're right, it is "yet another template<br>language". And I'm not going=
 to apologize for it.</p><p>The goal of web.py is to build the ideal way to=
 make web apps. If<br>reinventing old things with only small differences we=
re necessary to<br>achieve this goal, I would defend reinventing them. The =
difference<br>between the ideal way and the almost-ideal way is, as Mark Tw=
ain<br>suggested, the difference between the lighting and the lightning bug=
.</p><p>But these aren't just small differences. Instead of exposing Python=
<br>objects, web.py allows you to build HTTP responses. Instead of trying<b=
r>to make the database look like an object, web.py makes the database<br>ea=
sier to use. And instead of coming up with yet another way to write<br>HTML=
, the web.py template system tries to bring Python into HTML. Not<br>many o=
ther people are really trying to do that.</p><p>You can disagree that these=
 ways are better and say why. But simply<br>criticizing them for being diff=
erent is a waste of time. Yes, they are<br>different. That's the whole poin=
t.<br></p><p></p><p></p><p></p></blockquote></blockquote>
------=_Part_429_2710776.1342191628327--

------=_Part_428_14322734.1342191628327--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
