Anybody use web2py?

Yarko yarkot1 at gmail.com
Mon Dec 21 15:50:55 EST 2009


On Dec 21, 2:50 am, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> mdipierro a écrit :
...
> > This means you do not need to import
> > basic web2py symbols. They are already defined in the environment that
> > executes the models and controllers
>
> Ok. As far as I'm concerned : show stops here.

Sorry- I don't _think_ I'm following:  If you want to write an app all
yourself, and use components to put it together, that's fine - more
control, and more responsibility (e.g. watch for security, etc.).

But most web applications simply do not require or justify this much
effort spent on this level of "responsibility";  but maybe I'm missing
something less obvious that you mean, that makes "the show stop here"
for you.  If so, maybe you can be a bit more explicit about it.

....
>
> > - You have a web based IDE with editor,
>
> Why should I care ? I have a way better development environment on my
> own box.
>

For example, on a running system, simple things are possible simply:
change the cutoff date on something; change a class size.  Yeah, sure
- my app could write a controller for all those _little_ unanticipated
tweaks that inevitably come, but why bother?  You can just do it with
existing environment:   Want 100 coupons for that vendor?  No problem
(lets say that's in a controller).   Want to make it a special thingy
for that special vendor - put his image on his coupons? his words and
instructions?  Ok - I suppose i might have written a wiki interface so
someone can do this one thing, this one time - but (again) why
bother?  I'll do it thru the dev. interface on a running system.  If
I'm convinced it was an un-captured requirement (e.g. no one thought
of it until the system was running, or it was "assumed" but somehow
missed by everyone)  then I'll write the associated code, and add it
to the running system.  In fact, this is quite an agile way to do
it.   Both the dev. environ, and the command line shell help in this
(I can write a small loop in the shell to effect what might be a
controller for a customer, and output to a file instead of a view, and
ask the customer "Is this what you're looking for?"  - tweak, confirm
happy client, and then put the code I just used into a controller - if
it's short enough, right in the interface on the running system, and
have the client try it while we're still on the phone/IM/whatever.

The things I didn't think would be that useful - proved to have useful
application.


......
>
> Now FWIW, when my schema do change, the create/alter table code is
> usually the most trivial part - there are quite a few other things to
> do, that no framework will ever be abale to guess. IOW, you *do* have to
> write a migration script anyway.

In practice, this is /should be much less than you would think...
ADDING columns to tables is simple.
REMOVING columns... perhaps unnecessary on running systems...
ALTERING columns... can probably be handled instead by adding.

I think for most useful (and certain development time) cases, the
framework can do reasonable things, usefully.  But I do not deny that
there are cases where there is not way around doing things smarter
than that.  I think it is just that there are times where that is not
as necessary as at first appears.


.....
>
> Once again, while doing a quick dummy test app can give you a first
> general "feel" of the tool, it means nothing wrt/ complex real-world
> applications.

Actually, I agree - and I would go a bit further:  NO FRAMEWORK / tool
has anything much to do wrt/ complex real-world apps.  In fact, at the
framework / coding level, things should be as simple as possible (that
is where the cost is, anyway).

Good analysis of the problem domain will suggest the shape of the
solution needed.   Prototyping will then help with things like "can it
be a web app?" and "what technologies / implementation languages are
appropriate?"  Once you're at that stage, _any tool_ (and most likely,
combination of tools / set of tools) come into play: what do they do
to help at this level, how do they enable the process you want to
follow, how do they get out of the way.  Are they too rigid (too many
defaults / too few options for a given solution decision)?

But this is so far down the path of designing a solution that "complex
real-world" doesn't fitthis discussion, without getting more specific,
e.g. _a_ specific real-world app.   For PyCon, web2py registration was
done, reviewed, and put into place with little more than a month's
worth of discussion / prep.  Yeah, it didn't "look" like the main
PyCon site the first year (and didn't take much at all to change that
when I decided to).  Yeah, there are still details about integrating
w/ the django part of the site that could be taken care of from the
web2py end (I don't know, but was lead to believe it would be easier
from the web2py end than the django end, e.g. multiple database
connections).  As with many projects, if it is volunteer programming,
and if it's _really_ important, it will happen, or if someone _really_
wants to do it - otherwise it's not evidence of anything more than
something that's not really all that important.   A few years ago,
there was a challenge app (build a survey building app) that web2py
finished, and donated in < 24 hrs; no one else either completed, knew
of, or whatever - point is, if you _really_ want to make claims like
this, then setup an essential ingredient that you are convinced is
really beneficial - define it such that everyone agrees that it's a
good definition: it will either be a key deciding point (and helpful
to the community - "a does this; b does not"), or it will be a
challenge point that can be tested (e.g.  two solution approaches can
be devised by "those who know the tools", and inspected and reviewed
by the community - also helpful).  Anything else is just opinion and
talk - and to be sure, there is room for opinion, talk, and
preferences (no one really _needs_ to convince a Ford owner to drive a
Chevy - until some level of bankruptcy happens, it really doesn't
matter).  But even there, it is a benefit to the community in general
to separate the talk from the real deciding factors.  Thankfully,
preference will always play a part.

Kind regards,
- Yarko




More information about the Python-list mailing list