Default Event Type

[Dan Wilson]

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#HowToUseTypedEvents )

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.”

Guillaume Apollinaire quotes

[Doug Hughes]

If it doesn't vanish when you ad other event types, how do you indicate that an event is untyped?

Doug Hughes, President
Alagad Inc.
dhu...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836

[Bob Silverberg]

On Tue, May 19, 2009 at 3:50 PM, Dan Wilson <sipa...@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#HowToUseTypedEvents
> )
> 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:

<event-types>
<default-event-types="TemplatedEvent,SecuredEvent" />
<event-type name="TemplatedEvent">
<after>
<views>
<include name="main" template="templates/main.cfm" />
</views>
</after>
</event-type>
<event-type name="SecuredEvent">
<before>
<broadcasts>
<message name=”LoginRequired” />
</broadcasts>
<results>
<result name=”NotLoggedIn” do=”user.login” />
</results>
</before>
</event-type>
</event-types>

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

--
Bob Silverberg
www.silverwareconsulting.com

[Chris Blackwell]

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?

<event-handlers defaultEventType="TemplatedEvent,SecuredEvent">

...

</event-handlers>

<event-handlers defaultEventType="SomeOtherEventType">

...

</event-handlers>

<event-handlers>

...

</event-handlers>

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.

Chris

[Bob Silverberg]

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.

Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Doug Hughes]

Any concern that this muddies up the XML?

Doug Hughes, President
Alagad Inc.
dhu...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836

[denstar]

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]

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.
dhu...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836

[denstar]

Dude, saying "no", is like, a fscking *skill*.

Unless you yourself have a need, of course! ;-)

I'm very fond of heavy vetting (that almost sounded funny)-- if the
need/use cases don't stand up under that bright light, that's "a
sign", ja know?

FWIW, accomplishing this end goal seems like it would give *far* more
bang for the buck than, say, dicking with lazy-loading controllers.

Scaffolding, for instance, is has some pretty good ROI as far as R&D
and whatnot. We could make sooooo many people's lives sooooooo much
easier... ;-)

So, be an advocate for the devil all you want, he (she? ;]) always
gets his due, so it's best to think about it a bit ahead of time.

--
"Three cheers for not just saying 'yes, sounds swell, done deal'"
-Denny

[Gmail]

Yes. Although it still sounds like a useful feature. I see pros and cons to this suggestion. 

Sent from my iPhone

[Gmail]

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

[denstar]

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

[Chris Blackwell]

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 ;)

2009/5/19 Doug Hughes <dhu...@alagad.com>

[Chris Blackwell]

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.

Back to some real work now

Chris

2009/5/20 Gmail <bob.sil...@gmail.com>

[Doug Hughes]

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.
dhu...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836

[Bob Silverberg]

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 <dhu...@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.
>

--
Bob Silverberg
www.silverwareconsulting.com

[David Henry]

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]

Just look at the existing info on event types at
http://docs.model-glue.com/wiki/HowTos/HowToUseTypedEvents#HowToUseTypedEvents.

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.

--
Bob Silverberg
www.silverwareconsulting.com

[Dan Wilson]

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

[David Henry]

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:



    <event-types>


        <event-type name="SecuredEvent">
            <before>
                <broadcasts>
                    <message name="LoginRequired" />
                </broadcasts>
                <results>
                    <result name="NotLoggedIn" do="user.login" />
                </results>
            </before>
        </event-type>
    </event-types>   


    <event-handlers defaultType="SecuredEvent">
        <event-handler name="admin.administrate">
            <broadcasts>
                <message name="AdminIsDoingStuff" />
            </broadcasts>
            <views>
                <include name="body" value="admin.cfm" />
            </views>
        </event-handler>
       
        ...

    </event-handlers>

    <event-handlers>
        <event-handler name="home.page">
            <views>
                <include name="home" value="home.cfm" />
            </views>
        </event-handler>
        ...
    </event-handlers>

[Doug Hughes]

If we're grouping events by type, then the attribute on event-handlers should not be default, but type.

Doug Hughes, President
Alagad Inc.
dhu...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836

[Bob Silverberg]

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 <dhu...@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.
> dhu...@alagad.com
> 888 Alagad4 (x300)
> Office: 919-550-0755
> Fax: 888-248-7836
>
>

--
Bob Silverberg
www.silverwareconsulting.com

[David Henry]

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]

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?

--
Bob Silverberg
www.silverwareconsulting.com

[Doug Hughes]

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.
dhu...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836

[denstar]

On Wed, May 20, 2009 at 9:33 AM, Doug Hughes 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?

Are you saying that because you looked at what needs changing in the
code, or because we've been hashing it out so well?

If it's the former, ok, that's valid, but if it's the later, I'm
actually kinda happy with the discussion, and don't think it implies a
muddy concept.

FWIW, I like the idea of defaultType in the handlers block, which can
be overridden for each handler.

Seems to make semantic sense, will cut down on cut'n'pasting (always
nice), and encourages people to organize their handlers (I've been
splitting things into their own files, usually by controller, for
ages, and I can tell you, coming from a 4am coder, it's made a pretty
big difference in "finding" stuff).

--
Next to sound judgment, diamonds and pearls are the rarest things in the world.
Jean de la Bruyere

[Jamie Krug]

@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 <dhug...@alagad.com> 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.

> dhug...@alagad.com

> 888 Alagad4 (x300)
> Office: 919-550-0755
> Fax: 888-248-7836
>
> On Wed, May 20, 2009 at 11:09 AM, Bob Silverberg

> <bob.silverb...@gmail.com>wrote:

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

[Chris Blackwell]

@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 <jami...@gmail.com>

[Bob Silverberg]

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

--
Bob Silverberg
www.silverwareconsulting.com

[Josen Ruiseco]

Orders are in.

[Josen Ruiseco]

Sorry guys. Mis-emailed that one... Hehe

-----Original Message-----
From: model...@googlegroups.com [mailto:model...@googlegroups.com] On
Behalf Of Bob Silverberg
Sent: Thursday, May 21, 2009 6:50 AM
To: model...@googlegroups.com
Subject: [Model-Glue] Re: Default Event Type

[Dan Wilson]

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

[Jamie Krug]

On May 21, 2:53 am, Chris Blackwell <ch...@team193.com> 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

@Chris: Yes, I'm with you on this. When you first introduced the idea
of multiple event-handlers in a file, the idea of the single event-
handler override with the type attribute wasn't mentioned, so I was
uneasy with that. The more I think about it now, the more I like this
idea -- exactly as you've just summarized.

The only situation I could see being slightly confusing is when you
have multiple default event types for an event-handlers block and, for
a single event-handler, you'd like to remove one of the default types
and add a new type. In this situation you'd have to list both your new
type and "repeat" any of the default types that you'd like to keep in
your event-handler type attribute. It feels a little funny to list a
default type in an explicit event-handler type attribute, but since
you need that to be an override, it's the only option I can think of.
I just mention it as the only situation I can see not being crystal
clear, but I'm okay with it -- still has my vote.

Here's an example, in which I want to override/remove the "secured"
default type, but keep the "templated" default type and add a "foo"
type:

<event-handlers defaultType="secured,templated>
<event-handler name="login.form" type="templated,foo">
</event-handler>
</event-handlers>

Best,
Jamie

[David Henry]

Too busy to read the whole thing?  Executive summary: just read the bold words.

Methinks there may be a cart before a horse in this process.  The timeline (as I understand it):

1. Feature was named (in a question given mid-presentation was it?)
   
2. Functionality was considered (not sure this totally matches the feature name)
   
3. Need for the feature is discovered (hasn't happened yet imho)
   

I am a relative Model Glue newbie and I haven't built any large Model Glue applications yet but I do have lots of experience with feature creep.  This has all the classic signs of a "ya know what'd be nice is..." request that can soak up developer time away from stuff that would be more useful.

Why does the framework need this?  Give me a cost vs benefit analysis.  In what way am I better organized and prepared to do my job good, fast and cheap?  If I'm just completely missing the part of the conversation where someone pointed that out, please break it down for me again nice and slow. 

As a new user, simply saving me 47 keystrokes in my config is not worth the extra time I have to put into thinking about how to use this framework.  If I were a totally new MG user, learning Model-Glue day 1, and I saw the feature in the documentation I would agonize over whether or not I should be using default events just because the name sounds interesting and it was in the documentation.  I'd probably do it completely wrong at least once.   I already have plenty to agonize over.

~David

[Rich]

BRAVO!

I'm so going to use this "just read the bold words..." feature in all of my emails with my clients going forward, excellent!!!

Again, I've not even looked at MG3, but I'm always in favor of K.I.S.S.... (because I'm the representative for that last "S" ;-) )

FWIW,

Rich

Rich Leach

Advanced Certified Adobe ColdFusion Developer

ri...@cfsnap.com

http://www.cfsnap.com

303-913-7338

Instant Messenger:

AOL AIM: cfsnaprich

Instant Video Conference:

APPLE MobileMe: rich...@me.com

[Lola J. Lee Beno]

Rich wrote:
> BRAVO!
>
> I'm so going to use this "just read the bold words..." feature in all
> of my emails with my clients going forward, excellent!!!
>
> Again, I've not even looked at MG3, but I'm always in favor of
> K.I.S.S.... (because I'm the representative for that last "S" ;-) )

I would have to second this . . . this is one of the best, most creative
writing and editing I've ever seen. I'm definitely going to use this
technique in the future . . .

--
Lola J. Lee Beno
LinkedIn: http://www.linkedin.com/in/lolajleebeno
Facebook: http://www.facebook.com/profile.php?id=714355583
Blog: http://www.lolajl.net/blog/

[Adam Tuttle]

Yes, the bold-only thing was clever. Well done.

To stay on-topic: I'm not entirely sure what you're asking about. I'm familiar with the Default Event configuration setting, and I'm familiar with Event Types. Which one are you questioning?

Adam

[Adam Tuttle]

Sorry, I just saw the other thread; and unfortunately I wasn't at cfObjective... (This is why you shouldn't change the subject line unless there's a topic change!)

My bad. (Nothing to see here... move along!)

Adam

[David Henry]

You guys are making me blush, stop :D ... clever bolding, not so clever changing the thread title.

[denstar]

On Thu, May 21, 2009 at 7:45 AM, Jamie Krug wrote:
...

> The only situation I could see being slightly confusing is when you
> have multiple default event types for an event-handlers block and, for
> a single event-handler, you'd like to remove one of the default types
> and add a new type. In this situation you'd have to list both your new
> type and "repeat" any of the default types that you'd like to keep in
> your event-handler type attribute. It feels a little funny to list a
> default type in an explicit event-handler type attribute, but since
> you need that to be an override, it's the only option I can think of.
> I just mention it as the only situation I can see not being crystal
> clear, but I'm okay with it -- still has my vote.

I've run into the same thing with scaffolding.

What about "special" keywords? Something like:

<event-handlers defaultType="secured,templated>
       <event-handler name="login.form" type="_allExcept_secured,foo">
       </event-handler>
</event-handlers>

Kinda ugly, but... it's an idea. =]

--
The great gift of conversation lies less in displaying it ourselves
than in drawing it out of others. He who leaves your company pleased
with himself and his own cleverness is perfectly well pleased with
you.
Jean de la Bruyere

[Chris Blackwell]

I've just taken a shot at implementing this feature.

All of the heavy lifting is done by /ModelGlue/gesture/module/XMLModuleLoader.cfc, and looking at the way ModelGlue.xml is parsed, it appears that multiple <event-handlers> blocks (indeed most xml nodes) can already appear more than once, so no change needed there.

To implement the defaultType attribute only needed 2 tiny tweaks, see the attached diff.

heres a quick example of the xml

<event-types>

<event-type name="MyDefaultEventType">

<after>

<results>

<result do="template.main" />

</results>

</after>

</event-type>

<event-type name="AnotherEventType">

<after>

<results>

<result do="template.different" />

</results>

</after>

</event-type>

</event-types>

<!-- declares the default event type -->

<event-handlers defaultType="MyDefaultEventType">

<!-- inherits the defaultType -->

<event-handler name="page.1">

</event-handler>

<!-- overrides the defaultType and only gets AnotherEventType -->

<event-handler name="page.2" type="AnotherEventType">

</event-handler>

<!-- removes the defaultType -->

<event-handler name="page.3" type="">

</event-handler>

</event-handlers>

<!-- no default type declared -->

 <event-handlers>

<!-- apply event type individually  -->

<event-handler name="page.3" type="AnotherEventType">

</event-handler>

</event-handlers>

Anyway, take a look, try it out and let me know if anything blows up :)

Chris

[Dan Wilson]

Hey Folks. 

An Update.

Doug Hughes and I sorted out the Unit Test to test XMLModuleLoader so now all those tests are now running as expected. This means I can now get around to implementing this default event type patch from Chris.

I am going to put this into a branch and let a select few people play with it. Mostly the people on this email thread, since they know the most about what we want to do. With any luck, I'll have this up and dropped tomorrow or Thursday.

I'll be out of the office Fri-Monday and won't be thinking of ModelGlue at all. So Long Suckers!

DW

[Dan Wilson]

OK,

This link will get you a build of the Default Event Types. It does pass unit testing and I'd like feedback on usefulness and on usability.

http://datacurl.com/modelglue/ModelGlue-DefaultEventTypes.zip

DW