I want to start a thread about Default Event Types. Event Types, as you know are a ModelGlue:3 feature for defining behavior under an Event Type and assigning those Event Types to your Event Handlers. (lost? Read here: http://docs.model-glue.com/wiki/HowTos/HowToUseTypedEvents#HowToUseTy...)
A discussion came up in the MG BOF at CFObjective about a default event type. Presently there is no such functionality and some members of the audience felt it was a good idea, though there has yet to be a consensus on how it works.
Let's start the discussion with the following two questions.
1) Should there be a Default Event Type?
2) Model-Glue 3 allows for an event handler to have multiple event types. This means the Default Event Type should technically stay with the Event-Handler regardless if the Event-Handler has other Event Types. If this is the case, how does a Default Event Type differ from adding logic to OnRequestStart? If not, and the Default Event Type vanishes if a specific type is set for a specific Event Handler, what would the usage be?
The Model-Glue mailing list is full of very smart people, so let's get the initial ideas out there and we'll work on refining them as we go along.
Your input appreciated.
DW
-- “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.”
On Tue, May 19, 2009 at 3:50 PM, Dan Wilson <sipac...@gmail.com> wrote:
> I want to start a thread about Default Event Types.
> Event Types, as you know are a ModelGlue:3 feature for defining behavior
> under an Event Type and assigning those Event Types to your Event Handlers. (lost?
> Read here:
> http://docs.model-glue.com/wiki/HowTos/HowToUseTypedEvents#HowToUseTy...)
> A discussion came up in the MG BOF at CFObjective about a default event
> type. Presently there is no such functionality and some members of the
> audience felt it was a good idea, though there has yet to be a consensus on
> how it works.
> Let's start the discussion with the following two questions.
> 1) Should there be a Default Event Type?
> 2) Model-Glue 3 allows for an event handler to have multiple event types.
> This means the Default Event Type should technically stay with the
> Event-Handler regardless if the Event-Handler has other Event Types. If this
> is the case, how does a Default Event Type differ from adding logic to
> OnRequestStart? If not, and the Default Event Type vanishes if a specific
> type is set for a specific Event Handler, what would the usage be?
> The Model-Glue mailing list is full of very smart people, so let's get the
> initial ideas out there and we'll work on refining them as we go along.
> Your input appreciated.
> DW
> --
> “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.”
On Tue, May 19, 2009 at 3:50 PM, Dan Wilson <sipac...@gmail.com> wrote: > I want to start a thread about Default Event Types. > Event Types, as you know are a ModelGlue:3 feature for defining behavior > under an Event Type and assigning those Event Types to your Event Handlers. > (lost? Read > here: http://docs.model-glue.com/wiki/HowTos/HowToUseTypedEvents#HowToUseTy... > ) > A discussion came up in the MG BOF at CFObjective about a default event > type. Presently there is no such functionality and some members of the > audience felt it was a good idea, though there has yet to be a consensus on > how it works. > Let's start the discussion with the following two questions. > 1) Should there be a Default Event Type?
Yes, but it should be optional (in case that isn't obvious), meaning that a developer doesn't have to specify a default event type.
> 2) Model-Glue 3 allows for an event handler to have multiple event types. > This means the Default Event Type should technically stay with the > Event-Handler regardless if the Event-Handler has other Event Types. If this > is the case, how does a Default Event Type differ from adding logic to > OnRequestStart? If not, and the Default Event Type vanishes if a specific > type is set for a specific Event Handler, what would the usage be?
I think that the default event type should vanish if one or more types is specified for the event-handler. To me that's what default means: use this if I'm not overridden. One should be able to specify multiple event types as the default event type, just as one can specify multiple event types on an event-handler. In order to allow a developer to specify *no* event types for a particular event-handler, they could specify type="" in the <event-handler> element. In terms of how to implement it in the xml, I can see a couple of options:
1. Make it a Model-Glue configuration setting, for example "DefaultEventTypes", and allow a comma delimited list of event types.
2. Allow for a <default-event-types> element inside the <event-types> element. For example:
I was thinking about this last night, and very nearly posted to the list
about.. spooky.
I'd like to see this feature, I think it makes sense not to have to
enter type="TemplatedEvent,SecuredEvent" on nearly every handler, as has
been mentioned it should be optional, and the ability to remove the default
for a specific handler is a must.
As for configuration i'd go with Bob's option 1. The MG config bean already
contains the defaultEvent property so this seems to fit nicely. Although
something doesn't feel quite right about specifying type="" to remove the
default type.
While i think of it, would it be any use to have a defaultEventType
attribute for the event-handlers block, like Coldspring has the
defaultAutoWire attribute for the beans tag?
I don't know whether MG would like multiple <event-handlers> blocks in a
single file, but that would be a very clear way to apply a default event
type to a group of events. Its not an across the board catch all default,
but it would certainly save a lot of repetition.
> > The Model-Glue mailing list is full of very smart people, so let's get
> the
> > initial ideas out there and we'll work on refining them as we go along.
On Tue, May 19, 2009 at 5:22 PM, Chris Blackwell <ch...@team193.com> wrote: > While i think of it, would it be any use to have a defaultEventType > attribute for the event-handlers block, like Coldspring has the > defaultAutoWire attribute for the beans tag? > <event-handlers defaultEventType="TemplatedEvent,SecuredEvent"> > ... > </event-handlers> > <event-handlers defaultEventType="SomeOtherEventType"> > ... > </event-handlers> > <event-handlers> > ... > </event-handlers>
Oooh, I like that. That would allow a developer, for example, to have one set of default event types for the public side and a different set of default event types for the admin side.
Were you thinking that that approach would be in addition to being able to set one set of default event types in the model-glue config, or in place of that? I can see how giving developers two different ways of specifying default event types could be seen as confusing by some, but it would allow for maximum flexibility.
> On Tue, May 19, 2009 at 5:22 PM, Chris Blackwell <ch...@team193.com>
> wrote:
> > While i think of it, would it be any use to have a defaultEventType
> > attribute for the event-handlers block, like Coldspring has the
> > defaultAutoWire attribute for the beans tag?
> > <event-handlers defaultEventType="TemplatedEvent,SecuredEvent">
> > ...
> > </event-handlers>
> > <event-handlers defaultEventType="SomeOtherEventType">
> > ...
> > </event-handlers>
> > <event-handlers>
> > ...
> > </event-handlers>
> Oooh, I like that. That would allow a developer, for example, to have
> one set of default event types for the public side and a different set
> of default event types for the admin side.
> Were you thinking that that approach would be in addition to being
> able to set one set of default event types in the model-glue config,
> or in place of that? I can see how giving developers two different
> ways of specifying default event types could be seen as confusing by
> some, but it would allow for maximum flexibility.
I'm just trying to play the defensive role... I'm on the side of being very
conservative on changes to the framework. I think any feature should be
declined by default and only added if a war is waged and the winners wanted
the feature. :) (Or if I want the feature... then it should go in too.)
Doug Hughes, President
Alagad Inc.
dhug...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836
On Tue, May 19, 2009 at 5:41 PM, Doug Hughes wrote: > I'm just trying to play the defensive role... I'm on the side of being very > conservative on changes to the framework. I think any feature should be > declined by default and only added if a war is waged and the winners wanted > the feature. :) (Or if I want the feature... then it should go in too.)
> Doug Hughes, President > Alagad Inc. > dhug...@alagad.com > 888 Alagad4 (x300) > Office: 919-550-0755 > Fax: 888-248-7836
> On Tue, May 19, 2009 at 6:34 PM, denstar <valliants...@gmail.com> wrote:
>> On Tue, May 19, 2009 at 1:50 PM, Dan Wilson wrote: >> > I want to start a thread about Default Event Types.
>> What about using some form of advice instead of configuring the event >> handlers themselves?
>> I had pretty good success wrapping the event stuff in some CS advice >> and doing things based on the event name, etc..
>> Just tossing it out there. *shrug*
>> -- >> Avoid lawsuits beyond all things; they pervert your conscience, impair >> your health, and dissipate your property. >> Jean de la Bruyere
> Doug Hughes, President
> Alagad Inc.
> dhug...@alagad.com
> 888 Alagad4 (x300)
> Office: 919-550-0755
> Fax: 888-248-7836
> On Tue, May 19, 2009 at 5:40 PM, Bob Silverberg <bob.silverb...@gmail.com > > wrote:
> On Tue, May 19, 2009 at 5:22 PM, Chris Blackwell <ch...@team193.com>
> wrote:
> > While i think of it, would it be any use to have a defaultEventType
> > attribute for the event-handlers block, like Coldspring has the
> > defaultAutoWire attribute for the beans tag?
> > <event-handlers defaultEventType="TemplatedEvent,SecuredEvent">
> > ...
> > </event-handlers>
> > <event-handlers defaultEventType="SomeOtherEventType">
> > ...
> > </event-handlers>
> > <event-handlers>
> > ...
> > </event-handlers>
> Oooh, I like that. That would allow a developer, for example, to have
> one set of default event types for the public side and a different set
> of default event types for the admin side.
> Were you thinking that that approach would be in addition to being
> able to set one set of default event types in the model-glue config,
> or in place of that? I can see how giving developers two different
> ways of specifying default event types could be seen as confusing by
> some, but it would allow for maximum flexibility.
I'm not prepared to wage war over it, but I suggest that the simple
version (allowing for a single list of default event types in the
model-glue config) is not really a change to the framework.
Event types are new to MG3, so now's the time to make sure that they
are implemented in the most useful way. I truly believe that this
would be a very useful feature and really is in keeping with the
spirit of event types (which is to save on having to specify the same
logic in multiple places).
I agree that the suggestions that result in added complexity to the
XML file might not be the best route, even though they may extend the
usefulness of the feature.
So I suppose my stance is that default event types should be made
available, but perhaps only in the simplest way.
Cheers,
Bob
On 19-May-09, at 7:41 PM, Doug Hughes <dhug...@alagad.com> wrote:
> I'm just trying to play the defensive role... I'm on the side of
> being very conservative on changes to the framework. I think any
> feature should be declined by default and only added if a war is
> waged and the winners wanted the feature. :) (Or if I want the
> feature... then it should go in too.)
> Doug Hughes, President
> Alagad Inc.
> dhug...@alagad.com
> 888 Alagad4 (x300)
> Office: 919-550-0755
> Fax: 888-248-7836
> On Tue, May 19, 2009 at 6:34 PM, denstar <valliants...@gmail.com>
> wrote:
> On Tue, May 19, 2009 at 1:50 PM, Dan Wilson wrote:
> > I want to start a thread about Default Event Types.
> What about using some form of advice instead of configuring the event
> handlers themselves?
> I had pretty good success wrapping the event stuff in some CS advice
> and doing things based on the event name, etc..
> Just tossing it out there. *shrug*
> --
> Avoid lawsuits beyond all things; they pervert your conscience, impair
> your health, and dissipate your property.
> Jean de la Bruyere
The nice thing about the XML approach is that it's explicit.
I pretty much always split my MG XML into separate files, for the sake of organization, so the suggested modification to the event-handlers block would tie in quite nice.
A nice thing about XML is that you don't *have* to define the element if it's not required by the DTD ;).
There's always CS for advice based on event names* (tho it would be nice if one didn't have to extend the MG core to wrap the event handler stuff, and it was in the default ModelGlue.xml instead, like the orm stuffs).
*Example name-based advice is stuff like public.home, private.home, sometemplate.mainpage, public.sometemplate.home, etc.. with SES for pretty-ness and whatnot.
-- If our life is unhappy it is painful to bear; if it is happy it is horrible to lose, So the one is pretty equal to the other. Jean de la Bruyere
On Tue, May 19, 2009 at 8:20 PM, Bob wrote: > I'm not prepared to wage war over it, but I suggest that the simple version > (allowing for a single list of default event types in the model-glue config) > is not really a change to the framework. > Event types are new to MG3, so now's the time to make sure that they are > implemented in the most useful way. I truly believe that this would be a > very useful feature and really is in keeping with the spirit of event types > (which is to save on having to specify the same logic in multiple places). > I agree that the suggestions that result in added complexity to the XML file > might not be the best route, even though they may extend the usefulness of > the feature. > So I suppose my stance is that default event types should be made available, > but perhaps only in the simplest way. > Cheers, > Bob
I don't think it would really. The main change would be to add the
defaultEventType attribute to <event-handlers>, this would be optional so I
don't see that causes a problem. Allowing multiple <event-handlers> blocks
in a single config file wouldn't break any existing apps
I guess it would just require some documentation, and therein lies the real
problem ;)
> Doug Hughes, President
> Alagad Inc.
> dhug...@alagad.com
> 888 Alagad4 (x300)
> Office: 919-550-0755
> Fax: 888-248-7836
> On Tue, May 19, 2009 at 5:40 PM, Bob Silverberg <bob.silverb...@gmail.com>wrote:
>> On Tue, May 19, 2009 at 5:22 PM, Chris Blackwell <ch...@team193.com>
>> wrote:
>> > While i think of it, would it be any use to have a defaultEventType
>> > attribute for the event-handlers block, like Coldspring has the
>> > defaultAutoWire attribute for the beans tag?
>> > <event-handlers defaultEventType="TemplatedEvent,SecuredEvent">
>> > ...
>> > </event-handlers>
>> > <event-handlers defaultEventType="SomeOtherEventType">
>> > ...
>> > </event-handlers>
>> > <event-handlers>
>> > ...
>> > </event-handlers>
>> Oooh, I like that. That would allow a developer, for example, to have
>> one set of default event types for the public side and a different set
>> of default event types for the admin side.
>> Were you thinking that that approach would be in addition to being
>> able to set one set of default event types in the model-glue config,
>> or in place of that? I can see how giving developers two different
>> ways of specifying default event types could be seen as confusing by
>> some, but it would allow for maximum flexibility.
We can def do without any more wars :) I've been thinking about how i use event types and looking back over a few apps i never use an event type for every event (ie a default event), or have an event type thats used in a single place (which is pointless). I'm always using event types on groups of handlers.
So specifiying an all encompassing default type doesn't do much for me as i'd have to pick my most commonly used types then override on every handler where i need a different type or adding type="" where I don't want a default, which seems wrong.
Adding an optional attribute doesn't seem like anymore of a change than a config property. If allowing multiple <event-handlers> blocks in a single config file is a problem, then i'd settle for splitting my differently typed events into separate files, but as it wouldn't break any existing apps I think it would be fine.
> I'm not prepared to wage war over it, but I suggest that the simple version > (allowing for a single list of default event types in the model-glue config) > is not really a change to the framework.
> Event types are new to MG3, so now's the time to make sure that they are > implemented in the most useful way. I truly believe that this would be a > very useful feature and really is in keeping with the spirit of event types > (which is to save on having to specify the same logic in multiple places).
> I agree that the suggestions that result in added complexity to the XML > file might not be the best route, even though they may extend the usefulness > of the feature.
> So I suppose my stance is that default event types should be made > available, but perhaps only in the simplest way.
I must admit that if pressed to pick an idea I liked best, I like having the
ability to have multiple <event-handlers> blocks with an eventType attribute
which overrides the event type attribute on the <event-handler> tag.
Doug Hughes, President
Alagad Inc.
dhug...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836
On Wed, May 20, 2009 at 3:14 AM, Chris Blackwell <ch...@team193.com> wrote:
> We can def do without any more wars :)
> I've been thinking about how i use event types and looking back over a few
> apps i never use an event type for every event (ie a default event), or have
> an event type thats used in a single place (which is pointless). I'm always
> using event types on groups of handlers.
> So specifiying an all encompassing default type doesn't do much for me as
> i'd have to pick my most commonly used types then override on every handler
> where i need a different type or adding type="" where I don't want a
> default, which seems wrong.
> Adding an optional attribute doesn't seem like anymore of a change than a
> config property. If allowing multiple <event-handlers> blocks in a single
> config file is a problem, then i'd settle for splitting my differently typed
> events into separate files, but as it wouldn't break any existing apps I
> think it would be fine.
>> I'm not prepared to wage war over it, but I suggest that the simple
>> version (allowing for a single list of default event types in the model-glue
>> config) is not really a change to the framework.
>> Event types are new to MG3, so now's the time to make sure that they are
>> implemented in the most useful way. I truly believe that this would be a
>> very useful feature and really is in keeping with the spirit of event types
>> (which is to save on having to specify the same logic in multiple places).
>> I agree that the suggestions that result in added complexity to the XML
>> file might not be the best route, even though they may extend the usefulness
>> of the feature.
>> So I suppose my stance is that default event types should be made
>> available, but perhaps only in the simplest way.
I think that would be the most useful implementation as well. I was just addressing your concerns of adding complexity to the xml. It's true that adding a single attribute to the <event-handlers> element doesn't add that much complexity - I think it's more in the way that people will then have to write their <event-handlers> blocks, meaning that they'll have to put thought into which events to group into which <event-handlers> blocks. Not that that's a bad thing, but it does introduce one more thing to think about.
On Wed, May 20, 2009 at 5:57 AM, Doug Hughes <dhug...@alagad.com> wrote: > I must admit that if pressed to pick an idea I liked best, I like having the > ability to have multiple <event-handlers> blocks with an eventType attribute > which overrides the event type attribute on the <event-handler> tag.
I'm still not sure I see a clear use case for a default event type.
Can anyone show me an example where my time spent learning MG, developing an application, and maintaining that application is reduced with this feature?
Bob Silverberg wrote: > I think that would be the most useful implementation as well. I was > just addressing your concerns of adding complexity to the xml. It's > true that adding a single attribute to the <event-handlers> element > doesn't add that much complexity - I think it's more in the way that > people will then have to write their <event-handlers> blocks, meaning > that they'll have to put thought into which events to group into which > <event-handlers> blocks. Not that that's a bad thing, but it does > introduce one more thing to think about.
I can think of many cases where the majority of my events which are
responsible for rendering output would need the "TemplatedEvent" type.
By allowing me to specify that as the default event type I can avoid
having to specify it on each event handler than needs it.
The latest idea from Chris extends that even further, where one could
group together event handlers that share a common type (or types), and
then specify that type in the event-handlers block, and thereby avoid
having to specify it on each event handler.
It's not something that everyone would use (nor would they have to use
it), but I definitely see value in it.
> I'm still not sure I see a clear use case for a default event type.
> Can anyone show me an example where my time spent learning MG,
> developing an application, and maintaining that application is reduced
> with this feature?
> Bob Silverberg wrote:
>> I think that would be the most useful implementation as well. I was
>> just addressing your concerns of adding complexity to the xml. It's
>> true that adding a single attribute to the <event-handlers> element
>> doesn't add that much complexity - I think it's more in the way that
>> people will then have to write their <event-handlers> blocks, meaning
>> that they'll have to put thought into which events to group into which
>> <event-handlers> blocks. Not that that's a bad thing, but it does
>> introduce one more thing to think about.
It sounds like we are getting closer to a practical implementation of a
default event type. This discussion has been very productive and helpful.
Keep the ideas coming!
DW
On Wed, May 20, 2009 at 8:22 AM, Bob Silverberg <bob.silverb...@gmail.com>wrote:
> I can think of many cases where the majority of my events which are
> responsible for rendering output would need the "TemplatedEvent" type.
> By allowing me to specify that as the default event type I can avoid
> having to specify it on each event handler than needs it.
> The latest idea from Chris extends that even further, where one could
> group together event handlers that share a common type (or types), and
> then specify that type in the event-handlers block, and thereby avoid
> having to specify it on each event handler.
> It's not something that everyone would use (nor would they have to use
> it), but I definitely see value in it.
> On Wed, May 20, 2009 at 8:11 AM, David Henry
> <davidhe...@coldfusionpowered.com> wrote:
> > I'm still not sure I see a clear use case for a default event type.
> > Can anyone show me an example where my time spent learning MG,
> > developing an application, and maintaining that application is reduced
> > with this feature?
> > Bob Silverberg wrote:
> >> I think that would be the most useful implementation as well. I was
> >> just addressing your concerns of adding complexity to the xml. It's
> >> true that adding a single attribute to the <event-handlers> element
> >> doesn't add that much complexity - I think it's more in the way that
> >> people will then have to write their <event-handlers> blocks, meaning
> >> that they'll have to put thought into which events to group into which
> >> <event-handlers> blocks. Not that that's a bad thing, but it does
> >> introduce one more thing to think about.
By applying an event type to a group of events instead of individual events the xml becomes easier to understand at a glance. Improved code comprehension makes for faster and easier application maintenance by developers unfamiliar with an application. Removing the repetitive type declaration makes code refactoring easier and less error prone. Grouping handlers by type makes David less likely to accidentally expose administrative functions without password protection. An example usage could look something like this:
davidhe...@coldfusionpowered.com> wrote:
> I was fishing for an answer more like this:
> By applying an event type to a group of events instead of individual events
> the xml becomes easier to understand at a glance. Improved code
> comprehension makes for faster and easier application maintenance by
> developers unfamiliar with an application. Removing the repetitive type
> declaration makes code refactoring easier and less error prone. Grouping
> handlers by type makes David less likely to accidentally expose
> administrative functions without password protection. An example usage
> could look something like this:
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 <dhug...@alagad.com> 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. > dhug...@alagad.com > 888 Alagad4 (x300) > Office: 919-550-0755 > Fax: 888-248-7836
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 <dhug...@alagad.com> 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. >> dhug...@alagad.com >> 888 Alagad4 (x300) >> Office: 919-550-0755 >> Fax: 888-248-7836
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.
<davidhe...@coldfusionpowered.com> 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 <dhug...@alagad.com> 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.
> dhug...@alagad.com
> 888 Alagad4 (x300)
> Office: 919-550-0755
> Fax: 888-248-7836
> 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
> <davidhe...@coldfusionpowered.com> 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 <dhug...@alagad.com>
> wrote:
> > If we're grouping events by type, then the attribute on event-handlers
> > should not be default, but type.
|
