[erlang-questions] hierarchical behaviour doesn't seem to work ?
Fri Dec 16 07:04:32 CET 2011
I include an example of how this can be done taken from one of our courses. It implements a behaviour which is a GS server built on top gen_server and provides a more specialised callback interface similar to the normal gen_server one. I hope this will help show how it can be done.
----- Original Message -----
> Hi Vance,
> On Wed, Dec 14, 2011 at 01:25:40PM +0530, Vance Shipley wrote:
> > I wrote a howto article on this a few years ago:
> > http://www.trapexit.org/Cascading_Behaviours
> ah, i see.
> > Yes, you need to define these functions in your module. Your
> > client may extend these itself and/or pass them on to my_bahaviour.
> I've meanwhile found a solution to solve the problem. I was
> the "wrong way around". What I need to do is I need to call
> gen_server:start_link(), and tell in the init arguments which
> implementation it should use (my_behaviour), which then needs to get
> passed the name of the actual module (client) into its init()
> > Cascading behaviours wasn't anticipated in the design and, aside
> > from me, very few people have used that design pattern.
> At least when it comes to public Erlang code, it seems like that.
> And yes, the question was in fact related to signerl and the way how
> tcap_tco_server extends gen_server, and my osmo_sccp_tcap then
> the callbacks to tcap_tco_server.
> Things seem to be coming along quite OK for remotely-initiated
> transactions. I'm now working on locally-initiated transactions,
> TC-BEGIN is coming from the TCAP user side. I hope to have
> working fully in the next two weeks.
> - Harald Welte <>
> "Privacy in residential applications is a desirable marketing
> (ETSI EN 300 175-7
> Ch. A6)
> erlang-questions mailing list
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8251 bytes
Desc: not available
More information about the erlang-questions