Prev: Setting Parameters inside of code
Next: Problem with Dynamically unloading a module
From: Yarko on 21 Dec 2009 10:50
On Dec 19, 8:39 pm, AppRe Godeck <a...(a)godeck.com> wrote:
> On Sat, 19 Dec 2009 12:48:07 -0800, Yarko wrote:
> > On Dec 19, 12:42 am, AppRe Godeck <a...(a)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
From: Yarko on 21 Dec 2009 11:08
On Dec 21, 2:32 am, Bruno Desthuilliers <bruno.
42.desthuilli...(a)websiteburo.invalid> 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

From: Yarko on 21 Dec 2009 15:50
On Dec 21, 2:50 am, Bruno Desthuilliers <bruno.
42.desthuilli...(a)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

From: mdipierro on 22 Dec 2009 13:16
Some may find useful to compare:

- A Crash Course on Django
http://articles.sitepoint.com/article/django-crash-course

- A Crash Course on Web2py
http://www.web2py.com/AlterEgo/default/show/253

They basically describe the same app and the steps to built it. Sorry
I had not time to make screenshots.

I personally think it is great that we can learn from each other from
this kind of comparison and we can both improve.
I also think that stressing the similarities and the differences will
help prospective users understand the underlying design patterns.

Massimo
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Setting Parameters inside of code
Next: Problem with Dynamically unloading a module