ComponentFactory< P > Class Template Reference

Factory to create ModelComponent-derivative objects from a key string. More...

#include <Component/ComponentFactory.H>

Inheritance diagram for ComponentFactory< P >:

[legend]

Collaboration diagram for ComponentFactory< P >:

[legend]

List of all members.

Classes
class	ComponentCreator
	Creator class that creates ModelComponent derivatives on demand.
Public Types
typedef nub::ref< P >	ProductType
Public Member Functions
	ComponentFactory (const char *keydescr, bool nocase=false)
template<class T >
void	registerType (const char *name, OptionManager &mgr)
nub::ref< P >	createObj (const char *type) const

---

Detailed Description

template<class P>
class ComponentFactory< P >

Factory to create ModelComponent-derivative objects from a key string.

The template class P should be some class that is derived from ModelComponent, and that is also the root of some sub-tree of the full inheritance graph.

Here's a quick overview of how ComponentFactory can be used with plugins and dynamic loading. You would use this system when you have multiple concrete classes derived from a base class, and you want to be able to select a particular concrete type to use at run time, based on some user input (e.g. a string passed to a command-line option). First, you create a ComponentFactory that is going to build products derived from a different type. Then, you install a PluginFallback for that factory that tells it "if you don't already know about the type, then first try to load an appropriately-named plugin module, and then try again to see if that plugin has now informed you about the type".

For an example of all this, see Media/FrameSeries.C, where we use the factories defined in Transport/FrameIstreamFactory.H. We populate the factories with some statically-known types, and then we install a PluginFallback. The PluginFallback essentially says, if we get --in=foobar on the command line, and our factory doesn't know anything about 'foobar' yet, then it should look for a plugin library named <plugins>/FrameIstream/foobar.so, and it should try to find an init function named frameistream_foobar_init() in that library. Presumably, that function frameistream_foobar_init() will then tell the factory how to make a 'foobar', and so when the PluginFallback returns, the factory can try again to make a 'foobar'.

To actually try out a plugin, try the following:

    make bin/ezvision
    make plugins
    ./bin/ezvision --in=tests/inputs/mpegclip1.mpg -T --out=display --out=debug
    

and within the log output you will see something like this:

    Plugin::loadPlugin: opening /lab/rjpeters/projects/saliency/lib/invt/plugins/FrameOstream/debug.so
    Plugin::loadPlugin: running frameostream_debug_init() from /lab/rjpeters/projects/saliency/lib/invt/plugins/FrameOstream/debug.so
    debug::frameostream_debug_init: Hello from frameostream_debug_init()!
    

and then you will start seeing output from the DebugOstream that is built by --out=debug.

Definition at line 94 of file ComponentFactory.H.

---

The documentation for this class was generated from the following file:

• src/Component/ComponentFactory.H