Monday, September 17, 2012

KendoUI AutoComplete and JSON for the RESTofus

Like Scott... I've oft had disdain for the web dev' experience.

Started programming in '67, and haven't missed a day since. ArpaNet was exciting, but Berner's-Lee ideas opened up a pandora's box to be land-Netscape-d, and we're still trimming the bushes.

So, I've not been all that anti-MS over the years, but they certainly have a habit of trying one's patience, don't they. The MS approach to the web is no exception: "do it this way. No, wait... that way is bad... try this."

"ActiveX, COM, DCOM, COM+, CLR, .NET, Web-sockets, not yet" it all starts to sound like a Billy Joel song. Isn't it funny how parts of 'Razor' markup resemble classic .asp? Kinda makes you long for the Scott McNealy vision all over again. Man, the transition from AWT to Swing seemed orderly by comparison.

So... way back in the dark ages of 2002 ASP.NET with ViewState seemed like a good idea. Yeah... that was the ticket. We can think like desktop-developers, not worry so much about state-preservation, and concentrate on the LOB app's biz-rules. Nice. Until ViewState became larger than the page, and every thing that a poor user did caused churn and grunts as latency destroyed patience and the number of postbacks caused epileptic fits.

So we used lots of server-side widgets (gotta love those grids) to help. Things got slightly better... but, there was no way that I could not shudder at the thought of the poor users sitting in the office, forced to enter data into a system that was 2-4x slower than it should be. And.. after trimming Session and ViewState, and using more JS to reduce round-trips, we still ended up with users hating the experience, going into epileptic shock from the latency blues. Remember the promise of 'SmartNavigation'? Never worked well, right?

So, we all started to take a hard look at AJAX. Loading data asynch'ly client-side... wicked pissah. Telerik had some fantastic examples and widgets embracing the paradigm. For me, the JS door cracked open a little more; getelementByID and InnerHTML became good friends.

And then John Resig did us all a huge deed. jQuery saved the day. All of a sudden, JS was almost a real language. And... we started to escape from the bondage of the mighty MS 'long and winding' road-map.

OK... I've been typing too long, and I really wanted to talk about my latest KendoUI experiments.

So, have YOU tried to get the KendoUI AutoComplete to do its thing for you? Do YOU have it working with a RESTful JSON remote datasource? Well... I must say, it was more than a bit of pain, and it wasn't exactly a 'restful' project dalliance. but... maan.. it rocks.

Feast your eyes on this and behold the beauty:

$("#patSearch").kendoAutoComplete({
minLength: 2,
placeholder: "(Initials, DOB, MRN)",
suggest: true,
animation: { open:
{ effects: "fadeIn",
duration: 300,
show: true
}
},
dataTextField: "LastName",
dataSource: this.patients,
template:
"<span class='patSearchRow'> ${data.LastName.trim()},${data.FirstName}-${data.DOBString}-&nbspMRN:${data.MRN}-${data.ID}</span>",
select: function (e) {
if (e.item !== null) {
var theitem = this.dataItem(e.item.index());
session.setPatientInContext(theitem);
}
}
})
autoComplete = $("#patSearch").data("kendoAutoComplete");
autoComplete.list.width(400);
autoComplete.list.addClass("patSearchRow")


I'm starting to like Kendo, and love it's harmony with (and the ubiquity of) jQuery. It's not just that KendoUI rocks... it's the attitude of the whole JS-library community. There's alot of great people putting tons of effort into JS. And soooo many cool things we can now do for our enslaved users.

It's not exactly easy yet... but we're getting there.

More later... the bees are a-callin'. Time to put more sugar-water on the hive; winter's coming.

Long live ECMAscript !

Wednesday, September 12, 2012

KendoUI's AutoComplete and JSON for the RESTofus

so.. yeah, like Scott... I've oft had disdain for the web dev' experience.

Having worked in just about every stateful environment there is over the years, it was both joyful and painful when ArpaNet was finally blessed and the web became something more than a Berners-Lee rolling paper.

Heck, even 68000asm had better support for real programmers when it was born.  So, back in... somewhere around the early daze of Win95.. when the suits realized that color monitors were good, CDs werent the devil and 3.5"diskettes were... we all had to look at how we too could play.

Active Server Pages bit like the .asp they were.   Javascript?  ok.. that was something that the Netscapers cooked up so we could finally validate some data that we had started to collect... we could now actually build a community by allowing peeps to sign-up themselves... actually typing in their own email to OUR webpage... and we could even store it in a database.  Whoopee.  Playing with Alert() and window.open was fun.  How much time can you spend preventing submarining?  oh the joy.

But... run... a REAL biz-app... in a browser?   Riiiiighhhht.   Point-of-presence sites were fine for me, but sh-t, maan... do you really want to trust your biz-data to an HTML app?   CFML was a godsend, and Jeremy Allaire my personal hero.  That helped a whole bunch.  <CFQUERY> was a big deal.

Roll it forward.

ASP.NET with ViewState seemed like a good idea.  Yeah... that was the ticket.   We can think like desktop-developers, not worry so much about state-preservation, and concentrate on the LOB app's biz-rules.  Nice.  Until ViewState became larger than the page, and every thing that a poor user did caused churn and grunts as latency destroyed patience.

So we used lots of server-side widgets (gotta love those grids) to help.  Things got slightly better... but, there was no way that I could not shudder at the thought of the poor users sitting in the office forced to enter data into a system that was 2-4x slower than it should be.  

Other projects forced a hard look at AJAX.  Loading data asynch'ly client-side... wicked pissah.  The JS door cracked open a little more; getelementByID became a good friend. InnerHTML was for me.

And then John Resig did us all a huge deed.  jQuery saved the day.  All of a sudden, JS was almost a real language.

OK... I've been rapping for hours it seems, and I really want to talk about KendoUI.  Here we go.   Have YOU tried to get the KendoUI AutoComplete to do its thing for you?   Do YOU have it working with a RESTful JSON remote datasource?   Well... I must say, it was more than a bit of pain, and it wasnt exactly a restful project dalliance.  but... maan.. it rocks.   Come to the MeetUp... and we'll show ya.

More later... the bees are callin.  Time for more sugar water.

Friday, August 17, 2012

Confessions of a Desktop developer….

I must confess.  I have not always been a fan of Web development.  I have been a developer for over 12 years and most of that time I have been developing Desktop applications.  I always found JavaScript to be more painful than useful. I’ve always been a big fan of WinForms/WPF and C# .NET. I viewed HTML and JavaScript as a limited technology, not suitable for building LOB (line of business) applications.

At my last company we developed a large WPF application that was rolled out to over  1,000 users.  This application had 14 real-time integration points and on average we had 500+ concurrent users worldwide.  WPF allowed us to make a really stylish UIs and I fell in love with Data Templates.

Just 4 months ago I received a phone call from a friend. He explained to me how his company was planning to rewrite one of their core strategic applications.  I thought “awesome!”  After all, what geeky developer doesn’t want the opportunity to “completely” rewrite an application from the ground up?  So, I changed jobs.

At the new job, step1 – choose a technology platform. My first thought was of Silverlight.  It runs on Windows and Mac (and we could say Linux too). For me, going from WPF to Silverlight was a no-brainer.  But, as we researched our customers’ needs and talked to them about technologies they are adapting we kept hearing the same story, “Silverlight is dead or dying, Microsoft is moving away from it”.  My heart sunk. HTML 5 and JavaScript, do I have to go there? L.

Now, I’m not going to argue the merits of Silverlight versus HTML 5.  You can find those arguments all over the web.  And I’m sure they will go on for years.  

With our need to support multiple platforms (Windows, MAC,  and Mobile devices and the current view of Silverlight’s future,  the decision was made to use HTML5, CSS, and JavaScript for the UI. Yes, my heart sunk.

Well what to do? Being a professional (I cried at home and did research at work) I started to look at what people had been doing with JavaScript and frameworks.  I was very surprised; I found a lot of good stuff.  JavaScript frameworks have come a long way and there are a lot of them.

It’s been 4 months now and I’ve learned a lot. In the coming weeks and months, I plan to post about my experiences good and bad.  I still like Silverlight but my perception of HTML and JavaScript is starting to change.  It’s not that subpar technology that I hated to work with years ago.  It will be interesting to see what happens to Silverlight in the future but for my current future it’s HTML, CSS and JavaScript.

Friday, August 10, 2012

Join us for our first MeetUp:

So many technologies, so little time

Choosing technologies and Tools


Are you thinking of migrating an application from the desktop to the web?  Are you wondering if you can reuse most of your existing code?  Are you not sure what technologies and vendor tools to use?  Well you’re not alone.  We are in the beginning stages of doing it ourselves. We have a goal to migrate one of our strategic applications from the desktop to the web over the next 2+ years and we want to share our highs and lows (and maybe some anxiety along the way) with you as we travel this journey.  Come join us in our technology Therapy sessions. 

Our first (therapy) session: “So many technologies, so little time”. 
  • HTML 5 (what happened to 4, 3, 2, and 1? ) 
  • AJAX (are we cleaning Windows?) 
  • Compass,CSS (be stylish, modern, have 3.) 
  • JavaScript/Coffee Script (I can’t start my day without coffee) 
  • Ruby on Rails, PHP/Python (I hate snakes) 
  • Java (isn’t that an island in the South Pacific?) 
  • .NET MVC (Most Valuable Customer?) 
  • Backbone.js, KnockoutJS (knock out? Are we boxing during this session?) 
  • ExtJS, YUI, Dojo, KendoUI (is this a martial arts demo?) 
  • JQuery, Node.js (I’m running out of things to say) 
  • JSON (are we missing an “a” in Jason name?) 
  • RESTful (I’m getting tired, can I rest now?) 
  • Mobile (I have an app for that) 
  • FLASH (Really? Aren’t we done flexing our Air Muscles?) 
  • And more

We can’t decide for you but we can share our thoughts on what we decided.

Join us on September 13 @ 6pm as we start our journey to migrate a desktop application to the web.  RSVP on MeetUp: http://www.meetup.com/Desktop-to-Web

Desktop to Web

Travel with us as we migrate one of our strategic business applications from Windows Desktop to the Web.  During this journey, we’ve decided to share our story as it happens.  Each week we will post our experiences (the good and the bad).  We will detail both the technologies we’ve chosen and why we chose them.   Our postings will likely range from what ORM we decide to use, to our struggles with JavaScript OO patterns. Additionally, like all technology groups, we will probably have some disagreements and we hope to be able to share them for your benefit.

We’re also looking forward to sharing our triumphs and challenges face-to-face.  Once each quarter we will schedule a get-together (with food and drinks J ) in the Boston area.  During these get-togethers, one of our developers will present on a topic of their choosing.  After the presentation, we will have a round table discussion to talk about the topic.  Our goal is to share our experience as well as draw on the experiences of other people.

This journey is scheduled to take us about 2 years.  In that time we hope to provide some useful learning experiences as we travel down this road.

Here are some of the presentations topics we plan to cover:
  • Determining what technologies and tools to use
  • Design patterns for the web 
  • RESTFUL services 
  • Security 
  • Hosting challenges
  • And more….