Element behaviors

For a while now I've been coding away on a fairly hairy DHTML/JavaScript project. The project is basically a browser-based image viewing and annotation UI. So far I've mostly been working in straight-up JavaScript, with the server component wrapped into an ASP.NET Server Control.

Today I started taking a hard look at element behaviors in IE (aka viewlink behaviors). At first, it seemed like a very promising route. Basically I'm writing JavaScript that boils down to a client-side "control", and wrapping that up in a custom element would have been pretty nice. After a few hours of poking and prodding and experimenting, I ran across the catch. It seems that element behaviors can't participate in form postback - any form fields contained in the custom element don't show up in the form fields back at the server. People have hacked around this limitation by using a hidden form fields on the parent form, then copying the element's field values to the parent's hidden fields. That's workable for simple behaviors with just a couple of fields, but it would have been too complicated in my case.

So now I'm back to good ol' basic JavaScript. It's a shame when otherwise very cool and promising technology is rendered unusable because of a simple limitation like that. Incidentally, I didn't find this limitation anywhere in the documentation - only in a couple technical articles that I ran across during my research.

3 Comments

  • Element Behaviors are extremely cool, but yes they suffer from that defect. The way I handle it is to serialize the element behavior and use XmlHttp obbject in MSXML to do the post. This is an early version of Web Services. If you ever need any Element Behavior help, contact me.



    On a side note, the concept of Element Behaviors is taken to the next level in Longhorn's new UI engine Avalon.



    DonXML

  • Element behaviors are also problematic for screen readers that parse HTML because they're rendered as namespaced custom elements that the reader doesn't know how to parse. Best to stay away from them.



    Have you looked at "normal" (attached) behaviors?



    In any case, pure .js "include" files are much more performant and have no weird side-effects.

  • Element behaviors "suffer" from this inability becouse they all tend to be "isolated" from the outside page. You can always create hiddens in the parent document from your element behavior and thus include data for reply. This is like "registering" for data submission.

    anyway, I found these behaviors very heavy-weight and didn't use them finally, becouse they require very good computer with a lot of memory on the client side (thin-client does not apply then :-))

    it also work only with IE... obviously :-)

Comments have been disabled for this content.