| Age | Commit message (Collapse) | Author |
|---|
|
|
|
An array-registered function has no param names, so you can only pass an
array: a map would be meaningless. Initial implementation of map-registered
functions assumed that since you CAN pass a map, you MUST pass a map. But in
fact it's meaningful to pass an array as well -- for whatever reason -- and
easy to implement, so there you are. Tests to follow.
|
|
On Windows, unlike on Mac or Linux, boost::ptr_map<> started insisting on this
concept of clonability. In other words, it wants to own a unique instance of
the pointee; if you copy a value_type -- even to dereference an iterator! --
it wants to construct a whole new instance of the mapped_type. That's nuts. A
std::map<..., boost::shared_ptr<>> has the property I want (the mapped_type
goes away when the entry is erased), plus it's willing to pass around the
shared_ptr to the same instance of the mapped_type. This change also permits
simplifying a couple awkward kludges I'd already had to make to accommodate
ptr_map's idiosyncracies.
|
|
The shortcut way to construct an LLSD array of size n is to assign LLSD() to
array[n-1]. That's fine -- as long as you remember not to do it for n == 0.
|
|
Until now, LLEventAPI has only been able to register functions specifically
accepting(const LLSD&). Typically you add a wrapper method to your LLEventAPI
subclass, register that, have it extract desired params from the incoming LLSD
and then call the actual function of interest.
With help from Alain, added new LLEventAPI::add() methods capable of
registering functions/methods with arbitrary parameter signatures. The code
uses boost::fusion magic to implicitly match incoming LLSD arguments to the
function's formal parameter list, bypassing the need for an explicit helper
method.
New add() methods caused an ambiguity with a previous convenience overload.
Removed that overload and fixed the one existing usage.
Replaced LLEventDispatcher::get() with try_call() -- it's no longer easy to
return a Callable for caller to call directly. But the one known use of that
feature simply used it to avoid fatal LL_ERRS on unknown function-name string,
hence the try_call() approach actually addresses that case more directly.
Added indra/common/lleventdispatcher_test.cpp to exercise new functionality.
|
|
|
|
for all registered operations. (untested)
Introduce LLEventDispatcher::getMetadata(name) query so you can discover, for
a given named operation, its query string and required parameters. (untested)
Introduce LLEventDispatcher::add() convenience methods allowing you to omit
description strings. Fix LLLoginInstance (which uses a non-LLEventAPI
LLEventDispatcher) back to description-less add() calls.
However, filter LLEventDispatcher::add() methods inherited by LLEventAPI so
that an LLEventAPI subclass *must* provide a description string.
|
|
with an event API. In addition to the LLEventPump name on which to listen,
LLEventAPI accepts a documentation string for event API introspection.
Give every LLEventDispatcher::add() overload a new documentation string
parameter for event API introspection.
Convert every existing event API to new conventions, introducing suitable
documentation strings for the API and each of its operations.
|
|
existing event calls to use state as "offline" or "online", with "change"
indicating the reason for this status event. Changed disconnect() to send
state "offline", change "disconnect" -- instead of replaying last auth
failure. Changed unit tests accordingly.
Changed LLLoginInstance::handleLoginEvent() to use LLEventDispatcher to route
calls to handleLoginFailure() et al.
Added LLEventDispatcher::get() to allow retrieving Callable by name and
testing for empty().
|
|
LLEventDispatcher and LLDispatchListener classes. See LLAresListener for
example usage.
|
