[Cubicweb] floating ideas around

Nicolas Chauvat nicolas.chauvat at logilab.fr
Fri Jan 10 21:11:17 CET 2014

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.

* 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 !

Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  

More information about the Cubicweb mailing list