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

LINQ-to-Lucene

by Jon Davis 24. January 2008 15:57

I haven't tried this yet, but as a Lucene.NET user I find this to be quite compelling.

http://www.codeplex.com/linqtolucene

Be the first to rate this post

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

Tags: , ,

Software Development

LINQ-to-Javascript

by Jon Davis 24. January 2008 15:28

I jumped onto codeplex.com for a random summary of the latest projects and stumbled across LINQ-TO-Javascript (JSLINQ). Pretty nifty idea.

Personally I'd like to see JSLINQ to be a jQuery overload -- that is, take the JSLINQ object definition and merge it with jQuery's object (at runtime) -- so that jQuery extensions can automagically work with JSLINQ objects. I suggested the idea here.

Currently rated 5.0 by 1 people

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

Tags: , , ,

Open Source | Cool Tools | Web Development

XML Encoding Text Really, Really Easily

by Jon Davis 18. January 2008 00:31

Frequently I need to pass some text along in an XML document that may have special characters like less-than (<), greater-than (>), or the really annoying nuisance, ampersand (&). Most people fix this lazily by using CDATA nodes. But I hate CDATA nodes with a passion!! I've been using a trick I've used for years and I dunno why I never blogged it. You don't need to use CDATA, nor do you need to manually perform a scan and replace for these special characters. Microsoft already did the dirty work for you in XmlDocument by setting a node's InnerText value and getting the InnerXml value back.

So when I'm generating an XML file, such as with using a StringBuilder or using repeaters on an .aspx template, this is what I sneak into the code-behind:


    private static System.Xml.XmlDocument _staticDoc = null;
    public static string XmlEncode(string str)
    {
        if (str == null) return "";
        if (_staticDoc == null)
        {
            _staticDoc = new System.Xml.XmlDocument();
            _staticDoc.LoadXml("<text></text>");
        }
        lock (_staticDoc)
        {
            _staticDoc.LastChild.InnerText = str;
            return _staticDoc.LastChild.InnerXml;
        }
    }

Then I can just use: 

<%# XmlEncode("Ed & Bob")%>

.. where "Ed & Bob" actually comes from a data object. :) This in turn outputs "Ed &amp; Bob".

There's also XmlTextWriter, which I haven't tried yet.

UPDATE: Alright, now I've tried XmlTextWriter. I had a need for ASCII enforcement of XML encoding so that weird Unicode characters are converted to their "&#??;" entity replacements. The method isn't so simple anymore but first tests seem to pass. I'll update this again if I find it to be flawed. Note that I'm putting this among other things into a shared XmlUtil class full of handy static methods. But this update in particular is important because XmlDocument.Load() was failing to load because of some Unicode characters that could be best described in XML entities.

namespace XmlUtil {

private static XmlDocument _staticDoc = null;
private static StringWriter _staticStringWriter = null;
private static XmlWriter _staticXmlWriter = null;
 
/// <summary>Converts Unicode text into ASCII-compliant XML encoded text</summary>
public static string EncodeText(string str)
{
    if (str == null) return "";
    if (_staticDoc == null)
    {
        _staticDoc = new System.Xml.XmlDocument();
        _staticDoc.LoadXml("<text></text>");
        _staticStringWriter = new StringWriter();
        XmlWriterSettings settings = new XmlWriterSettings();
        settings.ConformanceLevel = ConformanceLevel.Fragment;
        _staticXmlWriter = XmlTextWriter.Create(_staticStringWriter, settings);
    }
    lock (_staticDoc)
    {
        _staticDoc.LastChild.InnerText = str;
        str = _staticDoc.LastChild.InnerXml;
    }
 
    // ASCII enforcement
    StringBuilder sb = new StringBuilder();
    char[] chars = str.ToCharArray();
    for (int i = 0; i < chars.Length; i++)
    {
        char c = chars[i];
        if ((int)c > 127) // goes beyond ASCII charset
        {
            lock (_staticStringWriter)
            {
                lock (_staticXmlWriter)
                {
                    _staticXmlWriter.WriteCharEntity(c);
                    _staticXmlWriter.Flush();
                    StringBuilder _sb = _staticStringWriter.GetStringBuilder();
                    sb.Append(_sb.ToString());
                    _sb.Length = 0;
                }
            }

        }
        else sb.Append(c);
    }
    return sb.ToString();
}

}

Currently rated 5.0 by 1 people

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

Tags: ,

Software Development | Web Development

If An Air Guitarist Picked Up A Real Guitar

by Jon Davis 13. January 2008 19:54

Someone replaced the audio of some great rock concerts with some .. um... really bad playing, with no musical ability whatsoever.

I laughed so hard on this one I started crying.

http://www.youtube.com/profile_videos?user=StSanders&p=v

I love them all but the first one I saw was the Jake E. Lee one .... clap - clap - clap - clap .. yeahhh!! .. clap - clap - clap .... Oh man I was hurting in laugher..

Be the first to rate this post

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

Tags: , , ,

Music Production

Silverlight vs. ActiveX: Give me automation or give me death!

by Jon Davis 8. January 2008 18:49

In the wonderful IE4 days when ActiveX was the big new thing, you could create an ActiveX control -- that is, a first class COM object - in full Visual Basic. In fact, Microsoft released a free version of Visual Basic just for creating ActiveX controls. It was ridiculously easy to create COM objects in this way.

Then you could instantiate the object in the browser scripting engine and do things like:

<script>
myActiveXObject.HtmlDocument = document;go
</script>

With that one line of code, (popping knuckles) the full-blown Visual Basic programming environment had access to the Internet Explorer web browser document object. There was no wrapper, just a COM interface!!

Visual Basic:

Call Me.HtmlDocument.window.eval("alert(""Hello from full-blown Visual Basic via the browser's Javascript scripting engine"");")

Me.HtmlDocument.body.innerHTML = "<h3>Muahahaha!</h3>" & Me.HtmlDocument.body.innerHTML
Me.HtmlDocument.body.style.backgroundColor = "#00000"
Me.HtmlDocument.body.style.color = "#ffffff"

Call Me.PlayVideo()

' etc.

Likewise, the COM interfaces of the ActiveX control were directly and effortlessly exposed to the browser Javascript runtime.

<script>
myActiveXObject.PlayVideo();
</script>

This opened all kinds of doors of opportunity. Event sinks and controllers could be dropped in every which way. Flexibility of writing code was virtually limitless.

This WAS doable before Microsoft abandoned Visual COM (Visual Basic 4/5/6). The ActiveX Script runtime engine was a marvelous invention. I'll admit that it's proprietary to Internet Explorer, though, but Mozilla has traditionally supported COM in some fashion. I don't know how Mozilla's plug-in and scripting runtime integrations work.

Fast forward to today. Rich client applications are now written in Javascript and AJAX, making use of only one specialized COM object (or other automation object, depending on the browser) now known today as XMLHttpRequest. Rich client apps also make heavy use of objects-based programming.

In order to create user experiences that are outside of the capabilities of Dynamic HTML, plug-ins are still used. This is where plug-ins like Silverlight come in. But those plug-ins, especially when they have broad and powerful runtimes like Flash (ActionScript) or Silverlight (CLR), need to be able to be interopable with the browser's script runtime in order for utilization to be fully realized. In the Internet Explorer world, the answer to this was simply IUnknown / COM / ActiveX.

Browser Javascript objects and logic need to be able to interact with plug-in runtime objects and logic and vice-versa.

ActiveX componentization is now virtually deprecated. Microsoft no longer sells nor supports Visual COM (Visual Basic 4/5/6, which was the only tool Microsoft ever created to allow users to be able to effortlessly create COM objects). ActiveX controls are also a security concern, and in Internet Explorer 7, users are discouraged from installing them.

But what I'm looking for is unwrapped interop support between the Silverlight CLR and the browser's runtime. Silverlight doesn’t have access to the Javascript DOM. It has access to a limited set of objects and properties of the HTML DOM using a wrapper API.

http://silverlight.net/QuickStarts/Dom/DomAccess.aspx

The CLR in Silverlight introduces a secure but powerful runtime engine to the web environment and an extent of sophistication that previously never existed, not even with old Visual COM (Visual Basic 4/5/6). Now that Silverlight 2.0 is coming out soon with a rich programmatic runtime like Visual COM (VB) used to have, I’d like rich COM automation back. The value is more fully realized when you can pass browser Javascript objects to the CLR or pass CLR-declared objects to the browser Javascript runtime.

(I'll post better examples of what used to work versus what doesn't work later this week. But yes, full COM interop was possible between VB and ActiveX Scripting, and yes you could pass objects back and forth. It even supported dynamically generated COM interfaces. For example, you could declare and instantiate a class in VBScript in the browser, pass the instance to a method on an ActiveX control written in VB where the VB OCX property expects a Variant, and then VB OCX could call upon the functions within that class.)

Obviously, what this means is that Safari, Mozilla, and Microsoft would have to agree on an interop strategy. I thought they had already accomplished this, but it'd be surprising to me if they didn't. It would, however, further cement my frustrations with Microsoft that they allowed too many years to go by without staying involved with the browser standards communities like W3C and ECMA to work those issues out.

ActiveX componentization is not deprecated because COM is a security concern. It is deprecated because the technologies that implemented ActiveX were not sandboxed like Java applets, Flash, and Silverlight are. The Silverlight CLR is neatly sandboxed--this means that there are no longer serious security concerns that developers otherwise had with the ActiveX plug-in support--so if security is a concern, it shouldn't be.

But, practically speaking, browser Javascript objects and logic need to be able to interact with plug-in runtime objects and logic and vice-versa. Put as succinctly as I can, if I cannot declare a function in the browser script with parameters, and call on it from the CLR while passing CLR objects, I feel stuck with preferring old ActiveX over the Silverlight CLR for dynamicizing HTML. The same is true going the other way. The way things are right now, it's an all-or-nothing deal--either you completely rewrite the AJAX web application so that it no longer users the browser Javascript and uses the Silverlight CLR, or you don't use the Silverlight CLR and stick with the browser Javascript. These two options are completely unrealistic, from a business perspective.

Microsoft's position on this matter has so far been that they think the "wish is valid, but it is challenging since we are dealing with a scripting world, a native world and a managed world all in one wish."

I'm sure it is challenging. But this and true DHTML are precisely why I thought Internet Explorer v4 was the greatest invention that came out of Redmond after the Windows NT kernel. It's why Internet Explorer had been Microsoft's preferred generic COM host for SDKs and development for many years.

I don't care if it is challenging. It was Microsoft who invented COM. It was Microsoft who implemented the ActiveX Scripting engine. It was Microsoft who invented the fully programmable browser DOM. It was Microsoft who invented .NET and the Visual Basic and C# languages. I have no doubt that the most profitable corporation on the planet can figure something out in this matter.

But this is an issue I have that goes beyond Silverlight, it is about Microsoft's leadership role in the Internet client software industry. It's like they fired their automation visionaries as soon as IE4 went gold.

Perhaps that isn't fair; the CLR is certainly quite visionary. It's just that the current state of things shows abandonment of the industry necessity to keep striving to bridge the gap between the browser script runtime and the plug-in runtime; this is a problem that has been around for over a decade, and that the industry leaders aren't still pushing for a cross-browser automation solution really befuddles me.

There is one "trick" that I can think of, though, to make window.eval() happen from Silverlight that may or may not work efficiently. Perhaps you can get Silverlight to change the text value of a hidden HTML element. This HTML element is strictly used for window.eval(). Javascript would need to be notified that the value changed. A setInterval loop? An onchange event hook? Dunno. But once it sees it it can fire it off and then populate some other hidden element for the eval result. I'd prototype this but I don't think onchange will work and a setInterval loop frightens me, not to mention only being able to use text (or XML) for params and return values. The whole idea seems terribly kludgy... Yuck.

kick it on DotNetKicks.com

Currently rated 3.8 by 6 people

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

Tags: , , , , ,

Software Development | Microsoft Windows | Web Development

Yes, I Game

by Jon Davis 6. January 2008 18:10

I still find it irritating when non-gamers look down on me as someone who needs to "grow up" when I admit I still play PC and Xbox 360 games. But I keep having to tell them, "Games aren't for kids. I'm 30 years old; I'm still roughly the average gamer age."

These statistics are pretty telling:

  • The average game player is 33 years old and has been playing games for 12 years.
  • The average game buyer is 40 years old.
  • 38% percent of all game players are women. In fact, women over the age of 18 represent a significantly greater portion of the game-playing population (30%) than boys age 17 or younger (23%).
  • In 2005, 25% of Americans over the age of 50 played video games, an increase from nine percent in 1999.
  • 44% percent of game players say they play games online one or more hours per week. In addition, 32% of heads of households play games on a wireless device, such as a cell phone or PDA, up from 20% in 2002.

I can't speak for everyone, but I believe that one of the big reasons why my interest in games never waned is because, frankly, it was my generation that saw the industry develop and blossom in the first place. When I was a little kid, Pac-Man was it. And even my sisters played that; I still have memories of looking over the shoulder -- er, around the waist, rather -- of my oldest sister playing Ms. Pac Man when I was, like, six years old when we visited the skating rink. And as my blog sidebar points out (as of this entry), it was in playing computer games that I knew that I wanted to be a programmer when I grow up, although I knew even at the age of twelve that it wouldn't be games I would program, it would be stuff that makes the economic world turn.

Generation Y (twenty-somethings) and kids these days grew up with the dazzling 3D games my generation could only slobber over. For us, a lot of the fluff is still very new to us. The original Unreal and Tribes and Quake 3 still seem new, so the new stuff like Lord of the Rings Online and Crysis are more jaw-dropping amazing. But for kids, it's mostly boring old school crap; they're a lot more picky and they find the MMORPGs called "Real Life" and "MySpace" just about as fascinating.

I spend more than ten hours a week playing games. But I'm not sure if that's hard core. I still can't say what game I'm playing on any given day; I play games either for curiosity of new things (like Call of Duty 4) or for nostolgia (like Team Fortress 2). On the other hand, I did finish Mass Effect not long ago in a pretty short amount of time, what a treat!


 

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