@Jamie: What I was suggesting with multiple event-handlers would change the way you work. Let me try and clarify how i see it working. The event-handlers block gets an optional attribute defaultEventType which accepts a list of event-types to be applied to any handler within the block. The defaultEventType can be overridden for any event-handler by using the type attribute. Both are entirely optional
Secondly, the DTD for ModelGlue's xml changes to allow multiple event-handlers blocks. This allows for events to be grouped and different defaultEventType's applied to each block So if you like the way MG event-types currently work, there is no need to change the way you organize your xml. Keep all your event-handlers within a single block, don't apply a default and add event-types to handlers on an individual basis. @Doug: By "tradeoff" do you mean the time it will take to implement this feature? I can't really see it will have a negative impact, yes there's added complexity if you want it, but otherwise everything works "as normal" Chris 2009/5/21 Jamie Krug <[email protected]> > > @Doug: I hear ya! I'm completely on the fence here. Initially, the > *idea* of a default event type sounded very nice. After reading > through this thread and considering implementation ideas, I'm not so > sure it's worth it. Truthfully, it's not saving _that much_ text in > the XML configs. > > @Bob: If this is going to be added, I'm right in line with your last > set of suggestions. Specifically, you pointed out my primary > discomfort with the idea of multiple event-handlers in a file -- I > like to group related event-handler events under a comment, so to have > to move one or more events to a different event-handlers block, just > because I don't want the default event type(s) is looking really ugly > IMO. That said, if multiple event-handlers blocks are allowed, I'd > suggest we still have a means to override the default event type(s) on > a single event-handler. I'd be totally fine with type="" to override > any defaults. The only other option that comes to mind at the moment > would be something like useDefaultTypes="false" and I think I might > prefer type="" to that. > > Just another 2 cents. Thanks for the great discussion. > > -- > Jamie Krug > http://jamiekrug.com/blog/ > > On May 20, 11:33 am, Doug Hughes <[email protected]> wrote: > > 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 . -~----------~----~----~----~------~----~------~--~---
