Naively, I am happy with an approach where, when we design a controller, we consider the HTML + CSS + javascript together as one component, a template, and we only want to know the interface to this template. We want a clean modular interaction between these templates and the code that generates the input that these templates need. We need an abstraction layer over the templates, in the same way as we have abstraction layers over database engines. In the case of database engines, the abstraction layer translate database queries. In the case of templates, the abstraction layer translates a dictionary into the inputs needed by the template framework, perhaps a dictionary in another format. However, the analogy with databases is broken. We can view two different database queries for different database engines as equivalent, but we cannot view two different inputs for two different templates as equivalent, because they are fundamentally different in terms of what is presented to human beings. So, I believe that the best we can offer on the controller side is a general language to generate dictionaries as input to template, just as web2py does. On the abstraction layer side, I am happy if, for each template framework, we have a wrapper that accepts dictionaries as input and a documentation of this interface. This is the natural situation in standard modular programming. We simply need well documented interfaces. Of course, the more we have already used templates that we can adapt, just as in the regular web2py philosophy, the better it will be. However, in this particular case, I strongly believe that it is also important to have well documented interfaces to the templates because in some cases a start from scratch approach would be preferable. Anyway, it is also perfectly in tune with a teaching view.
On Saturday, 18 June 2016 09:27:41 UTC-4, Massimo Di Pierro wrote: > > This is a big can of worms. CSS was created to decouple style info from > structural info (HTML). Turns out most CSS today dictate both a class > naming convention and an HTML structure. You cannot take an arbitrary piece > of HTML and apply an arbitrary CSS. Moreover adding class names is often > not sufficient. Every time you change the CSS framework you have to change > the HTML. > > This is a problem for all frameworks (like web2py) that generate HTML for > you. They must know what CSS framework you use. In web2py we support > multiple formstyle(s): > > > table3cols, table2cols, divs, ul, bootstrap (2), bootstrap3_stacked, > bootstrap3_inline, inline > > > as you can imagine this is turning into a maintenance nightmare. This is > against the original spirit. This is why I believe we need a new approach > to this problem and a new library for form generation. > > > Massimo > > > On Saturday, 18 June 2016 07:47:42 UTC-5, Dominic Mayers wrote: >> >> I am just starting to learn web2py and I want to better understand the >> issue. Is the issue simply that Bootstrap 3 is not backward compatible >> with v2.x and therefore we cannot use Bootstrap3 with the templates in >> web2py that have been created with Bootstrap 2 ? The issue seems to be >> bigger than that because we would need to modify "all parts of web2py that >> are tightly bound to bootstrap", but what does this mean? Of course, we >> expect a coupling between the view and the remainder of the code. The code >> has to provide data as expected in the view. There is no way this can be >> avoided, even in a loosely coupled framework. So, is this the only issue? I >> would like to know if there was a fundamental flaw in the design of >> web2py? >> >> On Friday, 18 July 2014 15:17:34 UTC-4, Moustafa Mahmoud wrote: >>> >>> I have been using web2py for 3 years know, and I was really impressed by >>> it, I defended it in every discussion, even implemented all my projects >>> using it and even convinced my Graduation Project Team to use it in our GP. >>> However, as my skill increased and I began looking more into customizing my >>> applications, I have hit a brick wall discovering how tightly bound web2py >>> is to bootstrap2, I wanted to use bootstrap 3 but was faced with tons of >>> problems. If I want to move to another front end framework then I >>> discovered that it would be easier to use another framework because of the >>> time and effort I would need to invest in modifying all parts of web2py >>> that are tightly bound to bootstrap. >>> This will result in making web2py a headache to me rather than my best >>> friend. I am writing this message because I am really sad that an amazing >>> framework like web2py is forcing me to consider an alternative because I do >>> really feel it is constraining me at this point. >>> Any help or ideas about that ? >>> >> -- 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.
