Just thought I'd chime in that I agree with everything that Chris is saying. And I echo Denny's sentiment that the real pain is occurring now, in the hashing out of this feature, which is, imo, a good thing.
Cheers, Bob On Thu, May 21, 2009 at 2:53 AM, Chris Blackwell <[email protected]> wrote: > @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 >> > > > > > -- 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 . -~----------~----~----~----~------~----~------~--~---
