Skip to Content
Consider the following situation:

We want to create a generic component(~controller+model+view) say a ‘tree’ – and of course we want this component to be save in terms of controller/model initialize themselves in a proper (OO-)way. So every controller that uses our component – no matter under which circumstances – would just create/register the controller ‘tree_ctrl’ with

create_controller( controller_name = ‘tree_ctrl.do’ controller_id = ‘org_struct_ctrl’ ).

and it would be in a sensible and usable state right away.

In ‘normal’ (non-BSP) OO this is the very job of constructors – create an object and return it in an initialized state. The caller – here the using controller – provides the parameters.

When initializing the ‘tree_ctrl’ we’d like to initialize its model as well (self-evident I guess). However the initialization of the model ‘tree_model’ might be parameterized, e.g. with the type and ID of the root. That is we need these parameters in do_init() of tree_ctrl in order to pass them right on to the tree_model during its creation. However BSP is a framework, do_init() cannot behave like a ‘real’ constructor (think about it, e.g. a variable length parameter list cannot be passed to create_controller( )): the signature is empty, no parameters can be passed.

The consequence is that parts of the initializing process of a controller (in this case the initialization of the controller’s model) are handled somewhere outside the controller itself – in our case this would be the supercontroller of tree_ctrl (the user of our generic tree component). The supercontroller would first register tree_ctrl (in the course of this process do_init() of tree_ctrl would get called) and then have the responsibility to call a bunch of setters on the resulting tree_ctrl object in order to initialize it properly. This code would probably appear in do_init() of the supercontroller:

But this is exactly what we wanted to avoid. What if developer Bob of a supercontroller creates/registers tree_ctrl and then forgets to call all the right setters in the right order at the right time? The compiler wouldn’t complain…

This is a possible solution for the dilemma: Let every user (other controller) of our component implement an interface ‘tree_user’ which contains a set of setter-methods. These setter-methods each get a reference to the tree-controller (and function as call-backs on the actual setter-methods on the tree-controller). Now do_init() of tree_ctrl could look like this:

The (super-)controller that uses the tree component and that implements the interface now implements the setter-methods like´

im_tree_ctrl->set_tree_title( ‘OrgStructure’ )

etc. where im_tree_ctrl is the handle to tree_ctrl of course. E voilà, the do_init() of our supercontroller now only contains something like

create_controller( controller_name = ‘tree_ctrl.do’ controller_id = ‘org_struct_ctrl’ ).

the actual initialization of tree controller/model is where it belongs – in the do_init()/constructor of tree_ctrl or tree_model respectively, not outside. It is a compile-time error if a user of the component does not implement the tree_user interface!

Of course the user controller still has to implement the setters in a sensible way (here call back the setters of tree_ctrl itself), but this much one can expect ๐Ÿ˜‰

Regards, Sebastian

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply