Anybody use web2py?

[Yarko]

On Dec 19, 8:39 pm, AppRe Godeck <a... at godeck.com> wrote:
> On Sat, 19 Dec 2009 12:48:07 -0800, Yarko wrote:
> > On Dec 19, 12:42 am, AppRe Godeck <a... at godeck.com> wrote:

....
>
> It seems that this is the biggest issue surrounding web2py, from my
> research, is the ability to customize the defaults (the easy). If all
> web2py offers is default views, then it may be good for proof of concept
> projects, however I can't see in my right mind, proofing an application,
> and then turning around to write it in django because more than the
> defaults is needed.
>

Perhaps I can clarify this:
- You CAN customize defaults easily ... but the default setup is so
easy, sometimes it's not initially clear where / how to do this in
web2py.

For example:  default views:

I updated (recently) the PyCon-2010  registration site so that it
"looked" like the base PyCon-2010 (django) site.  I copied some key
css and image files, replaced the big header/footers in the web2py
base layout (which is inherited by other views - also by default - so
he effect cascaded exactly as I wanted).

To quickly morph what I wanted from the web2py app's existing view
onto the new template (e.g., the menus, and the color/highlits of it's
pulldowns)  I went into a PC app (thru virtualbox):  stylizer - and
moved things around, changed the colors (e.g. of highlites) and saved
the result.   I then had cleaned it up.   Total time to change the
look:  about 45 minutes (20 minutes of that playing around with
Stylizer, enough to decide to use that for what I wanted to do).

In the result,  the templating (or view) language in Web2Py is...
um... *cough* ... *ahem* ... _simply pure python.

"How to I update the view?"  comes up often for new people.   "Just
write the code and references you want to call up in the view."
"How do I write them?"   "Python."

This comes up over and over.  How can you write python in view (html
files)?   How is indenting handled?  That's perhaps the only thing the
"templateing" language does:  It makes some assumptions about
indenting, so (for example) where context would signal the natural end
of indenting, in the template language you add a "hint" to the
template language:   {{ pass }}.

To output to the view, leave the left side empty:   {{ var='Output
this text'; =var }}
(result of var is output).

Another "how do I customize" question that comes up: data validation:
there are 2 levels in the DAL:  constraints which are defined in a
table field, and passed on as a constraint in the db engine;
constraints which are runtime in the request (e.g. in the web app).
The latter is easy to programmatically modify per context.   The first
time you do validation this becomes clear.

Another place is form customization.  You can customize forms.  There
are layers to this: in web2py, forms are automatically created for
data objects.  At one level, you have control over what data fields
are exposed.  At another, you have control over the type of object
that is presented in the form (list? text field?)  by the form of the
validator you setup.  This is one place where you have control over
"default" behaviors, but still used lots of the default "engine".  And
you can create custom forms altogether.

Then there are viewports:  Beside layouts / template (all the basic
stuff you will recognize from most other frameworks - not just
django), and more-or-less the same kind of inheritence model of views
you might expect, there are a few things:  the classes for HTML you
asked about:  If you reference those classes in your view, output and
integration with any view code will happen for you (that is, prefer
the class definition of bold to the html syntax, for you can pass
arguments, escape, and put in other activity on the content and output
within the HTML tag for which there is a class member.  You'd
mentioned "class" not being "view" - the first thing to let go of is
"executable python code" is not the same thing as "controller", eg.
view-logic != behavior-logic (business-rule, controller, whatever you
are accustomed to calling this).   Views have logic (just think of
ajax calls, javascript, and now Python-for-template code).   It's not
"is it code that runs" that is the important question, it is "what is
this code affecting?"  - Presentation, "business logic", or
persistence/data/model?

And then there's is automatic association of behavior with some part
of your view: automatic controller assignment and ajax setup...

All the tools within web2py provide what you need to customize /
change defaults.  Perhaps "forms" are the ... least clear... have the
most layers / ways to approach (or is it views? ;-).  But there is a
way for all, no reason to prototype and throw away.  But you WILL be
asking "how" at first, not doubt.

Hope this has been somewhat helpful.

- Yarko