If you've never looked at this video, please do - it's about 1/2 hour but
worth the time (I just took it in pieces over the afternoon).
>From my notes:
In this test, web2py would have came out on top (and understandably so).
Opportunities for web2py (based on observing this video):
- docs
- (nothing you didn't already know, but note: django in this version
rated fair on docs because there were no books yet, so this is a
stage-of-development thing; AND there actually already is good
documentation
- the book; only it's not free, and you may not be thrilled
about that - but
it is good, works, and is there; and there's more in the works)
- Legacy Database Interface
- we get a lot of request for this, and this video just validates that
those are reasonable and valid requests.
- automatic database reflection is possible (to an extent; proved by
and within the limits SQLAlchemy already does, and probably others;)
- mapping existing db names to DAL naming conventions needed .... this
may come up in new DAL; if not, we can probably do this (first)
in a contrib
package; the most obvious use is mappind to ID, but any relevant db name
needs to map to (e.g. names starting with "_"). This is all
do-able, given
time.
- Full text search
- I have no idea what the state of this is, but know that having it,
and having it easy for an application to add / use will be great;
- Skinning
- This means not changing the template language elements of a
particular site in order to get a different look
- We can get to this, with some conventions. Seems 2 rough places:
CSS standard names for basic layout elements will facilitate;
jPolite kind
of layout, with look-and-feel for content frames seems to me the second
part.
- I have no idea what this means for Flash/Flex UI's, but suspect this
is an entirely separate ballgame.
Everything else, I'm pleased to say, web2py already excels in quite well,
thank you - and even more....
Not from this video, but my own observations:
- C-DAL
- We have some interplay with Google's big tables from DAL, but the
"fit" is partial, less than ideal (though still workable).
- My personal opinion has been (and is growing in conviction) that a
Column oriented DAL, that is abstracting things specific to Big Tables,
Cassandra (Facebook), and other prime users (I don't think couchDB falls
into this bucket; I'm not sure what Amazon S3 is exactly - is it a column
oriented thing too? - it's not advertised) I see that Apache
Hadoop can be
hosted on S3, so my suggestion for an initial abstraction
experiment is Big
Tables, Cassandra, and Hadoop.
- Over time (and with experience) it will be interesting to see what
overlap / abstraction synergy between C-DAL and R-DAL (relational - the
current DAL; I just want a way to distinquish them). It would be nice to
have a common DAL with abstractions that fit well in both (sort
of what we
have now, only less skewed towards relational, and perhaps better
cenetered), and ability to move to either R-DAL or C-DAL to get more
performance / feature control into either domain.
Lots of fun ahead, even without "many changes" - there are enough to keep
things nicely interesting.
And notice: none of what is layed out here breaks or affects backward
compatibility - it's all forward motion, enhance / extend.
- Yarko
On Sat, Jul 18, 2009 at 11:21 AM, Yarko Tymciurak <[email protected]> wrote:
> Ach! Yes that's it - JPL - It was from Sean Kelly who's video starts with
> him working at NOAA:
>
> http://oodt.jpl.nasa.gov/better-web-app.mov
>
>
> On Sat, Jul 18, 2009 at 7:42 AM, weheh <[email protected]> wrote:
>
>>
>> -----
>> all the rest of this is smack-dab peachy: I'll remind you of one
>> thing -
>> there was a website, guy from NOAA I think it was - that showed all
>> the
>> frameworks that claimed to have something; he tried building
>> something
>> simple with them and uncovered all the flaws and gotchas and try to
>> say
>> "here's what I would (wouldn't) want to build with".... most things
>> just
>> took a long time...
>> -----
>>
>> Actually, it was a guy from JPL as I recall. In fact, watching his
>> screencast is exactly what got me started looking at frameworks and
>> CMSs. One thing led to the next and I found Django. And then I watched
>> a video of one of Django's developers and he said something like this:
>> "... Django's templataing language is different from python because
>> it's made for page designers. Page designers don't write programs and
>> programmers don't design pages."
>>
>> That is exactly what lost me for Django. Then I found web2py and the
>> rest is history.
>>
>> I agree wholeheartedly with MDP's observation of the 80:20 rule.
>> However, I find that web2py is an exception. On my first web2py app I
>> probably used 90-95% of the features of web2py. On the next app, it
>> will be 100%. Interestingly, my plate will be clean AND my appetite
>> sated. There is nothing extraneous in web2py that I can discern.
>>
>> Web2py's niche is that one person of reasonable skill can develop a
>> sophisticated enterprise web application in minimal time with minimal
>> effort. This is because of its 3Cs: consistency, completeness, and
>> conciseness.
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
