[entity] introduce a new 'adapters' registry
This changeset introduces the notion in adapters (as in Zope Component Architecture)
in a cubicweb way, eg using a specific registry of appobjects.
This allows nicer code structure, by avoid clutering entity classes and moving
code usually specific to a place of the ui (or something else) together with the
code that use the interface.
We don't use actual interface anymore, they are implied by adapters (which
may be abstract), whose reg id is an interface name.
Appobjects that used to 'implements(IFace)' should now be rewritten by:
* coding an IFaceAdapter(EntityAdapter) defining (implementing if desired)
the interface, usually with __regid__ = 'IFace'
* use "adaptable('IFace')" as selector instead
Also, the implements_adapter_compat decorator eases backward compatibility
with adapter's methods that may still be found on entities implementing
the interface.
Notice that unlike ZCA, we don't support automatic adapters chain (yagni?).
All interfaces defined in cubicweb have been turned into adapters, also
some new ones have been introduced to cleanup Entity / AnyEntity classes
namespace. At the end, the pluggable mixins mecanism should disappear in
favor of adapters as well.
=========================================
Refactoring the CSSs with UI properties
=========================================
Overview
=========
Managing styles progressively became difficult in CubicWeb. The
introduction of uiprops is an attempt to fix this problem.
The goal is to make it possible to use variables in our CSSs.
These variables are defined or computed in the uiprops.py python file
and inserted in the CSS using the Python string interpolation syntax.
A quick example, put in ``uiprops.py``::
defaultBgColor = '#eee'
and in your css::
body { background-color: %(defaultBgColor)s; }
The good practices are:
- define a variable in uiprops to avoid repetitions in the CSS
(colors, borders, fonts, etc.)
- define a variable in uiprops when you need to compute values
(compute a color palette, etc.)
The algorithm implemented in CubicWeb is the following:
- read uiprops file while walk up the chain of cube dependencies: if
cube myblog depends on cube comment, the variables defined in myblog
will have precedence over the ones in comment
- replace the %(varname)s in all the CSSs of all the cubes
Keep in mind that the browser will then interpret the CSSs and apply
the standard cascading mechanism.
FAQ
====
- How do I keep the old style?
Put ``STYLESHEET = [data('cubicweb.old.css')]`` in your uiprops.py
file and think about something else.
- What are the changes in cubicweb.css?
Version 3.9.0 of cubicweb changed the following in the default html
markup and css:
=============== ==================================
old new
=============== ==================================
.navcol #navColumnLeft, #navColumnRight
#contentcol #contentColumn
.footer #footer
.logo #logo
.simpleMessage .loginMessage
.appMsg (styles are removed from css)
.searchMessage (styles are removed from css)
=============== ==================================
Introduction of the new cubicweb.reset.css based on Eric Meyer's
reset css.
Lots of margin, padding, etc.