jQuery Failed Me?

by Jon Davis 10. December 2008 19:52

I had a painful and uncomfortable epiphany today, one that should not go unnoticed. In building up a form consisting of about 30 fields, I processed all of the "submitted values restoration databinding"--that is, re-populating the fields' values after submitting the form because the form failed validation--in script, using jQuery, like so:

(Yes, this is VBScript in ASP Classic:)

	<% For Each field In MyDictionary %>
	$("#<%=field%>").val("<%=Request(field)%>");<%
	Next %>
	

This was a really simple notion, to data-bind all my fields with just three lines of code. And it worked. It worked great. Except for one problem.

With thirty fields, plus code to add highlighting and such, it took jQuery, in IE7 (yes that monstrous piece of doo-doo, Internet Explorer) the browser kept locking up for five seconds every time the page was refreshed (that is, every time the form was posted locally with invalid field values), while it waited for jQuery to find each of these fields and populate their values. Now, I'm sure I could go back and do some optimizations; for example, I could have done the loop in reverse and limited my jQuery selector to a single search, something like:

	var fieldMap = {};
	<% For Each field In MyDictionary %>
	fieldMap["<%=field%>"]="<%=Request(field)%>";<%
	Next %>
	$("input").each(function() {
$(this).val(fieldMap[$(this).attr("name")]); });

But besides the fact that my code just grew, there was another problem with the jQuery approach. Some people turn script off altogether. Ultimately I had to do what I tried so hard not to do, which was this junky markup:

	<input type="checkbox" <%If Request("foobar") = "ABC" Then %>
	checked="checked"<% End If %> name="foobar" value="ABC" />
	<input type="text" value="<%=Request("acme")%>" name="acme" /> 
	

Now all of a sudden I had messy, difficult-to-maintain code. Any time you put implementation detail on the detail, such as here having field instance named data binding, you have messy code; I prefer to go abstract as much as possible.

But I didn't see any way around this.

Generally, people don't run into this problem. They typically settle for something like Web Forms, which imposes View State and ultimately suffers from similar performance issues in different ways.

I was lucky. I was doing my ASP Classic coding in Visual Studio 2008, which I might add would be a GREAT ASP Classic IDE, except for one not-so-small problem: VS crashes every time you quit the ASP Classic debugger. :(  Anyway, Visual Studio gave me the RegEx Find-and-Replce tool, which I spent no time thinking about; as soon as I realized I had to manually inject my binding code into the HTML markup, I started doing things like this:

        Find: name\=:q
Replace With: name\=\1 value\=\"\<\%\=Request(\1)\%\>\"

I did have a lot of bad runs for the several changes I had to make (thank Microsoft for Undo->Replace All), still in the end I saved a few minutes.

The end result was instantaneous refresh. Zero delay.

But after all that, I got up and went for a nature break (too much information?) and started asking myself, wait, what just happened? Till now I've started to sing the praises of jQuery about how wonderful it is and how it is our panacea to all the world's problems and ultimately hunger and disease in Zimbabwe and elsewhere in the world will end after we all adopt jQuery.

Now I'm coming to find that DOM traversing, in general, is not something that should be done on the client for such core operations as data-binding. This had me thinking again about Aptana Jaxer. Jaxer gives you jQuery (actually, browser-compatible Javascript in general) on the server by offering a Mozilla-based browser DOM on the server and spitting out to the client the resulting DOM markup in its modified state. But would this be any more performant?

It would be more performant than IE7 at least. Mozilla's JavaScript runtime is a lot faster than IE's Javascript runtime. But it's still client-side performance before the client ever receives anything. If nothing else, it would at least be perceived performance improvement because you don't see a web page build up all around you and then you have to wait for five seconds while the browser freezes.

Even so, Jaxer is not available in the workplace, nor should I ever expect it in my case.

I ended the day realizing that my curiosity of the notion of migrating all templating and forms and view logic off the server and onto the client might not be as desirable as I thought it would be. This could be a problem, too, for ASP.NET AJAX 4.0, which intends to migrate data binding to the client (something I celebrated when I found out about it).

Disable Text Selection In An HTML Document

by Jon Davis 12. November 2008 15:14

I just stumbled upon this. For months I've been wondering why it is that the nature of web browsers is such that if you're building a RIA where text selection would be inappropriate, such as in client-side "widgets" and "controls" where text appears as a label or text over an image to appear as a button, etc, but is rendered using HTML just the same, you cannot disable the user's ability to click-and-drag and thereby highlight text, creating a selection. This was partly disappointing for security reasons--disabling selection makes it more difficult to copy things that shouldn't be copied--and it was partly for UIX (user interface / experience) reasons--hiding from the user the obviousness that this is just a bunch of DHTML tricks and not a natively running app. I've always figured it was not possible in HTML to disable the user's ability to select text on the document. 

I was wrong! There's an old hat trick that's been around for quite a while. It's documented here:

http://support.microsoft.com/kb/318086

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Web Development

innerXHTML DOM-to-XHTML Generator in Javascript

by Jon Davis 13. March 2008 00:25

Developers often need XHTML-compliant HTML markup when they fetch DOM elements' innerHTML. Since the W3C hasn't standardized on this property (and I don't know why?!), the browsers have been inconsistent in their approaches to innerHTML. Firefox doesn't put the trailing slash in <br> tags, for instance, while Internet Explorer shows tags in all-caps and strips the quotation marks from some attributes.

This week after my rant got posted on Ajaxian.com, I figured I'd do my part to express my sincerity with the situation of by creating innerXHTML() and outerXHTML() functions in Javascript. Not the first-ever effort, but seemed appropriate considering the strong weight of my public rant. I intended to add it to the prototype of HTMLElement, but *gasp* .. wouldn't you know it, Internet Explorer doesn't expose a prototype for DOM elements!! Ack!! (Dang it, IE team, get out of your cave. :P )

So, take it or leave it, I wrote the innerXHTML() and outerXHTML() functions anyway, added them to the HTMLElement prototype for browsers that support it (yay Firefox), and added xhtml() for innerXHTML() equivalence for jQuery.

I posted it up at http://cachefile.net/scripts/xhtmljs/ with a lightweight test for initial coding efforts. More code than desirable is devoted to formatting (pretty line breaks and tabs), and if you don't like any of that fluff you can turn it off by setting the global variable xhtmlFormatting to "none" or, for now, to anything other than "formatted".

http://cachefile.net/scripts/xhtmljs/ 

Hope everyone likes it. Please give feedback (ideas, concerns, complaints, bug reports, etc) to jon@jondavis.net. I might post this on CodePlex if I get a lot of feedback, but in the absence of feedback I don't see much point.  

kick it on DotNetKicks.com

Currently rated 4.0 by 4 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , , , , , ,

Web Development

Last Anticipated Tidbit Of Suck Finally Removed From Internet Explorer 8

by Jon Davis 4. March 2008 17:08

Not long ago, I suggested the unthinkable, of boycotting Internet Explorer, if the IE8 team does not catch up with the rest of the Internet (with standards compliance, etc). And by "boycott" I literally mean to not only jump on the "don't use Internet Explorer" hatred bandwagon, but to completely stop building sites out and testing on Internet Explorer and just apologize later to visitors of my work that I did not double the amount of time that is involved in building a web application or site in order to get it to render correctly in IE, and to encourage to everyone that they do the same, and let Microsoft take responsibility for their own failures. After all, web technologies (HTML, Javascript, CSS, et al) are not Microsoft technologies, so if a web site is built using 100% standards compliant markup, really, it should just work, period.

But I'll hand it to Microsoft, as sincere as I was, and genuinely spiteful I was quickly becoming for their lame excuses, they have won back my respect.

First, they started blogging about IE8. The initial post really ticked me off, as my "boycott" link suggested, because they muttered something along the lines of "don't confuse silence with inaction". The Internet does NOT work that way, and the IE8 team should be the most pronounced and involved division of Microsoft, more so than any other division including the Visual Studio team. But each blog post related to IE8 has shown some kind of attempt to get feedback from the Internet community while at the same time giving answers to community feedback. Those answers were not always acceptable. But they have been thoughtful, or at least exposing thought processes. Transparency is a good thing in oneself; there's nothing that can bring about inner change for the better than exposing one's inner workings or thought patterns to people who care. The IE8 team still has a lot to learn about transparency, but it's one small step in the right direction.

Then, they passed the ACID2 test. That says a lot. It says that they care about standards compliance, and getting their product up to speed on what the industry has already established. And heck, it even shows that Microsoft even cares about having a competitive advantage again in Internet Explorer, for the first time since v4. (Needless to say, they'll have to work hard to keep that up while working against the productivity of the Webkit and Firefox teams.) Time will tell if the IE8 team is paying close attention to the new ACID3 test.

Yesterday, though, they reversed their rediculous proposal that demanded that the standards group require web developers (like you and me) to insert a version tag to every @#$% standards-compliant web page that they produce if they want it to render correctly in Internet Explorer 8. That Microsoft even attempted to push this still floors me, but that they heard the outcry from the developer community definitely reverses most of my animosity towards their behaviors. I mean, the audacity to ask the whole world to outwardly apologize for IE6 glitch behavior, rather than the IE team taking the heat for their past mistakes, really blows me away. But with their reversal of this move, I suppose I'm one step closer to getting warm and fuzzy about IE again.

I'm not there yet; I don't suppose I will be there until I see the "extend" part come back with Microsoft's old "embrace and extend" philosophy, and that only by way of the IE team getting actively involved with the open standards community and proposing innovative and acceptable additions and/or changes to HTML 5 and CSS 3, and then being the first to implement those extensions.

Some things I am still wishing browser vendors including Microsoft would innovate for are:

  • Open standards automation innovation. Not only do I want to see plug-ins like Silverlight having COM (or similar) automation so that one plug-in can talk to Javascript or to another plug-in using a native tongue (literally), but I wish there was an open standard way of going about deploying binary componentization, so that whether for the Mac or for Linux, and whether for Safari or for Opera, you could write one plug-in that worked well with both the browser's Javascript engine as well as with other plug-ins. The whole thing in the 90's with OpenDoc and ActiveX being the Next Big Thing for componentizing software really just sort of fizzled, even though COM objects did materialize and moved forward, but I'm looking for a good reason why this is still not a big area of support and interest between web browsers and standards committees. Then again, there's XPCOM, that plus COM might've sufficed but it looks like it's being discontinued so I'm confused, where's the native componentization love?
  • CLR scripting. We get this with Silverlight. But I want it in HTML. Microsoft, gimme!! The CLR is an open specification, just as Javascript is with ECMAScript. C# is an ECMA spec, as is the CLI (Common Language Infrastructure). Internet Explorer could make the CLR the replacement for ActiveX Scripting and it would automatically be "standards compliant" as long as the DOM is exposed with full W3C compliance, and JScript.NET is ECMAScript compliant. Meanwhile, the puzzle for COM marshaling with ActiveX controls was already resolved in .NET's v1 implementation with RCWs. So, no excuses on this; I'm sure that there is an engineering challenge in exposing the full W3C DOM, etc., to the CLR, but then again, is there really? I think the payoff is there. This could also be the answer to the previous suggestion, an open standard to plug-in automation, if something like XPCOM doesn't fit the bill. But once CLR is the "native tongue" of the browser runtime, Microsoft and the other browser vendors could easily throw in multiple CLR languages. Imagine Internet Explorer natively supporting: <script type="application/C#"> or <script type="application/IronRuby"> (or whatever it would be for IronRuby) or <script type="application/IronPython">. Heck, even <script type="application/javascript"> could run on JScript.NET. Couldn't it? I assume that JScript.NET is ECMAScript compliant, isn't it?
  • Window framing. We have windowing with window.open() but there's no window framing support, and by that I mean to support things like alpha channels and shapes on the window itself. One look at eBay's AIR-based Desktop application and I'm thinking, cool, a desktop app that looks and feels like a rich desktop application but under the covers it's an Internet app. But the thing about AIR is that it really is nothing but HTML, Javascript, and Flash, on a proprietary windowing framework, plus some OS integration bits for Windows' Start menu access and an Add/Remove Programs entry. Right? So I mean, why can't there be an HTML+Javascript specification that allows for the user experience that one enjoys in AIR, without having AIR installed?
  • Canvas. Oops, that's proposed in HTML 5. Yay!
  • Native menuing. Oops, that's proposed in HTML 5 as well. Yay! Microsoft, are you listening to this? ;)

Just a few ideas. It's fun to think forward now that the present frustrations are fading into the past.

kick it on DotNetKicks.com

Hello, Jaxer

by Jon Davis 26. January 2008 17:12

I think this new Jaxer thing just might become the next big new thing for open source web server architectures. It's AJAX all the way, even on the server. DOM on the server!

http://www.aptana.com/jaxer

The more I think about it, the more I can see it competing directly with the well-established open source web server technologies. Javascript is a viable language, and putting Mozilla on the server .. who'da thunk you could build complete client-server apps using only the one language? (Well I guess ASP Classic supported JScript on the server but .. *cough* .. besides, it didn't have HTML DOM running on the server.)

There is huge power in this when you can share APIs across both client and server without any manual proxy or wrapper coding, as this demonstrates:

http://ejohn.org/blog/server-side-javascript-with-jaxer/

I've tried hosting a COM instance of IE on the server in ASP.NET for similar uses but, needless to say, it's not a recommended strategy as it is not scalable on a high-traffic site (uses window handles, takes up a lot of RAM). It's like putting a motor home on a NASCAR race track. Then again, I don't know yet what Mozilla on the server will be like; I'm curious to find out.

I'd love to see something like this ported to ASP.NET.

kick it on DotNetKicks.com

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Extending XHTML Without A DTD

by Jon Davis 23. September 2007 23:33

Until Sprinkle I never did much with extending the HTML DOM with my own tags or attributes. When XML was introduced several years ago, people tried to "explain" it by just throwing in custom tags in their HTML and saying, "This is how the new semantic web is gonna look like, see?

<books><ol><book><li>My Book</li></book><book><li>My Other Book</li></book></ol></books>

Of course, that's not the greatest example, but at any rate, from this came XHTML which basically told everyone to formalize this whole XMLization of HTML markup so that custom tags can be declared using a strict DTD extention methodology. Great idea, only instead of picking the ball up and running with it for the sake of extensibility, people instead ran the other way and enforced strictness alone. So XHTML turned out to be a strictness protocol rather than an extensibility format.

Literally, even the latest, shiniest new web browsers, except for Opera (congratulations, Opera) have trouble dealing with inline XHTML extensions. At sprinklejs.com, the following at the top of the document causes a problem:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"[ <!ATTLIST div src CDATA #IMPLIED > <!ATTLIST div anticache CDATA #IMPLIED > <!ATTLIST div wraptag CDATA #IMPLIED > <!ATTLIST div apply CDATA #IMPLIED > <!ATTLIST input anticache CDATA #IMPLIED > <!ATTLIST input apply CDATA #IMPLIED >]>

The problem? Just go try and run that and you'll see what the problem is. The stupid web browser doesn't even speak XHTML. It sees those ATTLIST tags and thinks aww heck this must be malformatted HTML 4.01 markup, so it tries to "clean" it up in-memory by closing out the DOCTYPE before it reaches the "]>". So, when it does reach the "]>", it thinks, "Huh. Odd. What's that doing here? I haven't reached a <body> tag yet. That must be a markup error. I'll just go and 'clean' that up by moving it to the top of the body." So it gets rendered as text.

If you do a Javascript alert(document.body.innerHTML); you'll see that it became content rather than treated as an XHTML pre-parser definition. W3C validator thinks it's just hunky dory, but IE7 / FF2 / Safari 3 simply don't have a clue. (Morons.)

But heck. It handles the custom tags without the declaration just fine. These browsers don't balk at the Sprinkle script when the XHTML extensions aren't declared. And the breaking point is just extra content, right?

So I "fixed" this by simply clearing that ugly bit out. Here we go:

function dtdExtensionsCleanup() { // tested on MSIE 6 & 7, Safari 3, Firefox 2 if ((document.body.innerHTML.replace(/ /g, '').replace(/\n/g, "").substr(0, 5) == "]&gt;") ||  ( document.body.innerHTML.substr(0, 11) == "<!--ATTLIST" ||   document.body.innerHTML.substr(0, 11) == "<!--ELEMENT" )) {  var subStrStartIndex = document.body.innerHTML.indexOf("&gt;",    document.body.innerHTML.indexOf("]"));  var subStrHtml = document.body.innerHTML.substring(subStrStartIndex + 4);  document.body.innerHTML = subStrHtml; } else {  // Opera 9.23 "just works" }}

kick it on DotNetKicks.com

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , , ,

Web Development


 

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
 
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 


Tag cloud

Calendar

<<  May 2018  >>
MoTuWeThFrSaSu
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

View posts in large calendar