Upgrading an ExtJS application from 4.1.2 to 6.x - javascript

I'm acquiring an existing application written in ExtJS 4.1.2. It's a very large code base. The 4.1.2 application was built without CMD -- the sources are added directly to index.html.
Without having much of an ExtJS background, I have the following two questions:
1) Does it make sense to upgrade to 5.x first and then go from 5.x to 6.x? Or is it safe to go directly from 4.1.2 to 6.x?
2) Should a new project be created and manually copied over, or can I just update the sources, in theory, to point to the new extjs lib, and back peddle fixing all client code that's broken or no longer compatible?
I haven't followed the history of ExtJS much, so I'm not sure if upgrading two major revisions is even feasible with this framework.
What's the best approach if CMD isn't being used in the existing app?

I am using Ext.js in production, and we are currently doing a similar upgrade. We are on 4.1.1. Here is what we have done.
1) Does it make sense to upgrade to 5.x first and then go from 5.x to 6.x? Or is it safe to go directly from 4.1.2 to 6.x?
We chose to upgrade to 5.x then 6.x. The reasoning behind this is because 6.x was not considered stable(at the time), and we would have less bugs to deal with. The biggest jump is going to be moving from 4.1.2 to 5.x. Moving to 6 from 5 is easy. 5.x included new features and changes to the API. 6.x is mostly behind the scenes technical debt that merged sencha touch and desktop, which is signficant because now you can have one app for mobile and desktop. You could probably move directly to 6 since it is much more stable than when it was in beta.
2) Should a new project be created and manually copied over, or can I just update the sources, in theory, to point to the new extjs lib, and back peddle fixing all client code that's broken or no longer compatible?
We chose to go with the second one. We replaced the entire extjs lib, and tested all client code then fixed it. It has gone pretty smoothly. We did have the benefit of using sencha architect. Sencha architect keeps the javascript code is json meta data files. When you want to upgrade, it can do automated checks. We also had a lot of code outside of of architect projects that is similar to what you have, and there have only been a couple problems. It was a 50-50 split.
One way to assess the feasibility of the upgrade is how closely intertwined the code is with Ext.Js. We had a developer write a mini-framework that extended core Ext classes and overrode a lot of the core methods for stores and views. It also had a convoluted plugin framework that touched the Ext.Js internals. Overriding those methods made the code very fragile during the upgrade. Probably 60% of our effort went into fixing that framework. There were other pages that was closely intertwined with Ext.Js that took a lot of effort to migrate as well. Code that was much simpler, for example it just created a widget with some listeners, did not need many changes.
As I understand it, Sencha CMD is the official packager, minifier, and dependency manager for the framework. When you upgrade with Sencha CMD, it just replaces the main library, and it doesn't do much for fixing the actual javascript. Sencha architect is where you get a lot of bang for the buck in terms of time saving.

Related

How to go about implementing a webkit based windows application?

This is a bit of an open-ended question, since I am just starting out on the project.
Problem: I have clients who cannot install web-browsers on their machines, and are stuck with IE6. The app we are selling them is a web-based app using a lot of javascript and jquery.
Solution: Implement a windows application that has a web-browser control based on webkit (since the regular webbrowser control is not going to support javascript and jquery), which loads the app.
I started doing research, and I found 2 controls:
https://code.google.com/p/open-webkit-sharp/
and
http://webkitdotnet.sourceforge.net/
I started off with the second one, and tried the sample app they built, only to discover that the version of webkit they used is really old and doesn't run our app right.
So my current solution is to compile webkit myself and include the newer version in the control and see how that works out.
Since this is a time-sensitive issue I thought I'd also ask for the experience of StackOverflow at the same time I am going down my route, to see if there is a simpler solution, or if there are any libraries or pre-built controls I could use that I missed in my search?
Thank you for any help!

jQuery in Windows 8 JS Applications

Can we use frameworks like jQuery and jQuery UI in Windows 8 JS Applications? I can't find a document where I can read something about other frameworks.
Thanks.
Yes, you can. The only thing needed is to add the required JavaScript files in your application in Visual Studio and include them from there. Using any CDN won't work as you can't load external JavaScript files in a Metro JavaScript application.
There is some fix in jQuery library that you can include it in your Windows 8 development.
Here is the link to get the jQuery library (with some fix to tailor for Wins 8).
https://github.com/appendto/jquery-win8
The work is done by AppendTo and they had a joint talk with Microsoft at BUILD conference this year.
More detail for this jQuery library:
jQuery for Windows 8
With the recent release of Windows 8 many developers have eagerly set out to create jQuery-enhanced applications for Windows 8. Unfortunately, all of these individuals quickly learned that jQuery and Windows 8 initially suffer a bit of friction when brought together.
Faced with this issue, appendTo is pleased to release a custom copy of jQuery that will play nicely in Windows 8. Just download it, include it in your project, and you'll be up and running.
To ensure the project's direction was carefully planned, appendTo communicated with the jQuery team routinely to address any concerns about modifying some aspects of jQuery (or its Unit Tests) to improve compatability with Windows 8.
Given that this is a preview and you may come across issues in your own projects, we would like to encourage you to freely submit issues and feedback here on GitHub. We will do our best to answer your concerns in a timely manner, and resolve issues as quickly as possible.
Please note that in order to get the best experience with jQuery and Windows 8 you'll need more than a modified library, you will also need an understanding of basic security concerns in the Windows 8 environment. Many of these concerns are with how you, the developer, use $.html() (and other similar methods). Please see http://msdn.microsoft.com/en-us/library/ie/hh465388.aspx for further details.
Watch the presentation given at Build 2012 online at http://channel9.msdn.com/Events/Build/2012/3-130

Which Anti-XSS library should I use? Microsoft XSS 4.0, Web Protection Library on Codeplex, or other?

Seems like Microsoft updated the Anti XSS library today:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f4cd231b-7e06-445b-bec7-343e5884e651
In addition there is a new release of the Web Protection Library
http://wpl.codeplex.com/
Are these two downloads the same thing? What XSS library should I be using?
Are there others I should consider?
Well, as the WPL owner these days I know it's a little confusing, so
The WPL contains two projects, AntiXSS and the Security Runtime Engine. Previous versions installed both, but really they're quite separate and the SRE is an ongoing project which is getting a major rewrite, so rather than hold up the latest changes to AntiXSS whilst I pottered around some more with the SRE we made the decision to split them out, and ship separately.
So right now AntiXSS 4.0 on msdownloads is the most up to date encoding library.
As part of the source push the latest source for the SRE will be pushed as well - however the SRE is still a work in progress, and will remain so for some time, so it'll be source only for a while.
We're still trying to figure out how best to address this in terms of codeplex projects :)
It is the same thing. WPL includes AntiXSS and Security Runtime Engine.
I'm using Microsoft AntiXSS library with my MVC2 application. It integrates nicely and requires no code changes in the views.

Dojo vs YUI javascript framework

I want to know what you guys think of these 2 frameworks, in terms of:
robustness,
code quality,
core developers moving forward with new features,
cross browser problems,
module components,
easiest to learn and integrate
I already know and use jQuery, I recently found it lacking in terms of 'enterprise ready' components for large web app.
Now I don't want to start a debate on jquery, or why mootools is not in there, I want to know what you guys think of these 2 frameworks specifically.
Thanks!
Disclaimer: I am a Dojo committer.
Somehow nobody presented the Dojo side in this comparison — it is not a comparison without one, is it? Let me go over your points.
Robustness
Dojo is used in many IT projects by major international corporations. I personally participated in projects for VMware, IBM, Cisco, Reuters Thomson to name a few. Instead of forwarding you to the "marketing literature" I can show you the actual list of contributors: http://docs.dojocampus.org/developer/contributors — scroll down to see corporations that contribute (and use) Dojo.
We keep the list of individual and corporate contributors so our users can be sure that the IP lineage of Dojo code is clean — every contributor signs a CLA stating that he/she/it wrote the contributed code and/or has a right to contribute it under dual AFL/BSD license. So far we didn't have any problems with that.
As far as I can tell YUI is mostly developed by one company: Yahoo! YUI started to accept external contributions only two years ago being in development since 2005 and now requires CLA too.
I am not a stock market expert but something is always up with Yahoo!: one day it tries to forge an alliance with Google, next day it kills its search business and goes with Microsoft, even selling the whole company to Microsoft was discussed back in 2008 — who can predict what it will do tomorrow. Now in 2010, the share price went down since 2008 — is it going to be on sale again? OTOH some say that Microsoft would be a better mother for YUI, if it decides to keep it. Then again, Microsoft has its own software properties and not exactly a backer of open source JavaScript projects.
Unlike YUI Dojo is backed by several companies with IBM being the most influential one — several prominent committers were hired by this company. While Dojo has a strong corporate support, it is still a project driven by its community, by individuals. If any company or even several companies will experience market hiccups we will still plow ahead.
Dojo is distributed under dual AFL/BSD license and free for all uses. All officially released versions of Dojo are served by AOL and Google CDNs.
Code quality
I am biased :-) and I consider the code to be of a very good quality. As Dojo is an open source project you can always judge it for yourself, and improve it, if you feel up to it.
The source code is kept in Subversion with official mirrors maintained on Github (git), and Bitbucket (hg). For convenience there is a mirror on Launchpad (bzr).
Core developers moving forward with new features
Dojo has an active vibrant community, which keeps the wheel moving so to speak. Being one of the core developers I assure you personally that we will continue to move forward pushing the proverbial envelop even further.
Dojo has a proven track record of innovations, and we are not going to stop.
Cross browser problems
Currently Dojo 1.4 supports following browsers:
Firefox 2 support dropped. Firefox V3 and V3.5 supported.
Latest Safari (Safari v4) and latest Chrome (Chrome v3) supported, but not previous versions.
IE6, IE7, IE8 all supported.
Latest Opera (Opera v10) (Dojo core only).
The upcoming Dojo 1.5 (will be released in a few days) was extensively tested with following browsers:
Firefox 3.5/3.6
Safari 4/Safari 5 and Chrome 5
IE6, IE7, IE8
Opera 10.53 and later (Dojo core only)
To highlight the differences with YUI's A-grade browsers:
Dojo supports Linux in addition to Windows and Mac.
Dojo supports Google Chrome on all supported OSes.
Dojo supports Firefox on all supported OSes.
Dojo Core supports Opera on all supported OSes.
Personally I can add that I still test dojox.gfx (the cross-platform graphics package) on Firefox 2 — it involves Dojo Core and it works as expected. And I test Dojo Core on several exotic browsers like Midori.
Another difference is that Dojo can be used (and it is used) in desktop and server environments. Obviously browser-specific components are not used by those environments.
Module components
From day one Dojo provided classes, modules, and packages (collections of modules). Dijit provides widgets: packaged HTML + JavaScript with unified interface.
All building blocks are exposed to users, so they can create their own components, which will be 1st class citizens: they can be loaded like any other modules, processed by the builder (dependencies tracked, minified, CSS preprocessed, and so on), even exotic CDN builds can be done by users. Anything you can do with stock Dojo components you can do with your own components.
Dojo itself is split into 3 subprojects, which can be used separately:
Dojo (including Dojo Base as a single file)
Dijit: a collection of widgets
DojoX: even more widgets, and ~50 packages covering everything from cross-platform charting to encryption.
Easiest to learn and integrate
Dojo is just JavaScript and regular HTML/DOM (for widgets). It does not pretend to be something else, it is not a cult with a fuhrer at helm, it is not a "framework", which takes control of your app and forces you to do some bizarre things, Dojo doesn't want to "improve" "imperfect" JavaScript, Dojo doesn't want to masquerade a browser to be something else. Instead Dojo provides practical tools to make a programmer more productive, to facilitate RAD, to solve common problems, and to support useful techniques and methodologies.
Every experienced programmer usually has a mini-library of things that worked well for him/her in previous projects. He or she knows what to avoid and what to use. It "clicked" in my head when I realized that Dojo is this library on steroids — like several experts got together and carefully combined their personal libraries. Sure, it has a lot of different modules, but I can use only what I want for my specific project — I am not forced to use everything, and I don't pay for things I don't use. Not even an abstraction penalty.
If you know JavaScript and familiar with HTML, CSS, and DOM — you'll be right at home.
I think your reason for rejecting jquery sounds suspicious, and recommending a framework as "enterprise ready" is a backhanded compliment in my book.
However, I have a lot of experience with YUI (2 and 3) and I think it might fit your use-case.
Robust - YUI is used internally by Yahoo, so that should give some clues as to its robustness.
Code Quality - I'm a contributor to the project, and the code quality is very good. As it is open source you can take a look for yourself.
Moving Forward - It is backed by Yahoo (but also incorporates community contributions) so moving forward it is pretty safe. Again, you can track development and community involvement yourself.
Cross Browser - it supports all the Yahoo A-grade browsers
Modules - there are a ton, and (especially in YUI 3) it is easy to incorporate just the pieces you need. If you want mostly GUI modules, you'll still need to mix in some YUI 2 (which is easy to do). Widgets in YUI3 are coming soon, though.
Easy to learn and integrate - YUI has probably the best documentation of any JS library I've seen. However, YUI 3 is very opinionated about how you write your javascript. It is opinionated in a good way and gives you a lot of bang for your buck, but to just "drop in" to an existing project YUI 2 may be easier.
YUI has a great testing toolkit and doesn't pollute the global namespace. Also, YUI test results can be read by JUnit, which is a plus in my book. I haven't used Dojo so I can't comment on it in detail, but the way it integrates with the DOM is worthy of notation.
Knowing that JQuery is the easiest to use and immense popular, Dojo has its advantage of being integrated in Zend Framework. Also, the difference in being a library or framework counts.
- A library is about reusable functionalities, but a framework is about reusable behaviours
- A library is something you call/inherit from your code, but framework is something that calls your code or provide services for your code
- A library is a collection of components and classes, where framework is how abstract classes and components interact with each others.

What steps do you take with VS 2008 to reduce development time with Javascript?

I am seeking your stories on how you have streamlined your client side development with Visual Studio. In particular, it seems that I need to build my site too often in order for changes to pushed down to IE effectively. What shortcuts or tools like FireBug, etc. do you use for your client side development? Do you avoid Visual Studio for debugging your client side apps all together?
We are developing the application which is building almost everything on javascript side, all the controls, webservice call (thru Ajax enabled javascript), grids and all kind of stuff.
We have created framework which includes ExtJs, and JQuery. It makes life easy to initialize and define all the controls in jQuery and make get data using webservice. We can use only ExtJs, however Jquery reduce the number of lines we need to define and set the controls. And of course its very light weight as javascript files are like <25-20 kb which needs to use this frameworks.
I've used the steps outlined by ScottGu here to get a better JS intellisense for VS 2008.
(As it is pointed out here, this patch is intended for all JavaScript files, not just jQuery.)
I use the vsdoc files to get intellisense working for jQuery.
lately, I had to work in a VS2005 + IE6 only environment. I've quickly got used to having Firefox for debugging with the tools I subjectively deemed essential: Firebug, PageSpeed, FireQuery.
I tried Aptana. (As of yet however, I didn't invest much time in getting to know it - you may find it familiar if you are equipped with some Eclipse knowledge, though...)
After all is well and done, I check pages in IE and use the built-in profiler in IE8 if there is some IE specific perf issue.
I use the "empty vsdoc" workaround when VS intellisense gives up.
At home, I use VS 2010 RC - and at all places I keep the API references of JS frameworks bookmarked and within reach, just in case.
Place Javascript code in separate JS files.
You might want to consider turning your related sets of functionality into a ScriptControl.
When you work on some JS file and want to avoid the time of rebuilding the whole project, do not make it an embedded scriptresource from the start. Package it in the assembly when it is stable enough.
If you are in doubt whether you get the latest version of your JS file, disable the browser cache. (It can be done from FireBug, or in the IE dev tools.)
Disclaimer: this list is really subjective and probably not complete at all.

Categories

Resources