Ok, I think we are getting somewhere reasonably close to a consensus. I'll give this until after lunch time today to get any last viewpoints in and then write up a summary of how I see this working. We'll take a vote on it.
DW On Thu, May 21, 2009 at 7:59 AM, Josen Ruiseco < [email protected]> wrote: > > Sorry guys. Mis-emailed that one... Hehe > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Bob Silverberg > Sent: Thursday, May 21, 2009 6:50 AM > To: [email protected] > Subject: [Model-Glue] Re: Default Event Type > > > 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 > > > > > > > -- “Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew.” Guillaume Apollinaire quotes --~--~---------~--~----~------------~-------~--~----~ 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 . -~----------~----~----~----~------~----~------~--~---
