Creating animations using ExtJS and Ext.fx.Anim

CSS3 provides an ability for creating animations by gradually changing a style of an element. Any number of styles can be changed during a transition and there could be any number of transitions composing an animation. Animations in CC3 are created by specifying the “to” and “from” values or the @keyframe rule. With the @keyframe rule we define the steps starting from 0% and ending at 100 %. To be browser compatible, both 0% and 100% should be defined.

ExtJS has built-in classes to create animations using the CCS3 conventions. The two classes providing this functionality are Ext.fx.Anim and Ext.fx.Animator. Ext.fx.Anim accepts the “keyframes” configuration and passes the work to the Ext.fx.Animator . Following is an example of a simple animation using Ext.fx.Anim and  keyframes. The keyframe event generated at each transition will log a current step’s number. While this is might not be a real life example, a similar animation could potentially be used to alert users that a record is being edited by someone else at the same time and give them choices on the next course of action .

JSFiddle: http://jsfiddle.net/qPFf2/10/

var myComponent = Ext.create('Ext.panel.Panel',{

    renderTo: Ext.getBody(),

    width: 270,

    itemId: 'myPanel',  

    style: {

        width: '10px',

        height: '10px',

        'background-color': '#5687FF'

    },

    defaultType: 'textfield',

    items: [{

        fieldLabel: 'First Name'

    }, {

        fieldLabel: 'Last Name'

    }]

});

Ext.create('Ext.fx.Anim', {

    target: myComponent.getEl(),

    duration: 8000,

    keyframes : {

        '0%': {

            opacity: 0.6

        },

        '60%': {

            x: 120,

            y: 120,

            opacity: 1

        },

        '80%': {

        },

        '100%': {

            x: 0,

            y: 0,

            opacity: 0

        }

    },

    listeners: {

        keyframe: function(o, n) {

            console.log('transition:', n);

        }

    }

});

More information about  Ext.fx.Anim can be found at the Sencha's site.

Dapper and JSON:  performance and code simplicity.   You just may like this Micro-ORM.

If you are writing JavaScript apps that are data intensive you might want to take a look at Dapper.   Dapper is a super lightweight (single-file) object-mapper for .NET that’s been getting a lot of respect.  Per Wikipedia:  “Dapper was started by Sam Saffron because of the N+1 and other performance issues with Entity framework”

Wikipedia: http://en.wikipedia.org/wiki/Dapper_ORM  

GItHub:   https://github.com/SamSaffron/dapper-dot-net. 

stackoverflow: http://stackoverflow.com/tags/dapper/info

You can even now download Dapper via NuGet from VS2012.

I’ll tell you why my team is so excited about Dapper.  Many people have heard about Dapper’s performance.  Sam Saffron designed Dapper to be FAST.  It is fast.   However, that’s not the biggest win for us.  I’ll explain.

First, a quick note about the team and the project.  We’re a team of 5 working on a multi-year rewrite of a legacy healthcare app.  The app is data-intensive with a large schema, extremely detailed UI, and complex business rules.  We’re using ExtJS4.2, MVC4, MSSQL2012.   (Sidenote: we were using KendoUI, Knockout, MVC3 and have recently gotten religious about Sencha, the makers of ExtJS, Sencha Touch, etc.  But that’s another story, this blog is not about Sencha).

a)      Dapper has made communications with MSSQL much easier for us by making the always-fun ‘parameter boundary’ a bit easier to cross.   Take a look at these few lines of C# code in a data-layer:

Here, our server-side controller for processing an Product Master ‘Save’ receives one input ‘object’ parameter (passed to it as JSON by ExtJS code).  The stored-proc checks for potential save conflicts, and then returns another ‘object’ parameter from a single-row select executed by the stored-proc, in place of a ‘RETURN’ or ‘OUTPUT’ variable (in this particular optimistic-locking example, the biz-rule calls for returning the ‘current’ state of the row to the user if an intervening user manages to Update the same row before the ‘saving’ user commits their data.

  public JsonResult saveProduct(Product model)

{…

var  returnObj  = (IDictionary<string,object>)conn.Query("saveProduct", model, commandType: CommandType.StoredProcedure).First();

conn.Close();

return Json(returnObj  , JsonRequestBehavior.AllowGet);

…}

There’s a lot going on here.  Dapper is able to make complex AJAX-based Javascript<>SqlServer communications much easier for applications with .NET backend layers.

1)      The first parameter passed to conn.Query() is the stored procedure name, nothing special here.  However:

2)      Note that the second parameter passed to conn.Query is ‘model’.    Using this strongly-typed model (here a ‘Product’ model passed into the saveProduct method), Dapper auto-generates all parameters for the SQL stored-procedure call.  In this case, we’re saved 22 lines of ‘DynamicParameter’ declaration).

3)      Dapper also provides for ‘Multi’ (easy return of multiple result sets) and ‘Execute’ methods, but here, we use ‘Query’…  because our T-SQL Stored Procedure has been tasked with returning a result-set of ‘before’ values when it detects a multiuser collision.    When our SP detects a collision (using a table-resident DateTime column as a version stamp), it calls a JSON-generating UDF* to create a javascript object result-set that Dapper can easily cast back into a key-hash for easy server-side processing of a return-‘model’.

Here’s a fragment of the stored procedure that checks for collisions, and returns the ‘before’ state for processing client-side:

       IF @dtLastUpdated <> @tblDtLastUpdated  AND @tblDtLastUpdated IS NOT NULL

       BEGIN

              SET @lcSql='SELECT P.*,U.name AS userNameLastUpdated FROM Products P

            LEFT OUTER JOIN Users U on P.userlastUpdated=U.id where P.id =' +cast(@id as varchar(10))

              EXEC GetJSON @lcSql

              RETURN

       END

               

You can see that we did not have to declare a bunch of INPUT parameters to pass data to T-SQL from the C# layer.  Nor did we have declare a bunch of OUTPUT parameters to return a complex object back from SQL . 

Dapper is making things sooooooo much easier..

Namaste,

bob davis

*check back later for more info about JSON-generating UDFs.   I’m using one now created by an enterprising Bangalore tech.  I will be weighing in more on it and others as we continue to check it’s performance and accuracy , but so far, with the singleton-row result-set we need it for, performance is more than adequate.

We are finally off and running!

It’s been a while but we have finally started our project. J

What have we been doing for the last few months; you might ask?

Well; we initially worked on an interim web project. This really helped us get our feet wet with creating a Single Page (SP) Web application. If this is your first time developing an SP Web application, I highly recommend working on a small interim project before you start on your main project.  Even if you have a lot of Web development experience, I would recommend a small interim project.  Creating an SP Web application is far different than creating a Web site. Some people may say that you just need to build some prototypes to learn how to develop an SP Web application but I disagree.  Until you start hitting the big hurdles during development, you don’t really get the sense of what it takes to build an SP Web application. (I’ll talk more about the hurdles we encountered in future posts).

What is the one thing you really need to look at to build an SP Web Application?

You really need to look at a robust JavaScript framework.  We used Kendo UI (http://kendoui.com) for our interim project.  The product does provide a good amount of UI Widgets and their MVVM frameworks allow you to separate presentation from business logic.  But the widgets and the MVVM don’t seem to fit smoothly together. It seems like MVVM was an afterthought.

So we started to look at other frameworks (Angular.JS, Ext JS, Ember.js, and YUI).  We came to the decision to use Ext JS from Sencha (http://sencha.com).   Some of the key features that we liked about the framework are:

a.       MVC:

With version 4.0, Sencha has redesigned the framework to work with the MVC pattern from the ground up.  The UI Widgets and Controllers work seamlessly. 

b.      UI Widgets:

To list out their Components and features would take too long for this blog. I would strongly recommend looking at their example site: http:// http://docs.sencha.com/ext-js/4-2/#!/example .  If that is not enough to have you thinking about using Ext JS, I don’t know what else to say. J

c.       Documentation:

Out of all the frameworks I looked at, Ext JS has a robust documentation site (http://docs.sencha.com/ext-js/4-2/#!/api), with a large number of examples and guides to help you.

d.      Performance:

A lot of Ext JS 3.X users made a lot of noise about performance when Ext JS 4.0 first came out.  But with the release of 4.1.X and now 4.2 (We are working with version 4.2.), I think a lot of the performance hurdles are behind them.

e.      Build and Deploy tools (minify):

Ext JS uses a Loader class to automatically load the JS files as needed during development.  This allows you to separate your controllers, models, stores, views, and custom classes into separate files.  This is a huge benefit. Without this, you could end up with large JS files that are difficult to maintain.

(Note: there are open source libraries that allow you to do this too, but it’s nice that it is included in the Sencha framework.)

Having all those files is great for development but bad for production.  Luckily, Sencha has a tool (names: SenchaCmd) that can merge all the files and minify them for your production site. It fits well into our build process.

One thing to note about using Sencha, is that it is large.  There is a learning curve (especially if you have not used a JavaScript framework before). There are a ton of options and settings you can use for each component. I recommend looking at their training classes.   But before you go, I recommend working with the product first and getting some exposure to it.  That way you don’t feel overwhelmed with information during the week long training.

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 !

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.

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.

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