I don't think its important to be able to "name" handlers as a handler
only provides a binary operation: it either handles an event or it
doesn't. How it handles an event is an implementation detail that
should be private to an object. Currently, OL only supports a direct
handler implementation:
<handler name="oninit">
....
</handler>
My suggestion would be to also support an indirect implementation,
that follows the procedural paradigm, allowing methods to be specified
within a handler. A "method" attribute could be used to select from
amongst several available implementations.
<handler name="oninit" method="meth1">
<method name="meth1">
....
</method>
<method name="meth2">
....
</method>
</handler>
This is only one possible choice. You might find it better to use an
indexed array to support the current handler. In which case, it would
default to a zero offset and possibly also support "first", "last",
"next" and "previous" operations.
A handler could then be referenced and set as
obj.oninit.setAttribute("method", "meth1");
or
obj.oninit.setAttribute("method", 1);
I like the idea of having the methods enclosed within a parent handler
tag as it provides locality and complements the appearance of the
direct implementation handler. But this comes with the cost of
reusability. It might be better to represent the handler as an end
node that references any method defined within the object.
<handler name="oninit" method="meth1"/>
<method name="meth1">
...
</method>
</class>
As methods are inherited by an extending subclass -- also allowing
them to be overridden, while the methods contained within a handler
would need to be restated.
On Wed, Feb 17, 2010 at 12:28 PM, P T Withington <[email protected]> wrote:
> Good point, Norm. Thanks for the feedback.
>
> Clearly I need to think about this API more, because as you point out, what I
> have so far is too confusing.
>
> I'm open to better suggestions!
>
> On 2010-02-17, at 14:54, Norman Klein wrote:
>
>> I think this API is attempting to have things both ways and as a
>> result, its confusing. The attributes need to work in a single manner.
>> According to this email, the 'name' attribute operates in different
>> ways depending on the presence of the 'event' attribute. This allows
>> confusing situations like this to occur:
>>
>> <handler name="oninit" event="null">
>> ...
>> </handler>
>> <handler name="oninit">
>> ...
>> </handler>
>>
>> According to the API, this confusing mess would be legal as the first
>> handler only has the name "oninit", while the second handler only
>> handles "oninit" events and doesn't have a name, so there's no name
>> conflict.
>>
>
>
