Re: Anybody use web2py?
On Dec 19, 12:42 am, AppRe Godeck wrote:
> Just curious if anybody prefers web2py over django, and visa versa. I
> know it's been discussed on a flame war level a lot. I am looking for a
> more intellectual reasoning behind using one or the other.
Chevy or Ford? (or whatever pair you prefer)
vi or emacs?
...
These hold one aspect.
Hammer or a saw?
Hold (perhaps) another...
us.pycon.org, for example, uses both (in reality a mix of the above
argument sets, but at least evidence of the latter: different tools
for different problems).
>From a rapid prototyping perspective, web2py is heavily data-table
efficient: that is, you can define a system, and all the app creation,
form generation and validation have defaults out of the box, and you
can have a "sense" of your data-centric structure in minutes. The
same argument can go against ("how do I get it to do exactly what _I_
want it to, not what it wants to?") - that is, defaults hide things,
and that has two edges...
>From a layout/user interaction rapid prototyping perspective, web2py
is just entering the waters...
There is a steady growth of users, and (as you would expect for a
young framework), a lot of changes going on (although backward
compatiblity is a constant mantra when considering changes, that too
is a double-edged thing).
I find web2py useful, fast, and at times / in areas not as evolved /
flexible as I'd like. BUT I could learn it quickly, and get to work
quickly.
I have taken an intro Django course (at a PyCon), have built a few
things with it (not nearly as many as I have w/ web2py), and I _can_
do things in it - so I'll let someone else w/ django "miles" under
their belt speak their mind.
- Yarko
--
http://mail.python.org/mailman/listinfo/python-list
Re: Anybody use web2py?
On Dec 19, 2:48 pm, Yarko wrote:
> On Dec 19, 12:42 am, AppRe Godeck wrote:
>
> > Just curious if anybody prefers web2py over django, and visa versa. I
> > know it's been discussed on a flame war level a lot. I am looking for a
> > more intellectual reasoning behind using one or the other.
>
> Chevy or Ford? (or whatever pair you prefer)
> vi or emacs?
> ...
>
> These hold one aspect.
>
> Hammer or a saw?
>
> Hold (perhaps) another...
>
> us.pycon.org, for example, uses both (in reality a mix of the above
> argument sets, but at least evidence of the latter: different tools
> for different problems).
>
> From a rapid prototyping perspective, web2py is heavily data-table
> efficient: that is, you can define a system, and all the app creation,
> form generation and validation have defaults out of the box, and you
> can have a "sense" of your data-centric structure in minutes. The
> same argument can go against ("how do I get it to do exactly what _I_
> want it to, not what it wants to?") - that is, defaults hide things,
> and that has two edges...
>
> From a layout/user interaction rapid prototyping perspective, web2py
> is just entering the waters...
>
> There is a steady growth of users, and (as you would expect for a
> young framework), a lot of changes going on (although backward
> compatiblity is a constant mantra when considering changes, that too
> is a double-edged thing).
>
> I find web2py useful, fast, and at times / in areas not as evolved /
> flexible as I'd like. BUT I could learn it quickly, and get to work
> quickly.
Oh and one more thing: I find it dependable (not that snapshots don't
have bugs, but that they are well defined, not "wild", and quickly
fixed - and if you work around them, you can also depend on the system
you've created). FYI, it does the money/registration part of PyCon
(past 2 years).
>
> I have taken an intro Django course (at a PyCon), have built a few
> things with it (not nearly as many as I have w/ web2py), and I _can_
> do things in it - so I'll let someone else w/ django "miles" under
> their belt speak their mind.
>
> - Yarko
--
http://mail.python.org/mailman/listinfo/python-list
Re: Anybody use web2py?
On Dec 19, 8:39 pm, AppRe Godeck wrote:
> On Sat, 19 Dec 2009 12:48:07 -0800, Yarko wrote:
> > On Dec 19, 12:42 am, AppRe Godeck 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Anybody use web2py?
On Dec 21, 2:32 am, Bruno Desthuilliers wrote: > Thadeus Burgess a écrit : > (snip) > > > Spend one > > day working on a simple django application, polls, blog, image > > gallery, family pet tree, you name it. Then take the next day, and > > write the same application with web2py, and you decide. In the end, > > both are tools and you need to figure out what is best for YOU. > > The problem is not how easy it makes to write a *simple* (should I say > "braindead" ?) dummy test app, but how easy - or even possible -it makes > writing and maintaining a *real-world* complex application. Bruno - Check out the 50 minute coding-dojo we did at PyCon-2009: a complete news aggregation system, with authentication. There were people (who encouraged us to do the dojo) who doubted that we could cover so much ground in so little time. We asked WingIDE folks if they would donate a WingIDE for raffling at the dojo (to help draw people) - not only did they agree, then came and sat thru the dojo. At the end of the dojo, I think most people there were amazed: they had a complete system, and insight into how to extend and keep going with developing it further (e.g. for their own needs). I know the person who won the copy of WingIDE was on the web2py list after, continuing to work on apps. Wing wrote up a "how-to" develop web2py apps directly from wing, and we added a hook to defer "tickets" (web2py traceback logs) to the wing exception reporting system, if running under Wing (http:// www.wingware.com/doc/howtos/web2py). Hardly "brain-dead" (that is just a loaded term you threw out, but I see your skepticism). At some level, each programming activity decays to a "brain-dead" one, that is - to a trivially simple activity. However, a trivial activity (define a news aggregator, data tables; define a service to aggregate other data sources) does not equal a trivial result: in fact, the higher the level of abstraction I can make a _programmer_ activity trivially easy and still accomplish significant function, the more attention and time the programmer can spend on thinking about _the problem at hand_, rather than the _setting up of the system_ This is precisely one of the benefits I've seen touted in numerous papers arguing for teaching either Flash (adobe) over Java, or Python over Java --> the decrease in time spent worrying about setup of the system used to address a given problem/ algorithm. Easier / trivial setup in tool is good when it accomplishes what you need (e.g. gets out of your way, leaves more attention to the problem at hand). - Yarko -- http://mail.python.org/mailman/listinfo/python-list
Re: Anybody use web2py?
eb2py 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 -- http://mail.python.org/mailman/listinfo/python-list
