Sencha Touch Vs Backbone.js [closed] - javascript

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are the basic difference Sencha Touch and Backbone.js, actually have built a project in backbone.js but not aware of Sencha Touch. I have to built a PhoneGap application which one is better for that?

Sencha Touch (our product) is intended to be an all-in-one application framework that provides all the functionality you need to create great looking apps. Everything is designed to work all together on all the major mobile browsers. It's a cleanly architected object-oriented approach to developing apps.
As an "all-in-one" framework, it gives you a full set of resolution-independent UI widgets (carousels, lists, tabs, toolbars, etc. etc.) an MVC library, event management, utility libraries, animation, a theming system, object lifecycle management, a layout system, a drawing and charting library and more stuff than you can shake a stick at... Because it's all designed to work together, the initial learning is higher, but once you're there people swear it's light-years more productive than anything else.
vs.
Backbone.js, which is a simple MVC library. It's about 1,000 lines of code and gives you 5 classes:
Model
View
Router
Collection
Events
It has a dependency on underscore.js for utility functions, so you'll need that too. You will also probably need to use a separate templating library as well as a DOM abstraction/manipulation library like jQuery or jQuery Mobile which also has some UI widgets and a bunch of other libraries to build a full app. But some people prefer to research and hand-curate their individual libraries.
Update: I wanted to add more detail to repond to Ben Bishop's answer below. Aaron Conran, who's our Sencha Architect lead and a Sencha lifer has helped me out with this addition.
There is a definite world view difference between Sencha and backbone. In general, Sencha tends to stay in the JS world and we expect that your JS will generate your HTML content. Backbone on the other hand is kind of a mishmash between an HTML and JS. There's no cut and dry reason to using one or the other, although we believe that data-driven apps of any complexity are better served by the Sencha approach. Ok on to details.
First off re: Classes, Ben's example of declaring a class in JS would put a copy of every property and method in every instance of the object. Typically working in raw JavaScript, you want to put these on the prototype so that they are shared across instances of the class MyClass. The Sencha class system does this automatically for you.
Additionally in raw JavaScript, users have to grok prototypical inheritance correctly in order to properly inherit from or mix in a particular class. Sencha takes care fo thsi without you having to worry.
As far as "magic strings" go (although I'd argue that's a rather negative characterization) you don't have to use them if you don't like them in 4.x , instead you can use Ext.extend with direct identifiers (although this is officially deprecated since 4.0.0 http://docs.sencha.com/touch/2-1/#!/api/Ext-method-extend).
Using magic strings is useful in a few ways.
First off we can worry less about dependency order and when any class is defined/extended from. This matters in complex apps
For example
Ext.define('Turtle', { extend: 'Animal' });
Ext.define('Animal', { });
Works because Sencha waits until the Animal class is defined before defining the Turtle class.
In contrast:
Turtle = Ext.extend(Animal, {
});
Animal = Ext.extend({}, {
});
Does'nt work because we can't find the variable reference Animal.
Second, using strings means we can support dynamic loading. For example if we have
Ext.define('MyApp.foo.MyClass', {
extend: 'MyApp.foo.ParentClass'
});
If you follow a strict class name to JS folder convention, the class loader knows where to load the class namely:
MyApp.foo.MyClass lives in app/foo/MyClass.js
MyApp.foo.ParentClass lives in app/foo/ParentClass.js
This technique makes it easy for Sencha to do useful things:
- The class manager will automatically create proper objects without you having to create & manage namespaces
- Determine the classname of any class or instance
Ext.ClassManager.getName(myInstance) -> "MyApp.foo.MyClass"
Perform some action when a particular class is defined
Ext.ClassManager.onCreated(function() {
}, scope, 'MyApp.foo.MyClass');
Support namespace rewriting, for example if you need to run two versions of the same set of classes concurrently in the same page... you can rewrite the namespace of Sencha Touch's "Ext" top level namespace to something else.
Ok, on to Templates.
In the Sencha templating system, users can embed their templates within any HTML tag that won't muck with it: for example script tags with a custom type (or more typically in Sencha's case a textarea)
var myTpl = Ext.XTemplate.from('theIdOfMyTpl')
You can also store your templates in separate files and load them via an XHR. Though we generally recommend you write something on the server side to manage this for good performance.
re: IDE's
Sencha Architect handles this stuff automatically out of the box (including any places it's referenced in the project, etc). I believe our Eclipse plugin also handles this, but I'd have to check.

Seiryuu is correct. Comparing Sencha Touch vs Backbone.js is like comparing apples and oranges. However, I do want to highlight some differences you will see in developing with either of them.
Before I start, I want to clarify what Backbone is exactly....
Backbone.js is a framework to compliment other libraries like jQuery and/or Zepto. jQuery strengths lie in DOM manipulation not as a macro architecture. Hence why pure jQuery apps tend to be a mess. Backbone provides to traditional web developers the bare bones MVC structure to better organize an app.
To start of my comparison I'm going to start with defining classes...
For example, this is how you declare a class in Javascript:
function MyClass(){
this.myProp1 = 'my value 1';
this.myProp2 = 'my value 2';
this.myMethod = function(myParam){
//do something
}
};
var myInstance = new MyClass();
In Sencha, you declare a class like this:
Ext.define('MyClass', {});
Ext.create('MyClass', {});
Note the heavy reliance on magic strings. However, you could possibly create a make shift enum class with constants that you can use as the class names. Regardless, if you use magic strings for your class names you are going to have a hard time renaming your class 3 or 4 months down the road.
For differences in using HTML...
Traditionally, we declare a form like this:
<form action="/myAction.php">
<label for="username"/>
<input type="text" name="username"/>
<label for="password"/>
<input type="password" name="password"/>
<input type="submit"/>
</form>
In Sencha, you declare a form like this:
{
title: 'Basic',
xtype: 'form',
id: 'basicform',
scroll: 'vertical',
items: [{
xtype: 'fieldset',
title: 'Personal Info',
defaults: {
labelWidth: '35%'
},
items: [{
xtype: 'textfield',
name: 'name',
label: 'Name',
placeHolder: 'Enter Name'
}, {
xtype: 'passwordfield',
name: 'password',
label: 'Password',
placeHolder: 'Enter Password'
}
}]
}]
}
When it comes to templating, in Sencha you define a template like this:
var template = new Ext.XTemplate(
'<p>Name: {name}'</p>',
'<p>Kids: ',
'<tpl for="kids">',
'<tpl if="age > 1".',
'<p>{name}</p>',
'<p>Dad: {parent.name}</p>',
'</tpl>',
'</tpl></p>'
);
template.overwrite(panel.body, data);
With Backbone you have options...
Mustache:
{{items}}
<div>{{name}}</div>
{{/items}}
Or if you need more power jQuery:
<script type="text/template" id="item-template">
<div class="todo <%= done ? 'done' : '' %>">
<div class="display">
<input class="check" type="checkbox" <%= done ? 'checked="checked"' : '' %> />
<div class="todo-text"></div>
<span class="todo-destroy"></span>
</div>
<div class="edit">
<input class="todo-input" type="text" value="" />
</div>
</div>
</script>
With Backbone apps you can either define the templates as inline HTML or load them from external files. I would think you could do the same with Sencha, but I haven't seen any official prescribed methods. Just JS generated HTML strings.
These are just some basic differences between the two at the UI level. With Backbone you can better leverage your existing web skills and knowledge. With Sencha you are learning a complete new ecosystem with its own conventions and quirks.
With the heavy reliance on magic strings (see Sencha form example,) your IDE of choice will probably be limited in what it can do in terms of code completion. Which could possibly lead to slower dev time and a harder time finding bugs created by typos. However, Sencha does offer a Ext Builder app that is supposed to help you build the UI.
When it comes to application infrastructure (Models, Controllers, Services...) Backbone and Sencha are on par with each other. Sencha even has an advantage of sorts with its proxy layer that gives you more flexibility in regards to the integration of your server API, (Backbone is REST heavy.)
When it comes to PhoneGap I suggest you check out XUI. It's jQuery-like library built by the PhoneGap team that is optimized for mobile browsers. If your app is small enough it may not require a full blown app framework.
Hope this helps.

Sencha Touch - a full mobile JS library, along with widgets, animations and all sort of utilities for mobile html5 development.
Backbone - a lightweight library that provides all sorts of utilities for a JS app (structure, models, collections, key-value binding, templating...).
So I don't really see room for comparison here. Both are aimed at different things really. While some of their functionality may overlap, their aim is different. As for developing an app with phonegap and whether to pick Secnha Touch or Backbone - I'd say it depends on the app. I've done Phonegap apps with both - Sencha has a lot of things built in already. In some cases that means faster app development. Other times it might be a hindrance. Backbone gives you basic, non-mobile-specific utilities to build your app. Meaning, writing styles by hand, animations... To sum it up, it depends on the app and your personal preferences/coding style.

Sencha touch gives you a lot of pre-made widgets, but its a lot of work if you want to customize them, or create something "off the beaten path". You end up creating a custom component and digging through lots of layers.
Backbone is more lower-level access and not as "packaged". If you need mobile UI components you can use something like jqtouch - also written by david kaneda, before he went to sencha. not as fully featured, but the basics are there.

Related

Combining Galen and Protractor frameworks

The Story
We've been using Protractor framework extensively and have established a rather large test codebase. We've also been following the Page Object pattern to organize our tests.
Recently, we've started to use the Galen framework to fill the gap of visual/layout/responsive design testing. We really like the framework and would like to proceed with using it more.
The biggest problem right now is Page Objects. Both frameworks have its own ways of defining page objects.
Here is an example Protractor page object:
var LoginPage = function () {
this.username = element(by.id("username"));
this.password = element(by.id("password"));
this.loginButton = element(by.binding("buttonText"));
};
module.exports = new LoginPage();
And, here is a sample Galen page object:
this.LoginPage = $page("Login page", {
username: '#username',
password: '#password',
loginButton: 'button[ng-click*=login]'
});
Currently, we are duplicating the locators and repeating ourselves - violating the DRY principle. And, the other follow-up issue is that Galen only supports "by css", "by id" or "by xpath" location techniques at the moment - which means page objects don't map one-to-one.
The Question
Is there a way to avoid repeating page objects and element locators combining both Protractor and Galen together?
Given the information available, I don't see a direct way to combine it.
However, Galen and Protractor are available on Github and I don't see any bigger obstacle from aligning/forking/modifying them to what you need.
The best shot I see is to contribute to Galen framework and extend their GalenPages.js with a mapping functionality to Protractor Page Objects. Though there are 600+ lines of code in that .js-file, it seems doable within reasonable efforts.
At least to open an issue in the Galen GitHub project in that direction would sure be worth the effort.

What is the difference bettween ListView, FormView, and PageView? in JScript for (ODOO | OpenERP)

What is the difference between ListView, FormView, and PageView in openerp.web.XXXXXXXX.include({...? and are there more? I've been trying to learn JS for ODOO, but the official documentation it's poor or not precise, I really wanna know how to use them properly? and how many more are there?, It would be great if you can share a guideline about this topic. Thanks for your time!
Basically you can learn concepts of views with all the possible properties and it's child elements from Odoo documentation.
Forms
Form views are used to display the data from a single record. Their root element is <form>. They are composed of regular HTML with additional structural and semantic components.
Deal with single record at a time.
Can contains other structural components (like notebook, sheet).
There is no scope to sorting & searching because at the moment there is only single record.
Lists
The root element of list views is <tree>. The list view's root can have the following attributes:
Display record set in tree.
Can not contain any structural components.
Searching and sorting is possible.
There are javascript files are for each view in odoo, you can refer it from WEB module.
Web/static/src/js/view_form.js
Web/static/src/js/view_list.js
Web/static/src/js/view_list_editable.js
Web/static/src/js/view_tree.js
And other supportive functions sidebar, xml_to_json, xml_to_str, json_node_to_xml, fields_view_get and many others are available inside the views.js.
Page is structural component so it's covered inside the formview.
Javascript module structure for WEB.
JavaScript module mainly construct based on these three concepts.
Classes
Widgets
The QWeb Template Engine
Classes :
Much as modules, and contrary to most object-oriented languages, javascript does not build in classes although it provides roughly equivalent (if lower-level and more verbose) mechanisms.
For simplicity and developer-friendliness Odoo web provides a class system based on Javascript Inheritance.
Widgets :
The Odoo web client bundles jQuery for easy DOM manipulation. It is useful and provides a better API than standard W3C DOM2, but insufficient to structure complex applications leading to difficult maintenance.
Much like object-oriented desktop UI toolkits (e.g. Qt, Cocoa or GTK), Odoo Web makes specific components responsible for sections of a page. In Odoo web, the base for such components is the Widget() class, a component specialized in handling a page section and displaying information for the user.
The QWeb Template Engine :
This allows generating and displaying any type of content, but gets unwieldy when generating significant amounts of DOM (lots of duplication, quoting issues, ...)
As many other environments, Odoo's solution is to use a template engine. Odoo's template engine is called QWeb.
QWeb is an XML-based templating language:
It's implemented fully in JavaScript and rendered in the browser
Each template file (XML files) contains multiple templates
It has special support in Odoo Web's Widget(), though it can be used
outside of Odoo's web client (and it's possible to use Widget()
without relying on QWeb)
Example: (Retrieves the view's number of records per page, default is 80, you can update it by override this method))
There are two main thing to achieve this kind of task.
Adding/updating methods according to need.
Add created files to proper template.
Add this function for javascript file and add this file into web_backend assets using template inheritance then effect of this code will comes automatically.
instance.web.ListView.include({
limit : function(){
if (this._limit === undefined) {
this._limit = (this.options.limit
|| this.defaults.limit
|| (this.getParent().action || {}).limit
|| 160);
}
return this._limit;
},
});
Xml code:
<template id="assets" inherit_id="web.assets_backend">
<xpath expr="//script[#src='/web/static/src/js/view_tree.js']" position="after">
<script type="text/javascript" src="your script file path"></script>
</xpath>
</template>
Install your module and see the effect, the same way you can achieve anything using javascript inheritance.

How to make the javascript code easy to maintenance

All, I am working on a highly interactive web application which will need a lot of jquery or js code, And I'm finding that my code is becoming a little hard to maintain and is not all that readable. Sometimes even the author can't find the specified code.
So far what I had done for the clear code is below.
One js component in one js file .(for example. CustomTab.js is a tab component in my app.)
Using the templete to generate component HTML based on JSON.
Using Jquery UI.
Unobtrusive JavaScript.
Is there any other points I need pay attention? Anyway, Any suggestion or recommend technique for making js library/framework easy to miantanance is appeciated, thanks.
I could suggest you to use module pattern together with RequireJS to organize your JavaScript code. For the production you'll be able to use RequireJS optimizer to build your modules into one JavaScript file.
Also if you're expecting that your client-side application will be huge, consider to use some JavaScript MVC framework like Backbone.js together with the server-side RESTful service.
I use this namespacing pattern for my libraries:
MyLibrary.ListView.js:
var MyLibrary = MyLibrary || {};
MyLibrary.ListView = {
doSomethingOnListView: function() {
...
return this;
},
doSpecialThing: function() {
...
return this;
},
init: function() {
// Additional methods to run for all pages
this.doSomethingOnListView();
return this;
}
};
Whichever page needs this:
<script type="text/javascript" src="/js/MyLibrary.ListView.js"></script>
<script type="text/javascript">
$(function() {
MyLibrary.ListView
.init()
.doSpecialThing();
});
</script>
You can even chain methods if a certain page requires an additional function.
This is exactly the same question which I ask myself each time. I think there are few ways to get easy maintaining code.
Contribute in javascript opensource projects and understand how they solved that problem. I think you can gather some unique solution from each project and common part of projects structure will answer to your question about maintenance.
Use prepared solutions like backbone, knockout, ember or angularjs if I am not mistaken angular doesn't give you structure but provide you powerful tool for creating pages with less code. Also check todomvc for ready-made solutions.
Read books and try to create some structure for your needs. It will be difficult and long but result (maybe few years later :)) will be awesome.
Currently I'm also working on a JS framework for my company. What I'm doing is I use OOP elements for JS. In other words I'm implementing similar code to C# libraries(not that similar, simulating will be the correct word). As an example in C# you use Microsoft.Window.Forms, so I can use JSOOP and use method extending and overriding to create the same scenario. But if you gone to far in your project converting your JS code to JSOOP will be time consuming.
use JSLint, this will validate your code and bring down to a readable, script engine friendly code. Though JSLint is very strict so you can use JSHint also.
using seperate file for each component is a good idea I'm doing it also.
If you like you can download the jQuery developers version and you can have a general idea how they created the framework. I learned lot of thing looking at jQuery framework!

What JS library can be selected for RIA REST based application

I have ad idea to make some REST application. I already selected what I will use on server side.
But now I have a big big deal, what i should use to make RICH web app ?
I have middle javascript knowledges. I know jquery, I did my own jquery plugin. it should tell you about my level, so far from pro level.
But i would like to try make it by my self. And i'm thinking that jQuery it's not good choice for this kind of task. I would like to have something more flexible, and not looks like a lot of callback for specific events. Something maybe in MVC style.. But i don't want to spend a lot of hour to lear complicated stuff.
For example: ini PHP life there are a lot of frameworks, I choose Yii, it's really more easier to understand and make something, than Symfony (even 2nd version) for instance.
So i'm looking something similar Yii (but for a browser side), something fast, easy to learn, flexible and powerfull.
I thought maybe it could be cofeescript, or cappuccino or something else ...
BUT I don't have so much time to learn and try so many JS frameworks and libraries to make decision by my self, this is why i'm asking you all.
Thanks.
Typically my choice would be:
jQuery - for general stuff
Q promises library for handling of more
complicated asynchronous operations
Backbone for building model on the
client side
Mustache templates for interaction with HTML
Jasmine - for unit testing of the application
However if you plan to make very rich user interface, you need to handle many various events and you don't want to write your own visual controls (since they are complicated) you can go with ExtJS (note the potencial need to buy licence).
For me Jquery ui has always been easy to use with my limited javascript knowledge .The learning curve wasn't steep at all and lots of community plugins helped in the further development as well .
Apart from that you can try Mootools , Extjs (very nice components but requires a bit learning ) and yui (definite learning required for me ) .
I would recommend using jQuery because you already have some knowledge about it. When it comes jQuery UI it offers some functionality: http://jqueryui.com/demos/. Is this functionality RICH enough?
On top of jQuery, you can use several JS libraries to fullfil specific needs:
Charts:
http://www.highcharts.com/
Grid:
http://www.activewidgets.com/
When you are using JS it's really important that you keep your own JS code in good order. Devide your functionality into separate js-files. Think about your object structure. JS is prototypal language (you can inherit directly from other objects).
For me it took some time to find out the way to write good JS code. I highly recommend this book: JavaScript: The Good Parts (by Douglas Crockford).
// Namespace
var MyNameSpace = {};
MyNameSpace.vehicle = function() {
var that = {};
var my = my || {};
my.thisIsMyOwn;
that.publicFunction = function() {
my.thisIsMyOwn = "put something here";
};
return that;
};
MyNameSpace.car = function() {
var that = MyNameSpace.vehicle(); // "inheritance"
return that;
};

Ember nested applications and widgets

I'm designing the intranet web application for our company. One of the app. requirements is to provide "widget" platform. Which means that developers may create mini application, that will work inside the main web application and can use it's resources. Widgets could be independent of applications and they can have there own data models and behaviors. My task is to provide widget abstraction and widgets engine within application (widgets management and organizing on the application pages). I reviewed several JS "MV*" frameworks and it looks like Ember.js is the thing that I want to use. But I can't understand how to separate in Ember, the abstract functionality between widgets and the application. From one side, the main application is Ember application by itself that manages current widgets appearance, from other, widgets, are applications to. Is it possible to have nested apps in Ember, so can make something like:
Widgets.SpecificWidget1 = Em.Application.extend({
name:"I'm custom widget",
ready:function(){alert('Widget app Ready')}
});
App = Em.Application.create({
rootElement:"#widgetsPanel",
ready:function(){alert('main app Ready')}
});
App.WidgetsController = Em.ArrayController.create({
widgets:[Widgets.SpecificWidget1.create(),
Widgets.SpecificWidget1.create(),
Widgets.SpecificWidget1.create()]
});
App.WidgetsView = Em.View.extend({
});
<div id="widgetsPanel"></div>
<script type="text/x-handelbars">
<ul>
{{#each App.WidgetsController}}
{{#view App.WidgetsView contentBinding="this"}}
<li>{{content.name}}</li>
{{/view}}
{{/each}}
</ul>
</script>
If this way is not correct to do this, can you please tell what is the better way to do it?Thx
It's hard to tell what's happening in the code, but this is my best guess of what you're trying to do. This isn't designed to work as is, but it should put you on the path to what you want to do:
Widgets.SpecificWidget1 = Em.Object.extend({
name:"I'm custom widget",
ready:function(){alert('Widget app Ready')}
});
Assuming this is supposed to be the base model you're working from, the Widget is extending Ember.Object, as that's a tangible thing. As far as I can tell, there's not much to be gained from extending Ember.Application in most use cases, and in a basic scenario where your Ember Application is an entire page, you'll never want more than one.
App = Em.Application.create({
rootElement:"#widgetsPanel",
ready:function(){alert('main app Ready')}
});
App.WidgetsController = Em.ArrayController.create({
widgets : [Widgets.SpecificWidget1.create(),
Widgets.SpecificWidget1.create(),
Widgets.SpecificWidget1.create()]
});
As far as I can tell this is okay.
App.WidgetsView = Em.View.extend({
});
You don't really gain anything from this by itself. If you give it a 'templateName' attribute, you can bind it to a particular template defined in Handlebars to get some functionality, and wrap the general Widget to get a better MVC setup going. But for what you have, you could remove this.
For what I'm working on at the moment, I have a design setup that looks like this Fiddle: http://jsfiddle.net/PastryExplosion/99CMD/

Categories

Resources