Yes man!! web2py is very flexible and you need really few lines of code to actually have webapp working that it greatess strengh...
But Joe is right about one point, documentation is pretty dispersed and new undocumented feature are added very often... You have already exposed many of these undocumented features in your presentation at web2py-con last year... Like web2py, and appreciate critical and user feedbask (like Joe's feedback), it helps to improve my web2py uderstranding a lot... Richard On Thu, Feb 5, 2015 at 11:58 AM, Anthony <[email protected]> wrote: > Rather than speaking abstractly about "breaking MVC," it would be helpful > to see code examples along with an explanation of why they are problematic > and how they can be improved. > > I believe one of the motivations behind MVC (or MTV if you prefer the > Django/Flask terminology) is to de-couple independent functions so you can > make changes in one place without worrying about other areas of the code. > In web2py, when you define a model, you can also specify some field > attributes that affect how the data are displayed in forms and grids (e.g., > label, comment, represent, widget). However, moving these definitions to a > controller or view (which web2py certainly allows) does not necessarily > facilitate de-coupling. For example, if you add a field or change the name > of a field in a model, you then have to add or change that field in the > form or grid code in any relevant views as well. This actually makes things > more complicated because you have to track down code in multiple places > when you change the model. > > The advantage of defining some of the display attributes along with the > model definition is that everything related to a given model is in a single > place and will therefore affect all forms/grids based on that model. If you > need to override these defaults for a particular form or grid, you can > easily do so within the controller or view. And if you need to a completely > customized form, you can do so by writing a formstyle function, using > form.custom, or with hand-coded HTML. With the latter two options, if you > need to re-use the form code, you can put it in a template and "include" it > where needed. > > Anthony > > > On Wednesday, February 4, 2015 at 2:44:39 PM UTC-5, Carlos Cesar Caballero > Díaz wrote: >> >> I am agree with many of JoeCodeswell´s points, in my experience, expert >> developers reject web2py mostly because, even in the doc, users are aimed >> to break the mvc writing code in controllers that belongs to models or >> views. >> >> >> El 04/02/15 a las 12:11, JoeCodeswell escribió: >> >> Dear Dave, >> >> Thanks for the reply. I partially agree. I agree that, "SQLFORM already >> takes a lot of the drudgery out of form" [now my words] generation from an >> existing table. However, for me, two things apply to SQLFORM: >> >> 1. It breaks MVC, meaning if *I* want to customize the form *I* do it >> in a Model or in a Controller Action, *not *in a View. Maybe there's >> a way to do this in a View, but *I* don't know how. Here's a couple >> of my blog posts motivated by customizing SQLFORM: >> 1. Easy to Understand web2py Grid Custom Search >> >> <https://joecodeswell.wordpress.com/2014/07/10/easy-to-understand-web2py-grid-custom-search/> >> 2. web2py Field Exegesis >> <https://joecodeswell.wordpress.com/2014/05/05/web2py-field-exegesis/> >> 2. *I* find customization difficult: >> 1. adding buttons >> 2. specifying custom validation >> 3. specifying custom widgets >> >> For points 2.2 & 2.3, updates to the book have helped a lot. Still, the >> form is not specified in a View, at least as far as i can figure out. >> >> Lastly, I want to mention 1 more suggestion/request for improving web2py >> support for web-devs: >> >> Please find a process to keep the book updated with answers given by >> trusted members of the community (Massimo, etc.) given on this group (and >> other groups?). >> My motivation for this request comes from the fact that within the last >> couple of weeks [Jan 2015], i decided to integrate a web2py app with >> Dropbox: >> >> 1. I copied the code from the book-Other Recipes. I got an error for >> which Massimo said, on this group in 2012 >> <https://groups.google.com/d/msg/web2py/R_wPbFtUtc0/sUslRoPeFMQJ>, >> "You need to install: https://github.com/enginous/python-dropbox";. >> which i did. >> 2. Then I got a subsequent error for which Massimo said, on this >> group again in 2012 >> <https://groups.google.com/d/msg/web2py/Y-u_UiNzTFo/AYjwsdJ3QQcJ>, >> "Typo in the book ...". >> 3. There MAY have been other intervening errors of a similar nature. >> >> There was significant effort on my part required to research this >> subject, which, in my estimation, could have been better spent on thinking >> about my user's requirements. >> >> *I consider the book the be web2py's Principles of Operation*. I.e.it >> is the document that specifies the web2py Framework, describing each >> structure/object/function at the level of detail needed to prepare an >> Application Programmer to make apps. I borrowed/modified this definition, >> as an old IBMer, from "z/Architecture Principles of Operation >> <http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a>". >> >> Thanks again, Dave. >> >> Thanks to all for the GREAT Community and Framework. >> >> Love and peace, >> >> Joe >> >> On Monday, February 2, 2015 at 12:55:50 PM UTC-8, Dave S wrote: >>> >>> I find this post to be a lot clearer in terms of understanding what Joe >>> is getting after than the posts earlier in the thread. >>> >>> I'm thinking that SQLFORM already takes a lot of the drudgery out of >>> form design, and so I'm missing what Joe thinks is missing. I haven't used >>> the MS web design tools much (studied Silverlight 1.1 a couple of years >>> ago), so I'm definitely not a power user thereof, so I may not have the >>> perspective to evaluate Joe's request. (I'm also out-of-date in doing >>> Android app dev; that doesn't use Eclipse Galileo anymore, but I think >>> there was some similarity between EG and SL design of the visual side.) >>> >>> /dps >>> >>> On Saturday, January 31, 2015 at 9:01:41 AM UTC-8, JoeCodeswell wrote: >>>> >>>> Dear Leonel, >>>> >>>> I agree that you can and *should* do both. For my web2py projects, I >>>> am BOTH Developer and Administrator, *at* *least initially*, before i >>>> hand it over to my user. >>>> >>>> Regarding *my suggestions to improve* the help web2py gives me with >>>> the *Administration Tasks for my users*, my suggestion is to help *me, >>>> as developer,* customize the web2py Administrative capabilities for >>>> them. Possibly choosing from an easily understood menu of options of say >>>> registration/login types, etc.. >>>> >>>> Regarding *my suggestions to improve* the help web2py gives me with >>>> the *Website Creation Tasks* *for me as a developer*, I'd love, for >>>> example to have a Form Designer that would generate easily >>>> understandable/tweak-able web2py MVC code, to take the repeated drudgery >>>> out of form generation. I am thinking here, of the process i used to use in >>>> Microsoft Development. I would >>>> >>>> - first, use the MS form designer to help me flesh out my user >>>> interface View, making sure to get user buy in, >>>> - and then, hook that/those View(s) up with Model/Controller code >>>> for implementation. >>>> >>>> >>>> Thanks to all for a GREAT discussion. >>>> >>>> Love and peace, >>>> >>>> Joe >>>> >>>> On Friday, January 30, 2015 at 2:17:51 PM UTC-8, Leonel Câmara wrote: >>>>> >>>>> I strongly agree with Massimo on this. By making administrative tasks >>>>> easier you take that burden out of many developers. Not every developer is >>>>> part of a big team that has one guy just to take care of administrative >>>>> stuff. This is very true in the startup market where I think web2py has an >>>>> advantage. >>>>> >>>>> There's also another point, if you make web2py easier to admin it will >>>>> be easier for different hosting platforms to support it, this can take >>>>> even >>>>> more admin tasks out of the developers hands (like pythonanywhere already >>>>> does). >>>>> >>>>> There's no conflict between the two, you can work on features for both >>>>> the developers and the administrators, and specially the poor dudes having >>>>> to wear both hats. In the end it's always good for the developers. >>>>> >>>> -- >> Resources: >> - http://web2py.com >> - http://web2py.com/book (Documentation) >> - http://github.com/web2py/web2py (Source code) >> - https://code.google.com/p/web2py/issues/list (Report Issues) >> --- >> You received this message because you are subscribed to the Google Groups >> "web2py-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
