Andy Smith's Blog

Page.RegisterStartupScript('Andy', 'MetaBuilders_WebControls_GainKnowledge();');

Event handler declarations in the tag are the right thing

Teemu brought up the current event declaration behavior today, and even pointed to a bug report about it.

I'm going to take the opposite stance. putting the onclick="whatever" attribute on the tag is the best solution to a complicated problem. Now, if the problem were limited to the points that Teemu addresses, then yes, it looks like it should changable based on the current dev model. However, the thing that makes this problem more complicated is that not every control is at the top level of your page. Asp.net uses a hierarchal declaration system with containers and child controls. One by-product of this system is that not all design-time-selectable controls on your page have references at the page level, or even refer to a single instance of a control ( in the case of a databound template declaration ).

So, if you drag a button onto your form, and double click it to add a hook to the Click event, there are 2 or 3 basic choices ( depending on language ( VB has the Handles thing going on ))... add the glue to the tag, or add it in some initialization code block. Some want to use the code block because they don't like their UI declration to know the name of the handler function of the event.

However, the hole there is that if you now move that button from the top level of the page's heirarchy, into a INamingContainer like a Repeater's ItemTemplate, then the instance referenced in the initialization-block doesn't exist. ( VB's Handles doodad breaks here too )

So how should the designer attach to events in child controls if there is no top level instance to code against, nor any guarentee that the child control will exist at any given initialization time ( or be instantiated at all during that request for that matter )? To me, it seems it can't ensure correctness with any way but declarative. Which follows to the next point... Should it really use two completely different hookup mechanisms for top-level and child controls? I assert that it shouldn't as that would lead to some nitemare maintainability problems. ( "I know that it's hooked up somewhere, where did that code block go now?" ) Therefore... the tag declaration is the correct place for the designer to hook up event handlers.

Comments

AndrewSeven said:

I'm not sure I understand the bug report. It seems to be an issue with respecting the selected mode rather than attribute specified handlers.

If I hadn't gotten around so many little issues by using OnServerEvent="HandlerName" instead of wiring it up in code, I might not be so quick to agree.
What about those not too infrequent questions about event handlers for controls added on the fly, genre : myNewControl.OnClick = "MyControl_ClickTest";
They are still going to need a really really simple way

Handles ... If you name your control just right I Handles it?


I think it is better for the UI to know the names of methods than for methods to know the names of the UI elements.

# September 14, 2004 10:33 PM

Michael Teper said:

Andy, I see your point, but I think the problem is that this just hasnt been thought through by the IDE team. For example, has they created a BindChildControlHandlers event for the express purpose of initializing child event bindings, the IDE would have very clear heuristics to follow for that sort of stuff.
# September 15, 2004 3:38 AM

Teemu Keiski said:

Thank you Andy for the comments,

I agree these are good points, thank you for bringing them up, but isn't the question then just how smart the IDE actually is or can be (for example keeping references to related code parts)? Bit like Michael pointed out? If we get into that level, yes, it would be the best if the IDE could do the wireup in code for control despite the hierarchy. ;-) (This is just dreaming, I know)

After all, I see it as problem because I have explicitly selected the code model (my discussion concerns only and only code-beside, the inline model is fine) I use, and I think that the IDE should then stick to that and not take any inline-like behavior in use. It just should stick to the model, or if it seems appropriate, be smart enough to make suggestions (more dreaming...) but not just assume how I *might* want it to be done.

I understand that having single model to attach event handlers despite the control hierarchy is easier and unified, but I have made as user of VS.NET the selection that I want to use code-beside model and then I see that all stuff related to my code goes to the code class. Personally I just see that following the code model is more important than making ad-hoc wiring solutions. I don't always want everything to be easier. ;-)

And yes, in my opinion UI should not know the names of the methods. If I want to use similar sort deployment model as so far, I want to be able to refactor my code-behind without having to consider at all to which control this method is wired to. Certainly, this is quite theoretical view to the thing now.

But all in all, we go with personal preferences here, so lets not make this any sort of issue. :-) I love discussing these with other people, I learn something new every time.

Thank you,

Teemu
# September 15, 2004 4:17 AM

J. Ambrose Little said:

Check it out!
# September 15, 2004 11:33 AM

WMP said:

This is related to the previous post.

You can now request new features for Windows Media Player at http://www.microsoft.com/windows/windowsmedia/community/wish.aspx
# October 14, 2004 4:58 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)