[Cubicweb] floating ideas around
Christophe de Vienne
christophe at unlish.com
Sat Jan 11 15:18:34 CET 2014
Le 10/01/2014 21:11, Nicolas Chauvat a écrit :
> Hi List,
> 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.
It is ! the tracker is not a nice place to rework ideas IMO.
> * 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.
A _huge_ +1
The whole concept of files automatically loaded is scary.
Worse : we never know which ones are automaticaly reloaded in dev-mode
-> the new mechanism should address that.
> 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.
This is more or less what the Pyramid framework does.
An api allows to scan files, and if those have interesting things (like
exposed functions, "setup" functions), they are used to populate the
configuration of the application.
All the mecanism is implemented in a separate package, venusian . It
could be an option to use it directly, making the code base somewhat
lighter (which is always a good thing imo). At the very least it should
be an inspiration source.
> * 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.
I think it would bring unnecessary complexity, where simple solutions
can be found, like make sure register_all() (or "scan") read the
sub-modules in the right order by adding a parameter to it.
And if it is not enough, maybe it means separating a cube in two is
More information about the Cubicweb