On Wednesday, June 7, 2017 at 8:16:38 PM UTC-7, [email protected] wrote:
>
> According to github, there were semi-regular releases going back to 2013,
> then they stopped about a year ago, so I guess it's only natural for people
> to wonder about the status of the project. Personally, I'm wondering if the
> project will continue to build production releases in the future. I see
> that master still gets some love, so maybe master is now stable for
> production and I missed it?
>
> Anyhow, thank you for all your work on this framework. I admire the
> project itself and I think the community speaks for its integrity. I read
> your post earlier in this thread on your plans for web3py, and I thought I
> would say that as a web2py user, I loved how it gave me a current version
> of a few nice libraries and flattened web development into a single Python
> layer. Basically it gave me a mostly pre-built good-enough web interface
> and let me get on with the business of developing services for users.
>
>
I agree with this as well. I haven't been using web2py too long, but one
of the things I really like about it is how self-contained it is. Many of
the other frameworks involve layers of dependencies on all sorts of things
that make it quite onerous to begin. web2py shines in that regard.
> Your web3py post concedes that the days of the flat development stack are
> over, and I agree it's unavoidable to use some of the newer JS components
> and move a lot of the work to the browser. I haven't checked out the stack
> you've listed in your reply yet, but I'll very likely end up using whatever
> you put together because I want to keep using helpers, validators and the
> DAL. I look forward to the day the lineup is stable enough for release, and
> thanks again for your past work on web2py.
>
>
I think it would be unfortunate for the "flat stack" to disappear
entirely. Hopefully a compromise can be reached in which web2py ships (or
at least can ship) with a bundle of tested-and-verified-to-work-together
dependencies allowing simple installation.
Just to add my own perspective on the web3py play Massimo outlined: in my
experience, the main weaknesses in web2py are the "magicness" of the
import/namespace model, and the lack of comprehensive client/server
communication tools. By the first I mean many of the things I've asked
about (and been graciously helped with) over the past several months. The
way that web2py manipulates import paths, executes code per request, and
populates namespaces automatically (e.g., making names defined in model
code available in controllers) makes many things convenient. However, the
magic underlying this is not fully exposed, meaning that code reuse can
become difficult if you stray outside the predefined magic boundaries.
It's difficult, for instance, to create modules that factor out db-centric
code, because the db object (typically defined in a model file) won't be
available; this forces you to reimplement the wheel to some extent by
taking the db-creation code out of a plain model file and put it in a
function --- which then breaks things like the db-admin tool. Obviously
these are complex issues, but in the end I think it would be ideal to find
a way that makes simple things smooth without making more complex code
interdependencies quite so painful. (Importing rather than executing code
may help in this regard.)
The second weakness is client/server communication. The web2py view
template model is great, so telling the client what you want to serve is
easy. The problem comes when you want more or less continuous
back-and-forth communication between client and server. Most of web2py's
client/server communication model is based on forms, which require the
entire page to be reloaded. While I'm not super gung-ho for "single-page
apps", I do think that it's essential to facilitate "incremental" or
"modular" communication between individual page elements and the server. A
clear example is validation. Web2py has an elaborate validation mechanism
which is quite powerful, but the need to submit an actual form makes it
rather ponderous for situations where you want a "form" as just part of a
page. For instance, if you have a login form as a small box in the corner
of a content page, you really want stuff like email validation to happen
without a page reload. It still needs to talk to the server, but it should
be doing it with per-item AJAX. I do think, though, that this is something
that could be added to the existing web2py without requiring a wholesale
rewrite; it basically amounts to adding more full-featured client-side
tools, with linkups to the server, so that instead of using SQLFORM or
whatever you can just have a series of <INPUT> elements in a view along
with a {{=submitAjax}} or something that causes them to do their thing
independent of the rest of the page. The "components" model seems to be
something along these lines but from what I see it is still a good deal
less comprehensive than the whole form/validator mechanism available to
"real" forms.
I've become quite a fan of web2py in the last year or two that I've been
using it and hope to see it continue forward!
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
