Ahmed, Ok I understand now point 2. I think that is "dependency injection" and "inversion of control", web2py uses it. The problem you mention is real: debugging is harder because you don't know where things come from. This is common to programs that uses IoC, but is good for code reuse and unit testing (of web2py framework itself).
2010/8/2 Ahmed Soliman <ah...@farghal.com> > 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. >
