Seems that a simple little feature is getting to be a real box of hurt..... is it worth all the tradeoffs to save a few characters of typing?
Doug Hughes, President Alagad Inc. [email protected] 888 Alagad4 (x300) Office: 919-550-0755 Fax: 888-248-7836 On Wed, May 20, 2009 at 11:09 AM, Bob Silverberg <[email protected]>wrote: > > 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 . -~----------~----~----~----~------~----~------~--~---
