Thanks Ahmed for the clarifications. Having feedback from users is very important. :-)
On Aug 2, 5:51 am, Ahmed Soliman <ah...@farghal.com> wrote: > Ok, I would like to elaborate more on the points I've mentioned. > > 1- Web2py does not support unit testing out of the box and if you want > to hack everything to get unit testing well integrated you can but > this still doesn't mean the framework support unit testing, and by > that I mean the ability to test complete scenarios, have you tried to > write a unit test for controller that has SQLFORM in it? the double- > submission check will make your life miserable if you tried to do unit > tests that simulates form submissions. Also you will need to do a lot > to create correct fixtures that would bring the web2py environment up > and down before and after every test. Plus, there is no selenium > testing integration like how other frameworks do. > > 2- By saying "twisted" means that you have things that are > automagically imported for you and many things are imported by default > according to import_all, also you have a lot of variables like > "response, request, session, etc." that are magically inserted into > the execution environment, such design is OK but not Good, as I can't > see the context and there is a little of referential transparency in > there. You can't see what's being passed or imported, neither the IDE. > > 3- In error reporting, If you tried to write a mistake in the > template, the question is, does it show you the error "correctly"? > does it show you the right line number as in your source file? > 4- About the DAL and not ORM, that's OK and I understand that you > chosen the DAL choice based on your experience with ORMs but from my > personal point of view that your implementation of DAL is too close > from being an ORM but without a decent way of defining the entities, > you simply nest everything into a possibly one or more calls to create > tables with validators in a pure functional way. My problem with that > is that "flat is better than nested" and the code becomes scattered > especially in the model > > 4- Yes, I already explained that CPython implementation is the real > limitation and not web2py, this is a python-related issue and not > web2py but still web2py is affected. > > 5- Yes, Python does work on Eclipse, IntelliJ, etc. but does web2py > work smoothly and easily? for instance, to get web2py working > correctly on eclipse (PyDev) you will need to put stupid nonsense > imports ( if 0: import ) on the top of every file because of the > "magic" I mentioned before., you will need to manually redefine > request, response, session, etc. variables in that dummy if condition. > You don't get proper auto completion because almost everything happen > in the runtime (like dicts masked as attributed objects). So, simply, > By design no IDE can help you much unless we hardcoded much of that > stuff into the IDE itself. > > 6- I also would like to add that the current design on the plugin > system, looks more like a hack rather than a modular, conflict-safe > scalable system. > > Btw, I still like web2py very much and I would like to contribute when > possible on making things better but that might include general > philosophy changes.1 > > Thanks for the great community. > > On Aug 2, 12:36 pm, Michele Comitini <michele.comit...@gmail.com> > wrote: > > > Massimo since you are a real gentleman you have been too polite... ;) > > > DAL vs ORM: the fact that DAL uses a clean functional approach does not mean > > that is not OO... > > > "Python magic was all over the place, variables defined globally are > > allover, you cannot see real OO in the design" > > > I only agree that Python is magic, but that is the only thing I agree with. > > Probably a long exposure to COO (Class Object Oriented languages > > such as java) causes this misunderstanding with Python beginners. Indeed > > Python is a truly OO languages and web2py uses that. > > > Ok enough... > > > ciao, > > mic > > > 2010/8/2 mdipierro <mdipie...@cs.depaul.edu> > > > > This was my response. It is awaiting moderation: > > > > Hello Ahmed. Nice article. > > > > A few comments: > > > web2py runs with Jython. We just consider CPython the reference > > > platform. There is a known bug in the Java regex library that sun > > > marked as wontfix that can cause occasional runaway problems with > > > parsing templates in Jython. It is not a web2py specific issue but I > > > thought I'd mention it. > > > > You can use unit tests with web2py. web2py it self has unit tests in > > > the gluon/tests folder. You can run unit tests for your apps from the > > > shell (as you would do in other Python frameworks) although you cannot > > > run them through the web IDE. The web IDE only supports doctests and > > > you are correct about that. > > > > Web2py is known to work with WingIDE, Eclipse and IntelliJ. > > > > It is true that web2py does not distinguishes production from > > > debugging mode but to clarify: this is because webp2y always in > > > production mode yet it always logs all the errors. If the current user > > > is logged in as administator he/she has access to the error tickets > > > and error tracebacks. > > > > Web2py follows PEP8 internally but it does not import application > > > code, executes it. In this environment it exposes some symbols. Some > > > symbols are per-http-request. Some symbols are system wide. The latter > > > are all caps because should be treated as constants and not modified. > > > I feel this is consistent with PEP8. The naming scheme is explained in > > > the first chapter of the manual. > > > > You are also right that web2py has a DAL, not an ORM. The main > > > difference is that in a ORM a table is a class and a record is an > > > instance of that class. In the web2py DAL the table concept is a class > > > but each table is an instance and each record is a dictionary. In my > > > view both approaches are object oriented. For example this is a query > > > with the web2py DAL: > > > > for row in db(db.mytable.myfield>0).select(): print row.myfield > > > > and this the same query with the Django ORM: > > > > for row in Mytable.objects.filter(myfield__lt=0): print row.myfield > > > > In my opinion the former looks more OO than the latter.
