Question about web2py roadmap.

[JoeCodeswell]

Dear web2py-users,

Here is my question about the roadmap goals for web2py development.

Will the goals for web2py development be oriented to serve
    Web Developers MORE THAN Website Administrators or
    vice versa?

I personally think web2py should serve Web Developers MORE THAN Website Administrators.

However, i think it is often the case that web2py serves Website Administrators MORE THAN Web Developers. I think this is especially true regarding the target users of plugins and wizards.

Thanks for a GREAT framework.

Love and peace,

Joe

[Massimo Di Pierro]

I never thought about it in those terms. I think it serves web developers by taking care of administrative issues for them.

[Richard Vézina]

Joe,

I don't understand the dichotomy of your question? I don't think web2py serve each others as much...

Richard

--
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 web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Vézina]

I mean, 

I think web2py serve each others as much... 

don't, don't go there...

:(

Richard

[JoeCodeswell]

Dear Richard,

Regarding your comment, "I don't understand the dichotomy of your question?".

I have been thinking about it. Here's what i have come up with.

I am a Website Administrator for a  WordPress site that I host because:

• I don't care to write/read/understand ANY WordPress/PHP code in supporting that site.
• I NEVER want to read any source code of the WordPress Implementation Layer because i don't want to understand the above
  
• I just want to "push the buttons" of the Admin Interface and get plugins that work.

I am a Web Developer for the web2py sites that I host because:

• I ALWAYS want to write/read/understand the Application Layer code for my site.
• I want to INFREQUENTLY have to read the source code of the Web2py Implementation Layer to understand the above, preferring instead to work from the Book.
• I want to "push the buttons" (install plugins and/or use wizards) that generate Application Layer code that i can easily understand and that fits within the established norms of a well coded stand alone web2py app.

That's the best i can do at this time in expressing my desires.

Thanks, Richard, for the question.

Thanks to all for a GREAT Framework & Community.

Love and peace,

Joe

[Richard Vézina]

So how could we serve Web Developers better?

Richard

On Thu, Jan 29, 2015 at 2:34 PM, JoeCodeswell <joecod...@gmail.com> wrote:

Dear Richard,

Regarding your comment, "I don't understand the dichotomy of your question?".

I have been thinking about it. Here's what i have come up with.

I am a Website Administrator for a  WordPress site that I host because:

• I don't care to write/read/understand ANY WordPress/PHP code in supporting that site.
• I NEVER want to read any source code of the WordPress Implementation Layer because i don't want to understand the above
  
• I just want to "push the buttons" of the Admin Interface and get plugins that work.

I am a Web Developer for the web2py sites that I host because:

• I ALWAYS want to write/read/understand the Application Layer code for my site.
• I want to INFREQUENTLY have to read the source code of the Web2py Implementation Layer to understand the above, preferring instead to work from the Book.

• I want to "push the buttons" (install plugins and/or use wizards) thatgenerate Application Layer code that i can easily understand and that fits within the established norms of a well coded stand alone web2py app.

That's the best i can do at this time in expressing my desires.

Thanks, Richard, for the question.

Thanks to all for a GREAT Framework & Community.

Love and peace,

Joe

On Tuesday, January 27, 2015 at 11:03:29 AM UTC-8, Richard wrote:

[Niphlod]

In that POV, you'll always identify an "administrator" as a person who "clicks" on existing apps he didn't code and a "developer" of apps someone that "clicks" on fruits of his mind. That's basically comparing oranges and bananas....wordpress is hardly a framework. It's an application that does one job well.
The fact that php+mysql was the defacto standard for web hosters (and the relative lack of "easy blogging" environments) made the spread of wordpress "hacks" and ecosystem rather large, but making wordpress do "whatever" is pretty limited to installing something relatively uncoupled (except for authentication and the common "webpage style"). Moreover, if you don't know the first thing about php, any - little or big - customization you want means trusting someone else that did it.

web2py will hardly replace any known application that already does a job well. It's not a job for a framework but for an app.
No company will adopt web2py as a file sharing platform if a sharepoint farm is already in place, and I won't ever recommend the builtin web2py wiki over mediawiki for a CMS with 10k pages.

If you're fine with it, by all means, be an "administrator". But when you'll need something that no existing thing does (or you can't afford it), be a developer.

[Richard Vézina]

I am not sure where it is going... My understanding, is that Joe explain what he means by admin and devs (that I did already understand in the first place, but he make it clear)... And what I understand, is that he think that web2py help more admins in their day to day work then developers...

If my reading is rights, he wure has suggestion to improve web2py for devs...

Richard

--

[JoeCodeswell]

Dear Richard and Niphlod,

Thanks for your responses. Richard, your understanding is the indeed meaning of what i was trying to express.

Regarding my suggestions for improving web2py support for web-devs, i have 2 suggestions i can think of right now:

• When writing a Plugin or a Wizard or some add-on for web2py ask yourself the question, "Is my intended user a Web Developer or Admin? Will my intended user want to read/understand/modify/tweak my code or use it pretty much as it is?"
  
• Possibly set up a tag to categorize existing add-ons one way or the other (or both?).  
  

I will try to think of more suggestions as they come to me.

Thanks again.

Love and peace,

Joe

[Leonel Câmara]

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.

[JoeCodeswell]

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

[Dave S]

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:

[JoeCodeswell]

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

2. 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, "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,  "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 of Principles of Operation, as an old IBMer, from "z/Architecture Principles of Operation".

Thanks again, Dave.

Thanks to all for the GREAT Community and Framework.

Love and peace,

Joe

[Carlos Cesar Caballero Díaz]

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

2. 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, "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,  "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".

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:

--

[Richard Vézina]

Joe,

Do you know form.custom ?

It allows to customize in view (or controller but begin and end should be present in view) generated form from SQLFORM.

I think, that MVC is not really respected at all in web2py... I think that when there is a possible hack that can brings incredible feature and make dev life easier (at start) this hack get include... This as drawback already stated like missing recongnition from expert programmer...

Still web2py is incredibly handy and useful to start developping a web app rapidly without all the burden of repetitive task dev should do in Django for instance... Where Django suffer from to many plugins, web2py may suffer from be to much integrated... But still, you can import almost any python lib and use it inside web2py...

:)

Richard

[Anthony]

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 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

To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscribe@googlegroups.com.

[Richard Vézina]

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 <abas...@gmail.com> 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:

To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Leonel Câmara]

It also depends on how you choose to look at it. From my point of view the message for a label for a field is part of the model. The only difference is that you aren't putting it in a database (which you certainly could). The view should only be concerned with how to display the label not with the contents.

So from my POV there is no breakage of MVC whatsoever with labels in fields.

[Anthony]

On Thursday, February 5, 2015 at 12:35:35 PM UTC-5, Leonel Câmara wrote:

It also depends on how you choose to look at it. From my point of view the message for a label for a field is part of the model. The only difference is that you aren't putting it in a database (which you certainly could). The view should only be concerned with how to display the label not with the contents.

So from my POV there is no breakage of MVC whatsoever with labels in fields.

Yes, good point. One might say that display related code specific to a given model is properly part of that model, whereas more general display related code (e.g., formstyles) belongs in a separate layer.

Anthony

[Vinicius Assef]

An inline answer.

---- On Wed, 04 Feb 2015 14:11:51 -0300 JoeCodeswell wrote ----
>...

>
>I find customization difficult:
>adding buttons

As you have python in views, you can manipulate server side DOM in your view, i.e add/remove class names, create id for elements, etc. Or you can make it through javascript. It's up to you.

I know it's not the best way, but it is what we can achieve today.

[Anthony]

>
>I find customization difficult:
>adding buttons

As you have python in views, you can manipulate server side DOM in your view, i.e add/remove class names, create id for elements, etc. Or you can make it through javascript. It's up to you.

I know it's not the best way, but it is what we can achieve today.

To add buttons, you don't have to manipulate the DOM, as there is a form.add_button method as well as a "buttons" argument to SQLFORM.

Anthony

[Anthony]

1. I find customization difficult:
1. adding buttons

1. specifying custom validation
2. specifying custom widgets

Can you share examples of what you were trying to achieve and what you tried?

Anthony

[Carlos Cesar Caballero Díaz]

I know that web2py is very flexible, that's why I'm here and i'm working with web2py since almost 4 years, but this is my point, with two examples:

In the very first web2py code example in the manual, in the image blog example, we find this code in the controller:

def index():
    images = db().select(db.image.ALL, orderby=db.image.title)
    return dict(images=images)

Accessing from controller to the dal, in a simple query could not be a problem, but, what happen with a more complex query? With a three or four lines of code query, if we write it every time that we need the data in controllers, we are breaking DRY and MVC. But let´s supouse that we have a simple query like that, and we are using it in many controllers, if in some moment we need to change it, we need to go function by function in controllers to fix the problem. I know that I can put it with a function in the model, but the manual is saying that in web2py, the query goes in the controller.


Another example is in the search function on the simple wiki:

def search():
    """an ajax wiki search page"""
    return dict(form=FORM(INPUT(_id='keyword',_name='keyword',
                      _onkeyup="ajax('callback', ['keyword'], 'target');")),
                      target_div=DIV(_id='target'))

Why create a form that not need any kind of postprocessing, even adding a onkeyup attribute, in the controller, when all this code, following MVC should go in the view?

Well, in my experience, when experienced developers look code like this in the main reference of a framework... their run away scared...

I know that most of this is with the propouse to make web2py easier for begieners, but is a good idea to do this following not recommended programming practices?

Sorry for my bad eiglish, but right now I have not internet access (only mail because ISP problems) and any dictionary at hand...

Cheers.


El 05/02/15 a las 12:22, Richard Vézina escribió:

To unsubscribe from this group and stop receiving emails from it, send an email to web2py+un...@googlegroups.com.
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 web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anthony]

In the very first web2py code example in the manual, in the image blog example, we find this code in the controller:

def index():
    images = db().select(db.image.ALL, orderby=db.image.title)
    return dict(images=images)

Accessing from controller to the dal, in a simple query could not be a problem, but, what happen with a more complex query? With a three or four lines of code query, if we write it every time that we need the data in controllers, we are breaking DRY and MVC. But let´s supouse that we have a simple query like that, and we are using it in many controllers, if in some moment we need to change it, we need to go function by function in controllers to fix the problem. I know that I can put it with a function in the model, but the manual is saying that in web2py, the query goes in the controller.

Does the book actually specifically recommend that all queries go in controllers? If so, can you point that out, as it should be changed.

Anyway, nothing about web2py requires you to put queries in controllers. If it is a single query used in a single action, then sure, put it in the controller. But if you re-use the same query in multiple places, of course you should move it to a model or module -- this is the recommended practice. web2py even allows you to define methods on database tables that execute common queries. I don't see anything wrong with the example above -- there would be no point to moving the query into a model file or module for such a simple example.
 

Another example is in the search function on the simple wiki:

def search():
    """an ajax wiki search page"""
    return dict(form=FORM(INPUT(_id='keyword',_name='keyword',
                      _onkeyup="ajax('callback', ['keyword'], 'target');")),
                      target_div=DIV(_id='target'))

Why create a form that not need any kind of postprocessing, even adding a onkeyup attribute, in the controller, when all this code, following MVC should go in the view?

I agree that could just as easily go in the view, but I don't see the harm in having it here. Because most forms do involve processing/validation, they are typically defined in controllers, so it makes sense to stick with that standard even when no processing is happening. It's odd to say that FORM(...).process() belongs in the controller but FORM(...) without the .process() must go in the view.

Also, keep in mind that the overview chapter is just a relatively simple introductory tutorial. It is not meant to communicate how one ought to architect a large complex application. I'm not saying we couldn't consider changing some of the code examples, but I don't see it as a major indictment of MVC violation.

Anthony

[Richard Vézina]

As a single dev for a relative big app, I tend to put as much stuff as possible in controller because I read and code there all the time, so it is much easier to debug trouble shoot, etc.

I often had to look very long cause a malfunction due to a refactoring because the offending code forgotten in views had not been updated. Just think to form.custom when you add or rename fields to the model... They don't get automatically added to the form.custom (relfecting as I am writting, I could have made form.custom dynamic but not sure about that)...

Also, IDE (PyCharm because it my IDE) not always able to refactor properly code in view even for a simple field renaming...

Richard

On Fri, Feb 6, 2015 at 11:50 AM, Anthony <abas...@gmail.com> wrote:

In the very first web2py code example in the manual, in the image blog example, we find this code in the controller:

def index():
    images = db().select(db.image.ALL, orderby=db.image.title)
    return dict(images=images)

Accessing from controller to the dal, in a simple query could not be a problem, but, what happen with a more complex query? With a three or four lines of code query, if we write it every time that we need the data in controllers, we are breaking DRY and MVC. But let´s supouse that we have a simple query like that, and we are using it in many controllers, if in some moment we need to change it, we need to go function by function in controllers to fix the problem. I know that I can put it with a function in the model, but the manual is saying that in web2py, the query goes in the controller.

Does the book actually specifically recommend that all queries go in controllers? If so, can you point that out, as it should be changed.

Anyway, nothing about web2py requires you to put queries in controllers. If it is a single query used in a single action, then sure, put it in the controller. But if you re-use the same query in multiple places, of course you should move it to a model or module -- this is the recommended practice. web2py even allows you to define methods on database tables that execute common queries. I don't see anything wrong with the example above -- there would be no point to moving the query into a model file or module for such a simple example.
 

Another example is in the search function on the simple wiki:

def search():
    """an ajax wiki search page"""
    return dict(form=FORM(INPUT(_id='keyword',_name='keyword',
                      _onkeyup="ajax('callback', ['keyword'], 'target');")),
                      target_div=DIV(_id='target'))

Why create a form that not need any kind of postprocessing, even adding a onkeyup attribute, in the controller, when all this code, following MVC should go in the view?

I agree that could just as easily go in the view, but I don't see the harm in having it here. Because most forms do involve processing/validation, they are typically defined in controllers, so it makes sense to stick with that standard even when no processing is happening. It's odd to say that FORM(...).process() belongs in the controller but FORM(...) without the .process() must go in the view.

Also, keep in mind that the overview chapter is just a relatively simple introductory tutorial. It is not meant to communicate how one ought to architect a large and sophisticated application. I'm not saying we couldn't consider changing some of the code examples, but I don't see it as a major indictment of MVC violation.

Anthony

--

[JoeCodeswell]

Dear Anthony,

Thanks for ALL your service to web2py and your replies to this discussion.

First, let me state emphatically, I am a grateful user & supporter of web2py.

My questions and comments are my effort to improve it for my Workflow, which is, as i indicated before, View (as in MVC) first.

You asked, "Can you share examples...?".

Here are links to a couple of app pages i remember finding difficult to achieve using my level of understanding of standard web2py techniques, for the version available at development time. To be sure web2py has improved since then.

• ChordMe - Last worked on c. Aug 16, 2012

• Scramble - Last worked on c. Nov 18, 2011      N.B. The "OutBasket Download button appeared and worked at one time."   :)

These apps worked at one time. However, my server has gone through an upgrade from 32 to 64 bits and I have NOT been back to update them. In fact, i just uploaded Scramble from my local machine before finishing this post.

In my workflow, i find that starting with the View my user's will see, hopefully helps me make apps that easily understood by them.

Thanks again, Anthony.

Love and peace,

Joe

[JoeCodeswell]

Dear Anthony,

You said, "And if you need 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."

Thanks, Anthony. I often find I "need a completely customized form".

Is there an example of using a hand-coded HTML form with standard web2py Model/Controller-Action code? I'm sure you know about it if there is.

Thanks, Anthony.

Love and peace,

Joe

[Dan Feeney]

Hi Joe,

When I needed to create a custom form, I followed this: http://web2py.com/books/default/chapter/29/07/forms-and-validators#Custom-forms

I still used the widgets serialized by the web2py model code and only modified the layout. However, it looks like they have some helpful goodies in the form.custom collections to help out folks like you who want to do all custom form markup in their views.

HTH,
-Dan

[Anthony]

Just use pure HTML as usual and (a) make sure the "name" attributes of form fields correspond to the names of your database table fields, and (b) at the end of the form, include the following:

{{=form.custom.end}}

in place of:

</form>

form.custom.end includes the two hidden fields used by web2py for form processing as well as the closing form tag.

You might find, though, that you can handle most custom forms via the method discussed here: http://web2py.com/books/default/chapter/29/07/forms-and-validators#Custom-forms.

Anthony

[Anthony]

You asked, "Can you share examples...?".

Here are links to a couple of app pages i remember finding difficult to achieve using my level of understanding of standard web2py techniques, for the version available at development time. To be sure web2py has improved since then.

• ChordMe - Last worked on c. Aug 16, 2012

• Scramble - Last worked on c. Nov 18, 2011      N.B. The "OutBasket Download button appeared and worked at one time."   :)

Without seeing the code and data model, it's not quite clear what the difficulty is here. How would you envision web2py changing to make the creation of these pages easier?

Anthony

[Julio F. Schwarzbeck]

Anthony, your last paragraph is quite interesting. I work for a large corporation, which for good or bad, has back-end web programmers, but also simple html designers. The concept of embedding HTML helpers A(), FORM() in controllers, or modules is frowned upon and it was one of the main reasons they almost dropped the platform altogether since the perception was that the developers would end up making a "mess" and leave the designers with an interface that is very hard to customize if you don't know python for example.

I personally do not use html helpers *at all*, but I can see why for some folks it can be a time saver.

Nowadays, I am designing more for mobile than for the desktop, and I am moving web2py to a new paradigm, I am providing the UI entirely for example via jQuery Mobile, or Kendo, and use web2py as an API, service oriented application framework, I find the html helpers are even less needed in this context, as web2py provides me with data abstractions and not view components, and for the MVC/MTV zealots, that is actually a good side effect, heck, even desktop web apps are now becoming "single page" (think facebook, tweeter, etc).

I am comfortable where web2py is heading, it is becoming a large framework, and every developer must evaluate what parts of the framework you want (or need) to use.

I think one of web2py's main "problems" (as seen from many of their detractors), is that it allows the newbie to very easily create database-driven applications - sometime large ones - in which basic software engineering principles are not applied correctly (or at all), this include antipatterns such as the "god" class, asynchronous gotchas and the like, I am not saying you cannot do them in other platforms, but it is "easier" in web2py.

On Friday, February 6, 2015 at 8:50:41 AM UTC-8, Anthony wrote:

..snip..

Another example is in the search function on the simple wiki:

def search():
    """an ajax wiki search page"""
    return dict(form=FORM(INPUT(_id='keyword',_name='keyword',
                      _onkeyup="ajax('callback', ['keyword'], 'target');")),
                      target_div=DIV(_id='target'))

Why create a form that not need any kind of postprocessing, even adding a onkeyup attribute, in the controller, when all this code, following MVC should go in the view?

I agree that could just as easily go in the view, but I don't see the harm in having it here. Because most forms do involve processing/validation, they are typically defined in controllers, so it makes sense to stick with that standard even when no processing is happening. It's odd to say that FORM(...).process() belongs in the controller but FORM(...) without the .process() must go in the view.

Also, keep in mind that the overview chapter is just a relatively simple introductory tutorial. It is not meant to communicate how one ought to architect a large complex application. I'm not saying we couldn't consider changing some of the code examples, but I don't see it as a major indictment of MVC violation.

Anthony

[Anthony]

I personally do not use html helpers *at all*, but I can see why for some folks it can be a time saver.

I lean towards sticking with HTML, but there are cases where the helpers are useful -- see http://stackoverflow.com/questions/8091487/what-are-the-benefits-of-building-html-markup-with-html-helpers-in-web2py/8095585#8095585.
 
Anthony

[Massimo Di Pierro]

I am sorry people read example like this and do not understand it. All web frameworks have helpers (Rails does, Django does, etc.) and helpers are to be used in views. Web2py helpers are quite useful because they provide a complete extensible set (other frameworks do not do that) and they can be used in views very much like one would use HAML to generate HTML.

HTML:

<section class=”container”>

  <h1><%= post.title %></h1>

  <h2><%= post.subtitle %></h2>

  <div class=”content”>

    <%= post.content %>

  </div>

</section>

HAML:

%section.container

  %h1= post.title

  %h2= post.subtitle

  .content

    = post.content

WEB2PY:

{{

=TAG.section(

  H1(post.title),

  H2(post.subtitle),

  post.content

  , _class='container')

}}

Now the fact that one can use them in controllers does not mean one should do that.

Let me put it in another way. We give you a toolbox. We show you that our wrench is very strong by smashing it a hummer. That does not mean the purpose of the wrench is to be smashed with a hummer. A good developer should be able tell.

[Vinicius Assef]

Actually, the labels are part of the visualization layer. HTML widgets and CSS classes, as well.

By definition, the model doesn't need the label to anything. Take a webservice as an example, doesn't have a form to present. Does the model need it?

So, we conclude the label (and other artfacts) don't belong to models, but to the visualization layer.



---- On Thu, 05 Feb 2015 14:35:35 -0300 Leonel Câmara<leonel...@gmail.com> wrote ----

> It also depends on how you choose to look at it. From my point of view the message for a label for a field is part of the model. The only difference is that you aren't putting it in a database (which you certainly could). The view should only be concerned with how to display the label not with the contents.
>
> So from my POV there is no breakage of MVC whatsoever with labels in fields.
>
>
>
>

[pa...@cancamusa.net]

On Sunday, February 8, 2015 at 5:51:15 AM UTC+1, Massimo Di Pierro wrote:

Now the fact that one can use them in controllers does not mean one should do that.

But the FORM helper is extensively used in the controllers in the web2py manual. And complex forms usually contain tables, or may be laid inline with bootstrap, or have buttons or other controls which improve if you add the css classes, so I end up using helpers in the controllers more than what the canon seems to recommend. Workarounds like using custom forms seems to be very verbose, harder to read and less documented. What is the canonical way to turn a sample form like this one in the manual:

form=FORM('Your name:', INPUT(_name='name'), INPUT(_type='submit'))

into a real-world bootstrap-compatible form:

form=FORM(LABEL('Your name:', _for='name'), INPUT(_name='name', _class='form-control', _placeholder='Name Surname'), INPUT(_type='submit', _class='btn btn-primary'))

I'm gradually wrapping complex views into new helpers, and placing them inside modules. But I have code like the above all over my app: What's the web2py best practice?

Regards

[Anthony]

By definition, the model doesn't need the label to anything.

I'm not sure there is a canonical definition to which we can appeal.
 

Take a webservice as an example, doesn't have a form to present. Does the model need it?

Just because one consumer of a model doesn't require a particular attribute does not mean that attribute doesn't belong to the model. The webservice might not need the model's validators either, but that doesn't mean the model shouldn't have validators.

[Carlos Cesar Caballero Díaz]

> Does the book actually specifically recommend that all queries go in
> controllers? If so, can you point that out, as it should be changed.
>

No, but in all examples, queries are in controllers, sufficient for a
reader to infer that.

> Anyway, nothing about web2py requires you to put queries in
> controllers. If it is a single query used in a single action, then
> sure, put it in the controller. But if you re-use the same query in
> multiple places, of course you should move it to a model or module --
> this is the recommended practice.

True, but in addition to what I said earlier, the book even mentioned

> I agree that could just as easily go in the view, but I don't see the
> harm in having it here.

Because it confuses the designers, who on many occasions not know python
or web2py, this makes a big difference when you are working alone, but
complicated when a third party needs to make changes

--
Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas

Infomed: http://www.sld.cu/

[Anthony]

On Monday, February 9, 2015 at 8:55:47 AM UTC-5, Carlos Cesar Caballero Díaz wrote:

> Does the book actually specifically recommend that all queries go in
> controllers? If so, can you point that out, as it should be changed.
>

No, but in all examples, queries are in controllers, sufficient for a
reader to infer that.

Can you point to an example of a query in the book that you think should instead have been shown in a model?
 

> I agree that could just as easily go in the view, but I don't see the
> harm in having it here.
Because it confuses the designers, who on many occasions not know python
or web2py, this makes a big difference when you are working alone, but
complicated when a third party needs to make changes

Of course, if you are working with designers who don't know and are not interested in learning Python, it makes sense to keep as much as possible in pure HTML. But that is not the only context within which web2py is used. If you don't want to use the HTML helpers, you don't have to, but that doesn't mean they should not appear in any book examples.

Anthony

[Carlos Cesar Caballero Díaz]

What about some kind of views code generator for "advanced" developers or teams?, all the form generation is implemented, so, should be relatively easy write something like that, that generate an html form from the model (or controller) to a view.

Cheers.

El 08/02/15 a las 17:38, pa...@cancamusa.net escribió:

[Richard Vézina]

I don't think "God" class is a big concern in web2py... End user don't really need to write class... Sure you can, but since page is tide to a function and you have controllers files that you can use as an class like container to regroup your stuff. Sure I could write class, but considering work and progress nature of my dev, it difficult to predict what shoudl do my class in advence... So, writting class would lead me more in YAGNI state of thinking than in concrete problem solution.

Richard

--

[Carlos Cesar Caballero Díaz]

Can you point to an example of a query in the book that you think should instead have been shown in a model?

All of them, or at least mention that queries should go in controllers, even a simple query, will represent a problem, if we need to change it and is used many times, new users, that read the image blog and simple wiki examples, should explicitly known that in web2py, the recommended way is putting the queries in models (or modules), all this in my opinion of course.

Of course, if you are working with designers who don't know and are not interested in learning Python, it makes sense to keep as much as possible in pure HTML. But that is not the only context within which web2py is used. If you don't want to use the HTML helpers, you don't have to, but that doesn't mean they should not appear in any book examples.

We are moving away a bit from the main point, imagine that I made an application and my designer is learning how web2py views work and how helpers are used (which is exactly what is happening to me now), my designer does not have to look at the controllers, that is the goal of MVC, if I'm going to make changes in views, I do not have to know what is happening in the controllers. In the example that i mentioned, how I ask to a designer that modify a view that says:

{{extend 'layout.html'}}
{{=form}}

Web designers normally know html and css, and if there is a way to easily separate views and controllers, then web2py is going to be easily adopted in teams with specialized members. But if I read in the main doc examples with view related code in controllers, then I not adopt the framework.



When I started web2py also started with web development. But now, with the little experience I have, if I started from scratch using python, and read the book of web2py, I would go for another framework (Just after the Overview chapter), and would be a shame, because the documentation does seem to web2py one thing that it's not

[Richard Vézina]

So, documentation should be improve!!

Alone dev practices

Team dev pratices

Examples

What should go where

Richard

[António Ramos]

Documentation is important not only to find info but also to catch newcomers eyes.

I hate to navigate on the online book and loose the index.

i have to SCROOLLLLLL to the top countless times.So easy to fix right ?

The documentation is very good but not very easy to deal with.

I think web2py needs a good ui designer from the online site to the admin app.

The underground  from the DAL to the scheduler is another story. 

Regards

[Anthony]

On Monday, February 9, 2015 at 10:49:10 AM UTC-5, Carlos Cesar Caballero Díaz wrote:

Can you point to an example of a query in the book that you think should instead have been shown in a model?

All of them, or at least mention that queries should go in controllers, even a simple query, will represent a problem, if we need to change it and is used many times, new users, that read the image blog and simple wiki examples, should explicitly known that in web2py, the recommended way is putting the queries in models (or modules), all this in my opinion of course.

I disagree that all queries belong in models. A complex query that needs to be re-used in multiple places should go somewhere centralized (not necessarily a model file, but perhaps a module). However, not all queries need to be re-used. Furthermore, some queries are so simple, there is no point in abstracting them into a re-usable function/class (e.g., selecting all records and fields from a single table).

Of course, if you are working with designers who don't know and are not interested in learning Python, it makes sense to keep as much as possible in pure HTML. But that is not the only context within which web2py is used. If you don't want to use the HTML helpers, you don't have to, but that doesn't mean they should not appear in any book examples.

We are moving away a bit from the main point, imagine that I made an application and my designer is learning how web2py views work and how helpers are used (which is exactly what is happening to me now), my designer does not have to look at the controllers, that is the goal of MVC, if I'm going to make changes in views, I do not have to know what is happening in the controllers. In the example that i mentioned, how I ask to a designer that modify a view that says:

{{extend 'layout.html'}}
{{=form}}

Web designers normally know html and css, and if there is a way to easily separate views and controllers, then web2py is going to be easily adopted in teams with specialized members. But if I read in the main doc examples with view related code in controllers, then I not adopt the framework.

The first two examples in the tutorial show forms in pure HTML. Furthermore, in the forms chapter, there is a section on using HTML for forms as well as a section on custom forms, which shows how you can use custom HTML but still take advantage of some attributes provided by the FORM helper. I think it would be fine to add some verbiage to the book making it more explicit that these techniques might be particularly beneficial when working with designers (e.g., "If you are working with designers who only know HTML, you might want to lay out your forms via the methods described in the Custom Forms section."). That doesn't mean it's wrong to have some examples showing the use of helpers.

Also, encountering {{=form}} in a template doesn't have to stop a designer from contributing. If the form is laid out as desired via {{=form}}, then the only thing the designer need touch is the CSS. On the other hand, if the form is not laid out as desired via {{=form}}, then you need custom HTML anyway, and at that point, the designer can just go ahead and implement the HTML in the template (which you might later abstract into a custom formstyle function).

Anthony

[Vinicius Assef]

---- On Mon, 09 Feb 2015 09:40:42 -0300 Anthony wrote ----

Yes, the webservice need them. To insert, update and delete, data need to be validated.

See, it seems I'm being purist, but I tend to be pragmatic. I like Web2py a lot and it's because I like the general way it works. Some aspects I dislike but I don't have a good alternative approach to suggest.

[Vinicius Assef]

---- On Sun, 08 Feb 2015 01:51:15 -0300 Massimo Di Pierro<massimo....@gmail.com> wrote ----
> ...

> Now the fact that one can use them in controllers does not mean one should do that.

You're right, but sometimes we need to generate HTML from controllers. I.e, when we use SQLFORM.grid() with custom links for each row.

The chance to use helpers in controllers is very useful in this case. Otherwise we should create dinamic links with server-side DOM or with javascript. It would bring unecessary complexity.

I don't usually use helpers in controllers, but I prefer being a pragmatic than a purist. As you pointed out, Web2py allows us to do it and it is very good. :-)

[Massimo Di Pierro]

In any framework I know of helpers are developed using the language of the framework (here for example about Django http://stackoverflow.com/questions/1912351/django-where-to-put-helper-functions)

In web2py I would put them in a module and import them where necessary.

In web2py you can also use views to define forms since you can can calls response.render(...) insider your helper functions.

def myhelper():

     # do your logic and define your vars, for example d

     return response.render('myhelper.template.html', d=d)

[Anthony]

> Take a webservice as an example, doesn't have a form to present. Does the model need it?
>
>Just because one consumer of a model doesn't require a particular attribute does not mean that attribute doesn't belong to the model. The webservice might not need the model's validators either, but that doesn't mean the model shouldn't have validators.

Yes, the webservice need them. To insert, update and delete, data need to be validated.

A read-only webservice does not need validation. Anyway, the point was that the model need not be defined as the minimal set of attributes required by any given consumer.

Anthon

[Carlos Cesar Caballero Díaz]

I disagree that all queries belong in models. A complex query that needs to be re-used in multiple places should go somewhere centralized (not necessarily a model file, but perhaps a module). However, not all queries need to be re-used. Furthermore, some queries are so simple, there is no point in abstracting them into a re-usable function/class (e.g., selecting all records and fields from a single table).

Apps grow in time and we never known if in a future we will need to reuse a query, what happen if a client, in some moment decides that he don´t want to work with the data of more than one year ago, but it should remain in the DB? (Because so much data bothered and there is other software for data analisys) Then will be necessary to change so simples queries one by one.

The first two examples in the tutorial show forms in pure HTML. Furthermore, in the forms chapter, there is a section on using HTML for forms as well as a section on custom forms, which shows how you can use custom HTML but still take advantage of some attributes provided by the FORM helper. I think it would be fine to add some verbiage to the book making it more explicit that these techniques might be particularly beneficial when working with designers (e.g., "If you are working with designers who only know HTML, you might want to lay out your forms via the methods described in the Custom Forms section."). That doesn't mean it's wrong to have some examples showing the use of helpers.

Also, encountering {{=form}} in a template doesn't have to stop a designer from contributing. If the form is laid out as desired via {{=form}}, then the only thing the designer need touch is the CSS. On the other hand, if the form is not laid out as desired via {{=form}}, then you need custom HTML anyway, and at that point, the designer can just go ahead and implement the HTML in the template (which you might later abstract into a custom formstyle function).

Yes, but why not in the first two examples? (the image blog or the simple wiki)


I do not really like to continue this discussion, from the beginning I just wanted to comment on the reasons why some experienced web developers I know have rejected web2py after reading only part of the manual.

Cheers.

[Richard Vézina]

Carlos,

You bring good points to consider and Anthony brings some perspective too. I don't think there is a single answer here, but I think that web2py allows someone to do what is right to do depending of the context... The fact that the book may be misleading if you applied simply it examples can be fixed. So your comments have been heard and will serve to improve documentation.

Richard

--

[Anthony]

I disagree that all queries belong in models. A complex query that needs to be re-used in multiple places should go somewhere centralized (not necessarily a model file, but perhaps a module). However, not all queries need to be re-used. Furthermore, some queries are so simple, there is no point in abstracting them into a re-usable function/class (e.g., selecting all records and fields from a single table).

Apps grow in time and we never known if in a future we will need to reuse a query,

True, but you can always abstract the query the first time you need to re-use it. It would be overkill to assume every query used anywhere will ultimately need to be re-used and therefore add the extra boilerplate up front, when in most cases it won't be needed.
 

what happen if a client, in some moment decides that he don´t want to work with the data of more than one year ago, but it should remain in the DB? (Because so much data bothered and there is other software for data analisys) Then will be necessary to change so simples queries one by one.

Well, in this specific case, you would just add a common filter to the table. More generally, though, I would say just re-factor when that happens rather than pre-maturely optimizing for every conceivable possible future need. Note, there is nothing special about queries in this regard -- this same logic would apply to any bit of controller code, which you can always imagine might need to be re-used somewhere.

I'm not saying you would never move queries to controllers or modules, and we could certainly add some examples (actually, I don't think table methods are even documented, so that would be a good place to raise this issue), but I reject the idea that queries never belong in controllers and that the book examples therefore represent bad practice. If we abstracted all the queries into centralized functions/methods, then we might have a different set of people complaining about all the extra boilerplate and unnecessary abstraction in web2py code.

 

I do not really like to continue this discussion, from the beginning I just wanted to comment on the reasons why some experienced web developers I know have rejected web2py after reading only part of the manual.

I would be interested to hear more from them. Did they reject Django and Flask, whose documentation also shows examples with queries in controllers? I would also be interested to know if they thought that because the examples show queries in controllers, it is therefore technically impossible to create queries elsewhere.

Anthony

[Julio F. Schwarzbeck]

I beg to disagree, or perhaps I did not clarify in my original posting. Down in this thread, I believe someone mentions that (re)used helpers (could) go in modules, which I agree by the way, what I meant to say is that in a potentially complex application, where many common components are usually required, placing the code in a controller, which is tied up to a view would not be the best place to put it, and neither on a model for that matter, therefore new devs tend to "throw" these functions into the module file, whether is wrapped up in a class or not, and at the end of the day having a "function repository" equivalent of the god class pattern. Yes, this can happen on every framework, etc, etc, my point is (was) that it is much easier to fall in web2py.

Also, even though I have said that I don't use helpers in my projects, there is one that I use extensively because it provides a huge advantage when rewriting URLs URL() that is, and for a designer, seeing something like <a href="{{=URL('view.html')}}">Click Here</a> does not look too strange, so there you go, helper functions *do help* sometimes :)