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




--~--~---------~--~----~------------~-------~--~----~
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