Style ZMI using Bootstrap

[icemac]

WIP styling the ZMI of Zope 4 using Bootstrap. (This is part of a customer funded project. – There is still a need for )

It does not seem to make sense to have custom infrastructure to style the ZMI so we integrated it right into the core.

Using fanstatic to serve the static assets seemed to be the easiest way. (We have been using this WSGI middleware for years in production.) But there was neither a discussion nor a consensus about using it. But it is relatively lightweight according to its dependencies and its runtime impact.

Using this branch the ZMI currently (time when creating this PR) looks like this:

Whereas the same view on current master looks like this:

We decided against removing the frames as this would require AJAX calls for the tree as otherwise it has to be rendered at each page.

What do you think about it?

Related packages having a zmi-bootstrap branch which need to be merged along with this PR:

• AccessControl
• Products.BTreeFolder2
• Products.ZCatalog
• Products.MailHost
• Products.PythonScripts
• Products.CMFCore
• Products.Sessions
• Products.TemporaryFolder
• Products.SiteErrorLog

Open issues:

• Maybe replace fanstatic by resource directories.
• Document how to update an existing Zope instance (calling bin/mkwsgiinstance again does not touch already generated files.) not needed as we do not use fanstatic
• Style more screens using bootstrap (see Finish Bootstrap ZMI  #306)

[dwt]

@tseaver: At the last sprint we did discuss that adding the dependency on bootstrap would be the right way to go (You where not there, so you probably missed it). We did not discuss anything about a python dependency to serve those resources.

[icemac]

Added icons for all types which come with a vanilla Zope 4:

[tseaver]

I'm not intrinsically opposed to adding a dependency on fanstatic (I've never used it, nor do I know much of anything about it). I just didn't want it to slip in without discussion.

[dwt]

It seems to me that fantastics biggest advantage that is usable here, is that it allows hosting the js/css dependencies on urls that have a content hash and are thus easily infinitely cacheable.

Not sure if this is really worth it, as the bundled bootstrap is really only usable by the manage interface itself, thus caching seems not to be so important?

[dwt]

@icemac I really like the progress you guys have achieved here, I do however feel that the look that we already had (though still at the spiking stage) was cleaner and smoother. I would really like it if you could go further into the direction set by our prototype.

What do you think?

[icemac]

@dwt This PR is mainly to show it is possible to style the ZMI using Bootstrap by changing the code in the Zope core. We did not write any custom CSS but took only the one which came with Bootstrap. Additionally we wanted to avoid writing custom JS if possible. I know there are plenty abilities to make it smoother and nicer. Maybe the next sprint could be a possibility to finalize the styling.

[icemac]

@tseaver @pbauer Discussing the taken approach using fanstatic internally at gocept we found out that it would be a bigger effort to integrate fanstatic with ZServer. (I do not think the gain is worth the effort.) I doubt Plone will stop using ZServer on Zope 4 to keep the locking support and all the other things a plain WSGI server does not provide. (at least as long Python 2 is the only supported Python version)
But using fanstatic would mean that ZServer based installations see a ZMI without any styling. This would be bad.
Maybe a better solution is to keep using the tools Zope provides for resources namely resource directories which are served via ++resource++ and which are compatible with ZServer and WSGI.

[thet]

+1 for using resource directories instead of fanstatic. Todays static resource build and deployment tools are quite different from fanstatic. Resource directories support any build environment, fanstatic has their own tools.

Besides of that, both the new ZMI looks very nice - the @icemac version as well as the @dwt
one. It's probably just about tweaking some variables to get @icemac's version look like @dwt's.
@dwt where can I find your branch?

The templates also got a nice cleanup.

Although all templates are still DTML - I know it's out of scope for this PR but IMO it would make a nice sprint topic to migrating everything to TAL templates and browser views.

[jcbrand]

Bootstrap is not called "Twitter Bootstrap" since quite a few years already.

https://www.quora.com/Bootstrap-is-no-longer-referred-to-as-Twitter-Bootstrap-Has-Twitter-cut-off-support-for-Bootstrap

[dwt]

@thet: you can currently find our branch here: https://zmslabs.org/trac/browser/ZMS/branches/zope4

@icemac: I agree that loads of custom css / js are not the right initial push, but I think that it could be little effort, to get even plain bootstrap more into the direction we set forth.

Some examples:

• Use one color for all the action buttons instead of mixing priority and notification styles
• Use solid styles for buttons instead of the wireframe ones
• in general reduce the amount of colors used in the admin UI.

Of course we can always work towards this in a future sprint - but I feel these could be good guidelines for you when you guys work on this right now.

In any case: Thanks for the work!

[sallner]

@dwt and @drfho
It seems to me, that the work done in this PR is accepted by the majority to go into the right direction. Unfortunately, it is huge and hard to understand. Additionally there are branches in other packages, which have to be merged to really try this feature, which add more complexity. If you have time, it would probably be good to focus first on getting the tests to run and then rebase this huge PR. Afterwards, there could be issues and smaller PRs for individual improvements.