Most of the work already done on bootstrap 3, foundation 5, etc. can be reused. The DOM manipulating parts are also bound to be useful - as an example of what can be done, if nothing else.
I'm using the plugin_layout_<cssfw> functionality to keep bootstrap 2 & 3, bootswatch 2 & 3 and foundation 5 playing along within a single app. I'm aiming for slightly different bs2, bs3, foundation5, etc. welcome apps, that can be packed as plugin_layout_<cssfw> and updated as someone needs them. About the other part of the equation - the support for different CSS frameworks from within gluon or contrib - there was a discussion about how to implement all this a while ago and I think we really ought to finish it... My thoughts as far as functionality goes: - user would set a global variable (ie. styleserializer=bootstrap3 ..or bootstrap2, foundation5 or some other predefined style) and thus define the serialization of menus, forms, tables, grid, flash messages, etc. all in one place - existing menu, formstyle, etc. functionality stays, this is needed for backward compatibility and is also useful. User could ie. use the global variable to set everything to bootstrap3, then override the formstyle setting for one specific form to, let's say, bootstrap3-inline. All that is left for a user is to drop in a correct welcome app and voila, foundation 5 or bootstrap 3 based web2py. The implementation is something I'm not clear about. Should everything be kept in gluon, as it is now..? Should old formstyles (table3cols, etc.) stay within gluon, while bootstrap, bootstrap3 (it's already done, since recently) and future ones get moved to contrib? Should MENU() be deprecated, keeping it as is, or should it be extended to accomodate more CSS frameworks? Perhaps a new menu function altogether, in contrib? What else am I not thinking of..? On Saturday, December 14, 2013 12:50:04 AM UTC+1, Paolo Caruccio wrote: > > Thank you Niphlod. I see what you mean. I'll try to convert my code in > order to build a custom formstyle. However, I'll share my code with the > web2py users group: maybe it could be useful to someone. > About the menu, I have in my mind a simple change to the MENU helper that > should semplify its customization client side (jquery and css) but I have > to investigate more on this. > Anyway, the menu complexity is due to lack of support for multilevel > submenus. If we need a single level menu there's no need to modify the > web2py code. > For the sake of completeness, Foundation framework supports the multilevel > menu, but its css breaks the web2py calendar css. > It seems that every css framework has its own Achilles' Heel. > > > Il giorno venerdì 13 dicembre 2013 20:33:40 UTC+1, Niphlod ha scritto: >> >> IMHO there's no point on having web2py serializing by default a structure >> (response.menu) to a string (the html markup) and then reparse it back to a >> structure (elements) to move a few pieces back and forth and then >> reserializing those pieces back to html markup. It's just a waste of cpu. >> >> The way to go NEEDS to be modules with overrides, not server-side DOM >> manipulations... >> I agree that right now you can only act on the MENU() function, but a way >> must be figured out to avoid serverside DOM parsing or we'll soon face an >> untouchable MENU() that can't accomodate for new features 'cause there are >> lots of code expecting a fixed html markup. >> Same goes for forms and widgets: fortunately we have already a formstyle >> that takes a callback, but I don't see why noone is coming up with a new >> set of widgets that override the default one composing the html elements >> the way they are supposed to be in the first place >> >> -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
