[Cubicweb] floating ideas around
nicolas.chauvat at logilab.fr
Fri Jan 10 21:11:17 CET 2014
When discussing CubicWeb's internals with Sylvain or others, we
sometime have ideas that fall into the "would be nice, but we may
never find the time to implement this" category.
I could add tickets to the tracker, but that would only help clutter
the backlog of the project. Instead, I will from now on post them on
the mailing list. Consider that a message in a bottle thrown in the
sea. Maybe it will reach someone at some point in the future, maybe
not... but let's bet it is more useful than throwing them away.
* Idea 1: explicitly registering the appobjects in the registries
At startup, CubicWeb scans all the cubes for python files,
looking for classes deriving from AppObject and registers these
classes in the proper registry (depending on the __registry__
Explicit being better than implicit, CubicWeb could provide a
function "register_all()" that would implement the current behaviour
and could be called explicitly by client code (cubes) at some point
in the startup process.
If the "register_all()" behavior is not the one that fits a specific
case, the client code would use the utility functions of the API
underlining the scan/registration process to implement its own way
of looking for and selecting AppObjects to register.
A direct benefit of this would be that a cube could easily be
included without all its components being loaded and made available
in the registries.
* Idea 2: dependencies between AppObjects
Assuming Idea 1 gets implemented, we may get to a point where an
AppObject is loaded without the other AppObject it relies on being
also loaded. For example view A is loaded, but it will call another
view B that is not loaded. This would result in an exception of the
kind "object not found in registry" when A is executed.
To prevent that problem to be detectable only at runtime, a
dependency mechanism could be introduced to allow appobjects to
explicitly state that they need another appobject to execute
Once the registries are loaded, a consistency check could be
performed to detect the missing appobjects.
A bit more evoluted would be, if A is explicitly loaded with the
option "include dependencies", to look for and load the dependencies
of A, namely B.
That's it for today, have a nice week-end !
logilab.fr - services en informatique scientifique et gestion de connaissances
More information about the Cubicweb