Re: notes on welcome3

[Massimo DiPierro]

I apologize. I had not seen this: https://github.com/niphlod/welcomebs3

I like the layout.hml. I like the custom widgts. I like mdernizr+respond (I assume you tested the problem below PS does not arise). I am fine with this (https://github.com/niphlod/welcomebs3/blob/master/models/bs3_helpers.py) but it should be modules/plugin_bs3.py

This is what I have problems with: 

fixup_bs3_widgets(SQLFORM)

this will affect all the apps. I think the current reponse.ui = {…} method is better. We could pass the list of widgets to it.

Massimo

[Niphlod]

the whole point is that it affects ONLY the app where that piece of code is run.

[Leonel Câmara]

I think the problem with response.ui and a lot of these solutions, is that for very request I will have to be setting all of the UI again, this seems awfully inefficient to me.

[Michele Comitini]

Would be better if the response.ui = <a python module> ?

2015-03-13 17:54 GMT+01:00 Leonel Câmara <leonel...@gmail.com>:

I think the problem with response.ui and a lot of these solutions, is that for very request I will have to be setting all of the UI again, this seems awfully inefficient to me.

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Massimo DiPierro]

No it does not. This

def fixup_bs3_widgets(SQLFORM):
	SQLFORM.widgets.string = BS3StringWidget
	SQLFORM.widgets.text = BS3TextWidget
	SQLFORM.widgets.boolean = BS3BooleanWidget
	SQLFORM.widgets.date = BS3DateWidget
	SQLFORM.widgets.time = BS3TimeWidget
	SQLFORM.widgets.datetime = BS3DatetimeWidget
	SQLFORM.widgets.integer = BS3IntegerWidget
	SQLFORM.widgets.double = BS3DoubleWidget
	SQLFORM.widgets.decimal = BS3DecimalWidget
	SQLFORM.widgets.password = BS3PasswordWidget

changes SQLFORM for all the apps.

[Massimo DiPierro]

This is a long discussions that went back one year. I got lost in it a few times. There are some goals we all agree on (correct me if I am wrong):

1) the responsibility of styling forms, menus and navbar rest with the apps, and we should not bloat web2py with this code

2) we want to ship a default web2py welcome with bs3

3) we have two code bases:

(a) https://github.com/web2py/web2py/tree/master/applications/welcome3

(b) https://github.com/niphlod/welcomebs3

What are the differences:

4) (b) has a sticky footer. (a) does not. I like (a) better because the sticky footer overlays the text on small screens

5) (b) merges modernizer and respond in a single js file, (a) does not. That is because this post http://stackoverflow.com/questions/8273845/modernizr-with-respond-js suggests that (b) does not work. I do not have a IE7 machine to confirm so I am playing it safe. If somebody confirms (b) works for IE7, I am ok with it.

6) (a) has an optional jumbotron while (b) does not. I have the jumbotron in most of my landing pages but I do not have a strong opinion about this.

7) (a) has a combination of <link>&<script> and {{response.files.append(…)}} (b) uses the latter more systematically. I do not have a strong opinion about this but to me it is about separation of concerns. response.files should contains files that can be changed by a plugin and do not break the css. <link>&<script> should be used explicitly when required by the layout.

8) (a) uses the default web2py widgets but has some CSS to fix the navbar and other idiosyncrasies. (b) does not uses the navbar, has explicit code to render it in layout, the login options are not in a drop-down. (b) has its own function for rendering menus.

9) the most important difference is this:

(a) does response.formstyle = ‘bootstra3-inline’

(b) does fixup_bs3_widgets(SQLFORM)

None of these approaches is perfect but:

(a) form, navbar, grid and menu work well now and have the proper style. (b) forms & grid do not work at all for me. Do they for you? I am missing something?

(a) requires a single setting which only affects the current app. (b) in my understanding changes the default for the SQLFORM class and this can have concurrency issues.

I like the fact that (b) has lots of widgets overwritten for BS3 but really all they do is replace class names. So we have lots of python code for something that can be done by the formstyle in one place and or one line of JS.

A third mechanism has been proposed (response.ui). I am fine with it. It could be a compromise that allows overwriting formstyle, widgets, menu, and navbar in a single place. If I understand Anthony is working on it. Yet I do not believe the scaffolding app should come with tons of extra scaffolding code.

Please send your comments. I am hoping that we will end with two options and we can have a vote on this issue next week. I want to release a new web2py version asap.

Massimo

[Leonel Câmara]

Massimo, note that the fixup function is being called every time theres a request on menu.py, that's 10 assignments and much more lookups to get the things to assign to per request. This has to be done every request because SQLFORM starts its life every request with the wrong stuff assigned there.  

  

I think the better solution would be for people to have themes in their app, the themes would have, among other things, a subclass of SQLFORM and have everything set for them right away as SQLFORM also includes the grid.

[Massimo DiPierro]

On Mar 13, 2015, at 12:50 PM, Leonel Câmara <leonel...@gmail.com> wrote:

Massimo, note that the fixup function is being called every time theres a request on menu.py, that's 10 assignments and much more lookups to get the things to assign to per request. This has to be done every request because SQLFORM starts its life every request with the wrong stuff assigned there.  

What concerns me is that in a high concurrency setting this is not thread safe. The helpers are capitalized for a reason. They are to be treated as constants. Changing their state is not thread safe.

  

I think the better solution would be for people to have themes in their app, the themes would have, among other things, a subclass of SQLFORM and have everything set for them right away as SQLFORM also includes the grid.

[Massimo DiPierro]

About the grid. In my view the grid is crap. It is one giant load of bloated code. In my view we need to get rid of SQLFORM and move to a new and more modular Form and Grid objects. Spending time in making the current code more complex is the opposite of what we want. We want to make it simpler. Also we want to make a new Form and Grid that is not web2py specific and can lay the foundation of a new webXpy.

On Mar 13, 2015, at 12:50 PM, Leonel Câmara <leonel...@gmail.com> wrote:

Massimo, note that the fixup function is being called every time theres a request on menu.py, that's 10 assignments and much more lookups to get the things to assign to per request. This has to be done every request because SQLFORM starts its life every request with the wrong stuff assigned there.  

  

I think the better solution would be for people to have themes in their app, the themes would have, among other things, a subclass of SQLFORM and have everything set for them right away as SQLFORM also includes the grid.

[Leonel Câmara]

I'm open to that, web2py needs some refactoring in my opinion, particularly, I think web2py code needs to be more object oriented, because we have a lot of cases of classes with huge methods, if you look at why the methods are huge it's always because they have a bunch of if's to check what they really are, a prime example of that is class Session which is horrible, another is class Auth which frankly I'm afraid to touch nowadays. Inheritance has provided the solution to better structuring that kind of code a long time ago.  

  

It's normal that things like this happen, because people want to add features and the easiest way is to sprinkle a few ifs but I think we are reaching a point where we have to repay some of our technical debt.  

  

That said, we need a decision on which way to go ASAP.

[Massimo DiPierro]

Let’s separate the problems.

1) BS3 we need to bring to the market asap. It does not have to solve problem 2.

2) refactoring sqlhtml.py or (better) deprecate it and move to something better. There was attempt some time ago: https://github.com/mdipierro/web3py/blob/master/web3py/forms.py I still think the presentation should be ll done in CSS+JS and not in python, unless the brower does not support JS.

[Massimo DiPierro]

right now, in my view only sqlhtml is messy. The dal code is pretty good. The template is good. The helpers are verbose but ok. The logic in main+restricted+htttp is convoluted but I would not touch files that have not needed to be touched in ages.

On Mar 13, 2015, at 1:36 PM, Francisco Tomé Costa <ma...@franciscocosta.com> wrote:

I agree with Leonel,

Code should be clean, well documented and easy to maintain. When things get bigger they start to get messy.

Francisco Tomé Costa

+351 918412636

https://www.linkedin.com/in/franciscocosta​

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Niphlod]

NB: there's a reason why I presented welcomebs3 as a POC, and not as a final plan.

I layed out the ideas in pretty much all the discussions had so far, and the same exact things continue to pop up:
- default widgets can't be adapted for every framework, so we should have them shipped in app's "department" instead of core
- handling readable = False fields as disabled inputs instead of DIVs
- grid and smartgrid needs refactoring
- "themes" support
- MENU does it job but at a high cost, almost impossible to craft to every framework
- auth forms needs additional care (think to what form.add_button() does........)
- form.errors handling makes sense only for a pretty restricted set of ui design
- etc

IMHO the rush of pushing bs3 scaffolding is unjustified at the current state, given that every discussion we had ended in pretty much nothing. We should seize the opportunity, bite the bullet and see what changes need to be made to slip in a whole new set of css rules.
There's a reason to it: everyone feels that touching the code would end up in yet another attempt to make it more complex, won't solve the "css framework lock-in" and nobody feels like doing everything in javascript on the view, and use web2py only as the MC, because at that point most of the "batteries included" arguments don't matter at all. Customizing forms with lots of js may solve the issues at hand with all defaults, but they'll make impossible to hack in a bit, resorting to code the entire form by hand.

having only response and request object to rely upon to make everything "thread-safe" is another point that pops up, but I feel that appconfig.py (or anything else like that) could solve the issue (i.e. set there some "verbose" settings loaded once-per-app in order to not repeat them in code over and over, while keeping flexibility).

While I agree on refactoring, I still see lots of users bashing around crud, which we deprecated for the exact same reason: was a good idea at the beginning, had bloated so much for each and everyone's need, got never unittested. The same is applying now to grid (and an order of magnitude more on smartgrid).

tl;dr: Ok on creating new things, but let this be the last time we end up in the same state: we should learn from the past.

[Richard Vézina]

I guess Massimo has his reason for wanting that web2py support BS3, for instance DePy!!

Richard

--

[Massimo DiPierro]

On Mar 13, 2015, at 2:22 PM, Niphlod <nip...@gmail.com> wrote:

NB: there's a reason why I presented welcomebs3 as a POC, and not as a final plan.

I layed out the ideas in pretty much all the discussions had so far, and the same exact things continue to pop up:
- default widgets can't be adapted for every framework, so we should have them shipped in app's "department" instead of core

agreed as a general policy. but BS3 code is already in core and we are not taking it out.

- handling readable = False fields as disabled inputs instead of DIVs

Yes. This we can be treated as a bug and fixed in trunk. Not related to BS3. Not release blocking.

- grid and smartgrid needs refactoring

Yes. Not related to BS3. Not release blocking.

- "themes” support

Yes. Not related to BS3. Not release blocking.

- MENU does it job but at a high cost, almost impossible to craft to every framework

I think MENU is very customizable. MENU is one thing that can be done without helper if necessary.

- auth forms needs additional care (think to what form.add_button() does........)

- form.errors handling makes sense only for a pretty restricted set of ui design

As long as it works with the scaffolding app I am ok. I can see there are times you want custom ones.

- etc

IMHO the rush of pushing bs3 scaffolding is unjustified at the current state, given that every discussion we had ended in pretty much nothing. We should seize the opportunity, bite the bullet and see what changes need to be made to slip in a whole new set of css rules.
There's a reason to it: everyone feels that touching the code would end up in yet another attempt to make it more complex, won't solve the "css framework lock-in" and nobody feels like doing everything in javascript on the view, and use web2py only as the MC, because at that point most of the "batteries included" arguments don't matter at all. Customizing forms with lots of js may solve the issues at hand with all defaults, but they'll make impossible to hack in a bit, resorting to code the entire form by hand.

having only response and request object to rely upon to make everything "thread-safe" is another point that pops up, but I feel that appconfig.py (or anything else like that) could solve the issue (i.e. set there some "verbose" settings loaded once-per-app in order to not repeat them in code over and over, while keeping flexibility).

While I agree on refactoring, I still see lots of users bashing around crud, which we deprecated for the exact same reason: was a good idea at the beginning, had bloated so much for each and everyone's need, got never unittested. The same is applying now to grid (and an order of magnitude more on smartgrid).

tl;dr: Ok on creating new things, but let this be the last time we end up in the same state: we should learn from the past.

[Massimo DiPierro]

It is more complicated than that. I am looking at a lot of third party apps these days. Everybody uses BS3 and are complaining that web2py forms do not support it. People are choosing other frameworks because of BS3.

This is an emergency.

We have a solution that works. We can ship it. We can revise it. We are not changing core now anyway. We can do it better. We all agree on what better means. The problem is that better means work and we have already delayed BS3 more than one year.

Not moving on because our solution is not the perfect one is not an acceptable solution.

Massimo

[Niphlod]

I see the points, although I sense a bit of resentment.... this will get newbies mad when their app based on this first incarnation on bs3 gets changed when we'll ship a better "revision", however, as long as everything gets clearly marked as experimental and we can change it as soon as better ideas pop up, I'm fine.

[Massimo DiPierro]

No resentment. It is guilt. I feel i did not setve users well by stlll shipping bs2 and a broken Gae support. I am very grateful to you, Giovanni, michele, etc for always pushing for better and for all your work.

On Mar 14, 2015 2:33 PM, "Niphlod" <nip...@gmail.com> wrote:

I see the points, although I sense a bit of resentment.... this will get newbies mad when their app based on this first incarnation on bs3 gets changed when we'll ship a better "revision", however, as long as everything gets clearly marked as experimental and we can change it as soon as better ideas pop up, I'm fine.

--

[Tim Richardson]

On Saturday, 14 March 2015 05:44:49 UTC+11, Massimo Di Pierro wrote:

right now, in my view only sqlhtml is messy. The dal code is pretty good. The template is good. The helpers are verbose but ok. The logic in main+restricted+htttp is convoluted but I would not touch files that have not needed to be touched in ages.

 

For what it's worth, the grid is still a killer feature of web2py. I went looking for javascript datagrids which are permissively licenced (e.g. MIT), support editing, server-side pagination, "filtering" (i.e. search widget),  export (even if not to Excel) and which appear to be active projects. 

I found only angular-js ticked all the boxes. web2py does as well, except that it doesn't do inline editing. Backbone didn't make the grade because a key part of the solution, pagination, is not maintained. 

I didn't find ready-to-go ractive.js examples, but perhaps I didn't look hard enough.

I was actually about to write a wrapper around sqlform.grid to implement the inline editing slice I wrote ages ago because it seems that the laziest solution for me is to add inline to sqlform.grid. 

[Massimo DiPierro]

It will be easy to make a grid with ractive. In the todo list.

[Tim Richardson]

On Tuesday, 17 March 2015 12:22:43 UTC+11, Massimo Di Pierro wrote:

It will be easy to make a grid with ractive. In the todo list.

In your vision for this, would it be completely AJAX to the extent when the client makes requests for a certain page of data like the other fully fledged javascript grids?

 

[Massimo DiPierro]

yes. But it would look a lot like the current code server side.

On Mar 16, 2015, at 8:19 PM, Tim Richardson <t...@tim-richardson.net> wrote: