Thinking about this some more, it does seem to be morphing a bit from
what I originally saw as an enhancement, but that's cool.

I think you're right, one single default event type will not be very
flexible.  Being able to assign an event type to a group of event
handlers will be more flexible and useful.

That raises the question: will the event type(s) assigned to a group
of event handlers be "default" event types (i.e. they can be
overridden in an individual event handler), or will they be the actual
event types that are applied to *all* handlers in that block (with no
opportunity to override)?  I can see how the latter might make sense,
as now the developer is deciding to group event handlers together by
type, so if they don't want a particular handler to have that
"default" type they just wouldn't put it in the group.

The problem this raises is that now, in order to use that feature, a
developer is going to have to group event handlers based on type,
which might make the xml less reader-friendly.  For example, I might
like to group all event handlers that deal with Users together, but if
some of those event handlers need the "TemplatedEvent" type and others
do not then I'll end up with two blocks instead of one.

I suppose that allowing the event handler type to override the default
type would alleviate that problem, allowing developers to group their
event handlers however they see fit.  if they want to use separate
blocks an no overrides great, if they prefer to group differently and
therefore need overrides, fine too.  I do see that it could be a bit
confusing to describe, but it does seem to provide maximum
flexibility. It still leaves the issue of type="", which I agree is
ugly, but I'm not sure how to address that.

Thoughts?

On Wed, May 20, 2009 at 10:54 AM, David Henry
<[email protected]> wrote:
> Perhaps my use case calls for something more aptly named "event type groups"
> instead of "default event type".  Again I'm left wondering: Why would I want
> a default event type?
>
> I'll re-re-read the event types documentation as time permits and ponder
> this further.
>
> Bob Silverberg wrote:
>
> Perhaps, but that might suggest that it cannot be overridden.  By
> calling it defaultType I think it better describes the behaviour,
> which is "this is the default type(s) used if no type is specified in
> the handler itself".
>
>
> On Wed, May 20, 2009 at 10:21 AM, Doug Hughes <[email protected]> wrote:
>
>
> If we're grouping events by type, then the attribute on event-handlers
> should not be default, but type.
>
> Doug Hughes, President
> Alagad Inc.
> [email protected]
> 888 Alagad4 (x300)
> Office: 919-550-0755
> Fax: 888-248-7836
>
>
>
>
>
>
> >
>



-- 
Bob Silverberg
www.silverwareconsulting.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en

For more about Model-Glue, check http://www.model-glue.com .
-~----------~----~----~----~------~----~------~--~---

Reply via email to