reasons::
- bad routes.py
- changeless pattern for URL had to base routes.py redirect into short URL
- routes.py is out app
- url can not understand Chinese
- tooo stand alone app
- session/static ... is all srand alone
- can not easy base app slpit site's components
- tooo slow boot
- import tooo many lib
- error report is tooo ugly
- can not support debug easy!
- fighting with build-in module
- https://groups.google.com/group/web2py/browse_thread/thread/e20d0bd2e542aa14/a660bac70d5611a4
- can work with logging
- tooo magic
- http://stackoverflow.com/questions/1999950/download-link-fails-in-ie
- auto work in background,but not all clean
- NULL unittest support!
- DAL is bad than SQLAlchemy
- MVC is insulated!
- model/control/view all variable is in same name space
ONLY two feeling good:
- deployment is stand alone
- but usage yolk+virtualenv others web app. framework also can
deplotment stand alone
- built-in crontab task support
PS:
translate from: "Mage from hell: 说说 web2py"
http://blog.hellmage.info/2010/02/web2py.html
PPS:
hope mdipierro fixed these bad feeling for developer in time;
make web2py become realy ent. web app. workframe
--
http://zoomquiet.org 人生苦短? Pythonic!
Free as in Freedom! 哲思社区:http://zeuux.com
routes.py:
- It seems to me that Django routes are just as complicated:
http://docs.djangoproject.com/en/1.1/intro/overview/#design-your-urls
- Providing the routes.py outside of an app makes sense for web2py since
it directly maps app/controller/function to a url. This decision was
made to make things clear and understandable for new developers.
Chinese URLs:
- perhaps you could have written a patch?
- (more info:
http://en.wikipedia.org/wiki/Internationalizing_Domain_Names_in_Applications)
Standalone Apps:
- sessions can "master" to another application to tie them together.
- I use routes to unify all my static content to one app location.
Slow Boot:
- How often do you restart web2py? It can work as a CGI but only as a
stop-gap measure. Any web-developer worth his salt would run a framework
in FCGI or WSGI mode.
- I don't really care for the import_all.py module either.
Errors:
- I think the error report leaves much to be desired but at present, I
think we're locked in because of backward compatibility.
"fighting with built-in module" <-- I'm not sure what you mean here.
Too "magic":
- web2py is designed to be simple. I think how web2py sets headers is
appropriate.
- I agree that it should set appropriate headers with regard to SSL and
static files and IE.
No unittests:
- Creating unittests requires a culture.
- the web2py doesn't seem to have that culture built into it (for better
or worse)
- While web2py should have unittests, web apps don't mix well with
unittests.
- Functional tests would be much more appropriate for a web app. Most
functional tests would run in the browser anyway (e.g. Qunit)
"DAL is bad than SQLAlchemy":
- This a subjective statement
- The DAL is not as well-tested or as widely-used as SQLAlchemy. But it
is good enough for the vast majority of web2py users.
- The DAL supports migration, SQLAlchemy does not.
- The DAL has a cleaner (IMHO) declaration syntax and an uglier query
syntax when compared to SQLAlchemy.
MVC is insulated:
- I'm not sure what you mean here.
- Yes they are all in the same namespace. How is this a problem?
It's a bummer to see you and your team go. We wish you the best.
-tim
I am sorry to hear that and thanks for letting us know. We are glad to
provide an option but everybody has it own preferences. Anyway, I have
some responses to your comments:
> reasons::
> - bad routes.py
> - changeless pattern for URL had to base routes.py redirect into short URL
> - routes.py is out app
The syntax of routes is actually more powerful than Django's (has the
same syntax for regular expression but for example we provide
filtering by hostname, client ip, request method and explicit reversed
routing; Django needs a route entry for evey action, web2py provides
defaults). I do agree that web2py does not have a way to delegate
routes to an app. This would me more syntactic sugar than
functionality and we are working on adding it. I never realized this
was such a critical point. I will move some resources in getting this
done.
> - url can not understand Chinese
No but there is only one line to change to fix this. You can also
handle this with routes (something you will have to do with Django
too).
> - tooo stand alone app
> - session/static ... is all srand alone
> - can not easy base app slpit site's components
Not sure I understand
> - tooo slow boot
> - import tooo many lib
This can be changed by editing one line in "import_all". The choice to
import all at the beginning was a design decision, so that we do now
slow down later requests that request those standard libraries.
> - error report is tooo ugly
> - can not support debug easy!
Yes compared with Django and Pylons. But our their reports are
interactive therefore you ONLY get them if the bog shows up to you
when logged in as administrator. There is no report if the error
manifests to a regular use. web2py records all errors and traceback
and issues tickets to ALL users. that is why our error reports are
static. You pay a small price in development but get a big benefit in
production. You choose.
> - fighting with build-in module
> - https://groups.google.com/group/web2py/browse_thread/thread/e20d0bd2e...
> - can work with logging
Not sure I understand.
> - tooo magic
> - http://stackoverflow.com/questions/1999950/download-link-fails-in-ie
> - auto work in background,but not all clean
The mechanism we provide for upload is the same as Django. We also
provide a download mechanism that checks for authentication. Perhaps
this is a bit magic but it is the only way to do it. You do not have
to use it.
> - NULL unittest support!
We have unitests in gluon/tests for web2py itself and you can create
your own unitests for apps in gluon/unitests although for apps we
think doctests are more practical.
> - DAL is bad than SQLAlchemy
Perhaps but Django does not use SQLAlchemy. Both web2py and Django can
import SQLAlchemy if necessary but it would not work with generated
forms (with either). DAL is more powerful than Django (nested selects
for example).
> - MVC is insulated!
> - model/control/view all variable is in same name space
Not true. Only models variables are imported in the space of
controllers and in the space of views. variables defined in
controllers stay private there. In our view that is what defines a
model: stuff that should be available everywhere in the app. Show me a
Django app where the controller (which they call view) does not import
the models? We just make this default since in practice it is.
Massimo
On Feb 4, 8:48 am, Timothy Farrell <tfarr...@swgen.com> wrote:
> I'd like to weigh in on these comments.
>
> routes.py:
> - It seems to me that Django routes are just as complicated:http://docs.djangoproject.com/en/1.1/intro/overview/#design-your-urls
> - Providing the routes.py outside of an app makes sense for web2py since
> it directly maps app/controller/function to a url. This decision was
> made to make things clear and understandable for new developers.
>
> Chinese URLs:
> - perhaps you could have written a patch?
> - (more info:http://en.wikipedia.org/wiki/Internationalizing_Domain_Names_in_Appli...)
> > -https://groups.google.com/group/web2py/browse_thread/thread/e20d0bd2e...
> > - can work with logging
>
> > - tooo magic
> > -http://stackoverflow.com/questions/1999950/download-link-fails-in-ie
> > - auto work in background,but not all clean
>
> > - NULL unittest support!
>
> > - DAL is bad than SQLAlchemy
>
> > - MVC is insulated!
> > - model/control/view all variable is in same name space
>
> > ONLY two feeling good:
> > - deployment is stand alone
> > - but usage yolk+virtualenv others web app. framework also can
> > deplotment stand alone
> > - built-in crontab task support
>
> > PS:
> > translate from: "Mage from hell: ˵˵ web2py"
>> reasons::
>> - bad routes.py
>> - changeless pattern for URL had to base routes.py redirect into short URL
>> - routes.py is out app
>
> The syntax of routes is actually more powerful than Django's (has the
> same syntax for regular expression but for example we provide
> filtering by hostname, client ip, request method and explicit reversed
> routing; Django needs a route entry for evey action, web2py provides
> defaults). I do agree that web2py does not have a way to delegate
> routes to an app. This would me more syntactic sugar than
> functionality and we are working on adding it. I never realized this
> was such a critical point. I will move some resources in getting this
> done.
>
Y just choice...
suggest like RoR, plugin some RESTful URL support into routes.py is cool
and people will study for funny
>> - url can not understand Chinese
>
> No but there is only one line to change to fix this. You can also
> handle this with routes (something you will have to do with Django
> too).
>
yes only one line, as attac. web2py_regex_url.patch
(for fix gluon/main.py regex_url )
but can not smart understand argument/variable from URL is regretful ;
and not alert in manual...
>> - tooo stand alone app
>> - session/static ... is all srand alone
>> - can not easy base app slpit site's components
>
> Not sure I understand
means base web2py app.
each app. only work as stand alone site,
can not work as one site function part, of couse,just choice ...
>
>> - tooo slow boot
>> - import tooo many lib
>
> This can be changed by editing one line in "import_all". The choice to
> import all at the beginning was a design decision, so that we do now
> slow down later requests that request those standard libraries.
yes, there is always ways;
suggest append these skill into manual...
>
>> - error report is tooo ugly
>> - can not support debug easy!
>
> Yes compared with Django and Pylons. But our their reports are
> interactive therefore you ONLY get them if the bog shows up to you
> when logged in as administrator. There is no report if the error
> manifests to a regular use. web2py records all errors and traceback
> and issues tickets to ALL users. that is why our error reports are
> static. You pay a small price in development but get a big benefit in
> production. You choose.
>
Yes another choice, as spe6994web2pydjangoweb_py.zip we patch web2py
can report error like web.py;
at fact, we can config ngix export web2py error report file in :80 for
develop chk online...
just think about who need web app. framework ?
the team need quickly and clean build more and more app. in enterprise;
if just for tech community, eveything is funny, can hacking in happy,
but for work, can not make quicly and clean is disaster for everyone in team...
so online debug is general way...
>> - fighting with build-in module
>> - https://groups.google.com/group/web2py/browse_thread/thread/e20d0bd2e...
>> - can work with logging
>
> Not sure I understand.
chk mail:
https://groups.google.com/group/web2py/browse_thread/thread/e20d0bd2e542aa14
we found web2py can not work with logging module
in code usage logging object to export log is queer ..
so don't know hoe many other python build-in module is web2py not like...
>
>> - tooo magic
>> - http://stackoverflow.com/questions/1999950/download-link-fails-in-ie
>> - auto work in background,but not all clean
>
> The mechanism we provide for upload is the same as Django. We also
> provide a download mechanism that checks for authentication. Perhaps
> this is a bit magic but it is the only way to do it. You do not have
> to use it.
>
Yes we had to change file upload as:
response['header'] = "attachment;"
push file name in URL so can do next...
but also unexpected do some for URL in web2py:
web2py/gluon/main.py:
regex_space = re.compile('(\+|\s|%20)+')
path = request.env.path_info.replace('\\', '/')
path = regex_space.sub('_', path)
for smart work background is good idea;
but in Chinese world, everything is not simple;
because JS/browser/HTTPD... everything is nor support Chinese in nature;
so web2py smart work background is right in ASCII world, is bad in GBK world...
of course, just choice, Chinese team need fixed all clean,
but in business project, no time to found and fixed these magic only
for ACII world
>> - NULL unittest support!
>
> We have unitests in gluon/tests for web2py itself and you can create
> your own unitests for apps in gluon/unitests although for apps we
> think doctests are more practical.
>
>> - DAL is bad than SQLAlchemy
>
> Perhaps but Django does not use SQLAlchemy. Both web2py and Django can
> import SQLAlchemy if necessary but it would not work with generated
> forms (with either). DAL is more powerful than Django (nested selects
> for example).
>
>> - MVC is insulated!
>> - model/control/view all variable is in same name space
>
> Not true. Only models variables are imported in the space of
> controllers and in the space of views. variables defined in
> controllers stay private there. In our view that is what defines a
> model: stuff that should be available everywhere in the app. Show me a
> Django app where the controller (which they call view) does not import
> the models? We just make this default since in practice it is.
>
Yes, this is web2py design,
but for usual, coder is move in form JAVA,
so MVC is another understand...
so usage web2py's MMVC (model/module/view/controllers) will to lose ...
suggest pannend one full simpke exsample in manual for show:
- how to organize web2py app. is good!
- where to mapping DB model is good!!
- where to controller web action is good!!
so make web2py fresher DON'T usage web2py as Django...
--
http://zoomquiet.org 人生苦短? Pythonic!
金山常年招聘Py/C++人才! http://is.gd/6hXIL 简历直投俺就成;-)
Massimo
On Feb 4, 8:12 pm, "Zoom.Quiet" <zoom.qu...@gmail.com> wrote:
> >> -https://groups.google.com/group/web2py/browse_thread/thread/e20d0bd2e...
> >> - can work with logging
>
> > Not sure I understand.
>
> chk mail:https://groups.google.com/group/web2py/browse_thread/thread/e20d0bd2e...
> we found web2py can not work with logging module
> in code usage logging object to export log is queer ..
> so don't know hoe many other python build-in module is web2py not like...
>
>
>
> >> - tooo magic
> ...
>
> read more »
>
> web2py_regex_url.patch
> < 1KViewDownload
>
> spe6994web2pydjangoweb_py.zip
> 435KViewDownload