let auth.navbar() talk semantic

[Richard]

Hello,

I found a way to let auth.navbar(), talk semantic...

Code a bit dirty at the moment, but I have been able to create a layout_semantic.html make the top navbar look and feel the same way as boostrap3 but using semantic ui.

I had to create a couples of news settings for icon which are kind of hardcoded which doesn't work in case there is more then one css framework supported...

Then I derive a semantic2() base on navbar() boostrap3()... Also a settings to specify the scaffolding. So we can set our own icon for navbar (login part) and choose between from default or semantic... I think, I also get decoupled icon so we are not tie to semantic, some one can use semantic or Font awesome, or anything else (need further test).

Then the hard part was MENU, that I override with a derivative but I had an hard time figure out how to spit properly formatted semantic dropdown/menu, so it is really dirty.

I will try make a patch and package a welcome_semantic app ASAP so yo have a better idea what change.

Would have to complete the rest of the layout... It should be easier for the rest of the component of the layout (I hope)...

Are you interested in those kind of modification to support semantic users? Because as far as I know navbar was the stumbling block...

??

Richard

[Richard Vézina]

What I found interesting with semantic is that it seems to support multiple level dropdown menu...

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

if it complicates further CORE code without flexibility to accomodate the next css framework, it's not a solution: it just adds complexity...

[Richard Vézina]

The other solution that would be to do like W3 where you render json data from the template... So you have one set of template per CSS framework...

Though I am not sure where we are going on this front (what will be "w3p" stack)...

Richard

[Richard Vézina]

That why (since we are incremental improve web2py), I propose to fix navbar issue to make it easier someone to use semantic instead of bootstrap, though I don't what are gonna be the other chalange (I think widget are also containt "hardcoded" bootstrap stuff).

Richard

[Massimo DiPierro]

stupid.css also does multiple levels of menus. 

http://mdipierro.github.io/stupid.css/index.html

https://github.com/mdipierro/web2py-welcome-theme-stupid

I was planning to go in the opposite direction with web3py and remove the auth.navbar exactely because it is one layer of abstraction that confuses people and it is better deal with a html code snippet.

Anyway, let me see your changes before we decide.

Massimo

[Richard Vézina]

I don't have it right now (they are in home computer)... Will pack something tonight.

stupid.css is nice, but I think semantic ui as much more under the hood to offer...

About auth.navbar, I think you are right, having to subclass/overriding to modify the behavior of auth.navbar complicate things a lot... Correct me if I am wrong but I never see passing any refactored implementation to accomodate other css framework... I often read that someone has implement it own navbars though. So I guess it confirm what you mention as this layer of abstraction confuse people.

By the time you are here guys can you have a look here : https://groups.google.com/d/msg/web2py-developers/x23GReU0McM/5kX42ft-PAAJ

I was asking related stuff about validation in w3 and use case for interdependent fields (missing feature in w3 to me, as it [w3] don't seems to leverage the increase in flexibility that js validation brings).

Thanks

Richard

[Richard Vézina]

Here,

Patch to gluon/tools.py is attached

And I pack the welcome_semantic derivative app. So, change in welcome_semantic occur in :

controllers/default.py (I think I just clone index() to index_semantic() to fix index.html element of lending page)

views/layout_semantic.html

views/default/index_semantic.html

static/css/web2py_semantic2.html

models/dp.py (addition are commented)

I think everything that change are pointed out...

To try the semantic auth.navabar() landing page : http://127.0.0.1:8000/welcome_semantic/default/index_semantic

Richard

[Richard Vézina]

UP!

[Anthony]

I think we need to come up with an alternative solution rather than continuing to add code branches for each CSS framework to the web2py core.

Anthony

UP!

make speech: web2py-developers@googlegroups.com
unsubscribe: web2py-developers+unsubscribe@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-developers+unsubscribe@googlegroups.com.

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

--
-- mail from:GoogleGroups "web2py-developers" mailing list

make speech: web2py-developers@googlegroups.com
unsubscribe: web2py-developers+unsubscribe@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-developers+unsubscribe@googlegroups.com.

[Richard Vézina]

So, we need to create css agnostic navbar/widgets/grid/form/etc

Moving stuff into template and passing only json data around (like w3) is one option

I really take time to before to come to this as I was unable to decide what other good proposal design could be...

Then I come up this... Why should we choose one single way over another... Why can we not still do things as were doing and at the same time be able to do other things. 

I know one of the reason is lack of ressource to maintain every part of the system... An option about that as we do for CRUD would be to Deprecate/Fix security hole and state that it shouldn't be use in production, maybe make it not working in prod by default to force the person to do something if she really wants to use CRUD in prod at it own risks.

I think the issue we have since sometimes is that there is things that are difficult to do with the actual state of web2py, let say new CSS framework onboard, Angular/Ractive/React seems to be easier... And we don't make it easier as we don't decide what direction to follow (at the same time we are well server by what is there).

I think IMHO, that we should focus as making web2py as flexible as possible (what it already is for the major part).

What is the best way to do it remains to be determined.

Maybe the question is not what should be w3p but how can we bring new way of doing thing without breaking old things that work...

??

Richard

UP!

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.

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

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

[Niphlod]

spraying core code with markup is not a good idea

spraying core code with css-specific markup is even worse

we ended up in the current situation (which is miles away from good) BECAUSE we did what you just did. 

We need a solution rather than yet another iteration of the thing we all know is screwing us. 

Doing what you did takes 5 seconds to do and abandon and hours of pain to maintain (and, implicitly, the impossibility to promise backward-compatibility)

Once again, IMHO the presentation layer belongs to the app, not gluon: I was overruled before but I still can't see a solution...not talking about real implementations, just ideas. (and no, doing everything in javascript isn't, altough is surely better than the multiple-iteration-problem we have).

[Richard Vézina]

Good analysis Simone...

So, Helpers, Widgets, etc. need a re-design, I am not exactly sure what your solution (thought) is... I can see that we need to rely more and more on templating, so Helpers, Widgets and other would only pass structured data that can then be processed by the view. This could allow a dual rendering possible by JS or Template (Python) rendering which could be flexible as desired I guess.

Was at something like that you have in mind?

Richard

On Tue, Jun 14, 2016 at 5:29 PM, Niphlod <nip...@gmail.com> wrote:

spraying core code with markup is not a good idea

spraying core code with css-specific markup is even worst

[Dave S]

On Tuesday, June 14, 2016 at 2:29:46 PM UTC-7, Niphlod wrote:

[...]Once again, IMHO the presentation layer belongs to the app, not gluon: I was overruled before but I still can't see a solution...not talking about real implementations, just ideas. (and no, doing everything in javascript isn't, altough is surely better than the multiple-iteration-problem we have).

It sounds like Massimo is moving to your viewpoint for web3py.

Perhaps what should be done for web2py is ... nothing.   Instead, Richard could turn his work into a how-to that anyone needing the change could use.  After web3py comes out, it won't be so important to maintain the how-to.  If I'm not too far wrong.

/dps

 

[Richard Vézina]

I guess like many other things it will just stay on the list for ever haha! :)

I use to create a couples of web2py slices in the past, but it seems not so stable since a couple of month...

Richard

--

[pbreit]

Couldn't/Shouldn't all that stuff be in the app instead of in the framework? Could there be a couple sample apps: Bootstrap, Semantic, stupid, etc?

[Richard Vézina]

Hello Peter,

If you want to use semantic you need to alter Auth navbar() method, so if you don't want to alter web2py you can subclass Auth and apply the mods I did... In the future, I think it the idea leave the core of w3p agnostic to which scafolding framework user may want to use.

It could also be done inside web2py it just a matter of how the implementation will be done. With web2py it requires a lot of refactoring and verification to make sure we don't break backward compatibility as it has been a promise of web2py. So Massimo's for instance seems to think (my interpretation) it would be better to invest effort in web3py and leave web2py behind. This would allow total thinking out side the box for what can be done and how as you don't have to bother with "how to maintain" backward compatibility if you take some path or another.

Right now we are nearer then ever to web2py compatible python 3... So stay tune for what coming next.

:)

Richard

On Thu, Jun 16, 2016 at 5:09 AM, pbreit <pbreit...@gmail.com> wrote:

Couldn't/Shouldn't all that stuff be in the app instead of in the framework? Could there be a couple sample apps: Bootstrap, Semantic, stupid, etc?

--

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

[Anthony]

On Thursday, June 16, 2016 at 9:13:54 AM UTC-4, Richard wrote:

Hello Peter,

If you want to use semantic you need to alter Auth navbar() method, so if you don't want to alter web2py you can subclass Auth and apply the mods I did...

You don't really have to bother subclassing Auth for this -- just write a custom function to generate a navbar.

The navbar is just a convenience method, not an essential part of the Auth system. If it doesn't work with your particular UI, then do what you have to do with every other aspect of your app's UI -- use HTML/CSS/JS (possibly via web2py's helpers) to create the UI you need.

Anthony