I am going to use either knockout.js or angular.js libs (b/c of the binding support) for a web app.
My question is - how is your experience integrating these libs into existing UI libs like Dojo, jQueryUI, Ext.js, YUI,..
E.g. how is the usage of databinding suport/syntax in the UI libs? Do you have to implement something like custom binding in order to use the widget form UI lib?
For Knockout the situation is quite good. One can integrate with third-party widgets via custom bindings. Bindings API is very simple and strait-forward. All you need is to implement one or two methods (quoting Knockout docs):
ko.bindingHandlers.yourBindingName = {
init: function(element, valueAccessor, allBindingsAccessor, viewModel) {
// This will be called when the binding is first applied to an element
// Set up any initial state, event handlers, etc. here
},
update: function(element, valueAccessor, allBindingsAccessor, viewModel) {
// This will be called once when the binding is first applied to an element,
// and again whenever the associated observable changes value.
// Update the DOM element based on the supplied values here.
}
};
Most of the time implementing single update method is sufficient. There's even a collection of ready-made bindings for jQuery UI. It doesn't cover all jQuery UI widgets but since creating custom bindings is so simple you can implement your own bindings as you see need.
As for Angular JS the situation is more difficult. You can create a custom binding as a part of your own Directive. Directives API requires you to write much more code. The lifecycle of directives is quite complex, too. So, they would take quite a bit of time to learn.
At the same time it lets you specify a lot of different aspects of behavior. For example you can completely rewrite the inner HTML representation of a widget via directive and use Angular templates inside. In Knockout you'd need to use jQuery for that. Unfortunately, unlike custom bindings in Knockout directives are more suitable for writing your own widgets and not for integrating with existing ones.
To summarize:
Knockout bindings are easier. Integrating with third-party widgets is easy.
Angular directives are more suitable for writing your own widgets but are more powerful at the same time.
Typically you would implement custom bindings to work with external libraries, but there are often plenty of open source efforts that have already made considerable headway. Check out
https://github.com/SteveSanderson/knockout/wiki/Bindings
If there aren't any available, implementing your own isn't terribly complicated:
http://knockoutjs.com/documentation/custom-bindings.html
Related
I'm trying to better understand the fundamentals of A-Frame.
I understand how to use the getAttribute() and setAttribute() methods for
accessing component data. However I don't understand why we use them instead of just accessing the components attributes using dot notation.
A lot of people use something like:
document.querySelector("#myText").getAttribute('text').value
Why not use:
document.querySelector("#myText").components['text'].data.value
Is there something wrong with using that second way? What are the pitfalls? In my experiments I have experienced both ways returning "undefined" due to the code running before the scene is finished loading, but I have learned how to avoid that using the "loaded" event.
As you can see at this glitch example (https://glitch.com/~text-hierarchy) I've successfully printed data to the console using both ways.
Part of the standard
Both getAttribute(prop) and setAttribute(prop, value) are used to get/set attributes of any other DOM elements. MDN links here (get, set)
Compatible with aframe components
If you have a update() function in your a-frame component, setAttribute() calls it, notyfing, that a property of a component has changed.
It's not mandatory, it's even faster to modify some properties directly, but it has risks, like undefined behavior if a developer uses update() to monitor changes.
I need to design how to implement JavaScript module pattern in existing large .NET Web Forms application. Currently there are no rules and lot of JavaScript code uses global variables. The problem is also with communication between server and JavaScript client code, currently lot of JavaScript functions are called from code-behind classes and are inlined into page.
Current JavaScript usage example
A server control adds link to some JavaScript file to the <head> element so it will be downloaded. The file contains one or more global functions. Then the server control call's this global functions whenever it needs them, like following:
string script = string.Format("GlobalFunction1('{0}');", param);
And this string is inserted somewhere inside the <body> element in the HTML. There are no rules and the server can call any of the global function whenever it needs them.
The main goals for improvements are:
Separate server-side code from client-side JavaScript. This means no chaotic inline calls for JavaScript global functions.
JavaScript self functioning modules, which are not dependent on each other.
JS modules should not expose anything to global scope.
Every JS module has only one place to initialize itself.
Server-side should be able to populate some parameters to JS module initialization.
Here is the approach that I came with:
How would it look like on Server-Side
Every Control has its own JavaScript module
Every Control is wrapped inside its root <div> element.
Server can call this helper method in every page life-cycle: ScriptModule.AddParam("param_name", "param_value"); This params will be added to the Control's wrapper (div) on pre_render event call as HTML5's data- attributes.
Finally Server registers the module with ScriptModule.Register("module_name", "path_to_js_file", "controlWrapperId").
This results in these steps in HTML:
The <script> file (path_to_js_file) is inserted into the page which links to desired module's file.
The parameters are added into Control's wrapper (div) through data- attributes.
At the end of the page the inlined Core.start("module_name", "controlWrapperId"); is inserted, which starts the module's initialization. This method is discussed later in client-side section.
How would it look like on Client-Side
The first file that is downloaded is the Core.js file, which registers one global variable Core that is used to define new modules.
Every JavaScript file will be defined as module. This module should not expose anything to the global scope and should be self functioning. The template follows:
// 1. first param is module's name
// 2. than the array with dependencies to helpers modules
// 3. than the callback with following parameters
// a. jQuery object which references wrapper (i.e. div) of this module
// b. params hash-object, which contains server parameters from wrapper's -data attributes in format
// { 'param1_name': 'param_val',
// 'param2_name': 'param2_val' }
// c. then the external dependencies to helper modules
Core.htmlModule('mod name', ['external', 'deps'], function ($w, params, external, deps) {
// Here the module initializes itself
// it can communicate with other modules through Core.publish(); Core.subscribe();
// it does not return anything, because it is HTML module and so it does not expose anything
});
The second parameter defines so-called helper modules, which are for code reusing. Due to the normal module's independence and inability to expose some functions outside, there is needed something to share same code. This can be achieved by defining helper module, which can expose some of its properties and then be referenced from normal module.
I have been using Flex / Flash Builder for a number of years. The latest release of Flash Builder (4.7) seems to come with quite a few problems, the biggest of those being:
Does not detect component IDs in MXML. For example, you cannot Find Usages of the ID of a component. Keeping the cursor on the ID of a component does not even mark occurrences of the ID. Instead, it marks occurrences of the actual id words in the MXML.
Extremely slow.
I am seriously evaluating moving over to IntelliJ IDEA 12, especially after reading many experienced Flex devs raving about it and recommending it.
I tried it. It took me a while to get to terms with the new terminologies of the IDE (made easy by this doc and very helpful support personnel at JetBrains).
I was able to setup my (large) projects in IDEA with Adobe Flex 4.6 SDK and got it to compile fine. But I noticed many "errors" highlighted in my AS files which are all actually false alarms.
The ActionScript editor doesn't seem to recognise the objects defined in MXML. Apparently, this is a known bug in IDEA (tracked here). And this bug has existed for more than 2 years!
Quoting the JetBrains support personnel:
I must admit that highlighting of ActionScript files which do not contain classes, but instead included in mxml as <fx:Script source="some_file.as"/> is probably the only weak part of IntelliJ IDEA code highlighting. False error highlighting will go away if you embed AS code inside CDATA of <fx:Script/> instead of referencing as external *.as file. Though I understand that this is not always desired.
I'm afraid the fix won't go into 12 release because the release is very soon and the fix is too risky. Priority of the issue depends on votes and user feedback. So far we have only 2 votes (http://youtrack.jetbrains.com/issue/IDEA-52598) and as the fix is pretty complex we still haven't implemented it thinking that this is a rare use case. I hope to fix it in one of 12.x update releases.
My project is a huge one, with huge MXML files and even more huge AS code for each MXML. So, for organisation purposes, I need to logically split them into smaller files. So, merging the AS code with the MXML is not practical. The false error highlighting just drastically reduces the readability of the code. Also, it does not allow Control / Command-clicking component IDs in AS code to quickly navigate to the definition of the component in MXML (which, incidentally, is now broken in FB 4.7 as well, but worked well in FB 4.6).
This bug in IDEA is unfortunately a deal-breaker for me. But I am wondering how other Flex devs are able to overcome / work around this seemingly critical bug.
It seems unbelievable to me that just 2 people have been affected by this bug, especially with so many Flex devs recommending IDEA. Maybe I am doing something wrong?
All you Flex developers, I would appreciate your thoughts.
UPDATE
This is in response to RIAStar's excellent and detailed answer. But it doesn't quite help me completely. Let me explain why and how I use <fx:Script source>. I am using Flex 4.x, with almost only Spark components.
Suppose a brand new Flex project. The main application is an MXML file.
In this MXML file, suppose I have a signup form.
On editing the form (in each field), suppose I have to run validations and enable the Submit button only if the form is completely valid. This would mean I need to assign change event handlers to the form items. The event handlers is AS code.
Suppose there is a username field which needs an on-type uniqueness check, by calling the server asynchronously. The server communication code is also AS code.
And then of course, there is the Submit button handler, which is also AS code.
I usually put all the AS code in separate .as files and include it in the MXML using <fx:Script source>. This AS code is usually quite heavy, with a lot of functional and behavioural logic. Many times, based on user action, even the components in the MXML and layout of the elements is modified through this AS code.
If I understand you guys right, none of this event handler code should be in these MXML script files. So, where should it be? How do you guys do it? I am not sure how the Spark Skinning architecture has anything to do with this.
Since I can't think of a gentle way of putting this, I'll just be blunt: I'm afraid the reason only two people think this is a critical bug, is that most seasoned Flex developers will agree that using <fx:Script source="some_file.as"/> is bad practice.
You effectively create two files that represent one class. From a readablity POV, which you seem concerned about, that's not a good move. One of these files (the .as file) is just a bunch of functions that cannot exist in their own right: they are tightly coupled to another file/class, but just looking at the .as file there is no way of knowing which class it is coupled to. Of course you can use some kind of naming convention to work around this, but in the end ActionScript/Flex is supposed te be used as a statically typed language, not a scripting language relying on mixins and naming conventions (don't get me wrong: I'm not saying scripting languages are bad practice; it's just not how ActionScript was conceived).
So what are your alternatives?
I suppose the main reason behind this construct is that you wish to separate MXML from ActionScript code, or in more abstract terms: separate the view from the logic. Fortunately this can be achieved in a few other, cleaner ways. Which solutions are available to you depends whether we're talking Flex 3 (or earlier) or Flex 4.
I realise that you may not have time to refactor your code to one of the proposed solutions, but I didn't want to leave you with just a "that's not good practice" answer.
Flex 3 (mx)
Code behind: A lot of developers used the so-called "code behind" pattern to separate their logic from their view. You can find plenty of information on the topic by Googling "flex code behind". I don't need to repeat all that in here. I'm not much of a fan of the concept because it relies heavily on inheritance and the two resulting classes are still pretty tightly coupled, but at least we're talking two classes. If you design your architecture well, you may even be able to reuse some of your base classes.
Compose model en controller: I used to create a separate "presentation model" class and a "controller" class for each MXML view and then use it something like this:
<!--MyView.mxml-->
<mx:VBox>
<m:MyModel id="model"/>
<c:MyController model="{model}" view="{this}"/>
...
</mx:VBox>
MVC purists won't like this, but it worked pretty well for me in thencontext of Flex applications.
Later when Direct Injection supporting frameworks (like Parsley) made their appearance, I could use injection to wire all those classes instead of hard-wiring them like in this example.
MVC frameworks: My knowledge of this topic is sparse (because in my opinion Flex is a very decent MVC framework that requires no third-party additions, but that's another disussion), but in short: they can help you separate logic from view in a clean way.
Flex 4 (Spark)
With Flex 4, the Spark skinning architecture was introduced, which allows for very nicely separated view and logic. You create a so-called 'host component' class in plain ActionScript, which contains all of the behavioural code, and a 'skin' class in MXML which defines the visual representation of the component. This makes designing reusable components very easy.
As per your request, here's a simplified example of how you might use Spark skinning to create your signup form.
Let's start with the skin class since it's easy to understand. It's just a form with some input fields. The HostComponent metadata tells the skin it's supposed to work together with the SignUp host component.
<!--SignUpSkin.mxml: the visual representation-->
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark">
<fx:Metadata>
[HostComponent("net.riastar.view.SignUp")]
</fx:Metadata>
<s:Form>
<s:FormHeading label="Sign up"/>
<s:FormItem label="User name">
<s:TextInput id="userInput"/>
</s:FormItem>
<s:FormItem label="Password">
<s:TextInput id="passwordInput" displayAsPassword="true"/>
</s:FormItem>
<s:Button id="submitButton" label="Submit"
enabled="{hostComponent.canSave}"/>
</s:Form>
</s:Skin>
And now the host component in pure ActionScript. It has to extend SkinnableComponent to be able to use our skin (there's also SkinnableContainerwhich I've just recently explained in this question: Flex mxml custom component - how to add uicomponents?, but we won't be needing that here).
public class SignUp extends SkinnableComponent {
[SkinPart(required="true")]
public var userInput:SkinnableTextBase;
[SkinPart(required="true")]
public var passwordInput:SkinnableTextBase;
[SkinPart(required="true")]
public var submitButton:IEventDispatcher;
[Bindable]
public var canSave:Boolean;
override protected function partAdded(partName:String, instance:Object):void {
super.partAdded(partName, instance);
switch (instance) {
case userInput:
userInput.addEventListener(TextOperationEvent.CHANGE,
handleUserInputChange);
break;
case passwordInput:
passwordInput.addEventListener(TextOperationEvent.CHANGE,
handlePasswordInputChange);
break;
case submitButton:
submitButton.addEventListener(MouseEvent.CLICK,
handleSubmitButtonClick);
}
}
private function handleUserInputChange(event:TextOperationEvent):void {
validateUsername(userInput.text);
}
...
}
What's important here?
The variables marked as SkinPart will automatically be assigned the components with the same id that exist in the Skin you just created. For instance <s:TextInput id="userInput"/> will be injected into public var userInput:SkinnableTextBase;. Note that the type is different: SkinnableTextBase is the base class of TextInput; this allows us to create another skin with e.g. a TextArea instead of a TextInput and it'll work without touching the host component.
partAdded() is called whenever a SkinPart is added to the display list, so that's where we hook up our event listeners. In this example we're validating the username whenever its value changes.
When the validation is done, you can simply set the canSave property to true or false. The binding in the skin on this property will automatically update the Button's enabled property.
And to use both of these classes together:
<v:SignUp skinClass="net.riastar.skin.SignUpSkin"/>
I actually have become quite fond of using RobotLegs.
In my MXML views I try to keep all logic outside of the MXML and simply dispatch events out to the mediator. From there I can put code in the mediator to the heavier AS needed.
What's the fastest way to render dijit widgets?
I know that the programmatic way is faster than the declarative. (Some reference)
I have a custom widget that loads too slowly (it's a datagrid with combobox, buttons and other small dijit widgets used for adding filters, etc).
Looking at the source, I see that all the dijit widgets are created programmatically, but the DOM nodes where they are inserted into are created programmatically as well.
Is it the "right" way?
I'm trying to speed up the rendering of this widget, and currently my choice would be to combine a velocity template (my company uses struts2 + velocity) to create the DOM nodes, with programmatically created widgets (using placeAt and similar methods to insert the widgets into the already built DOM nodes).
It would work fine, but sadly all the css classes are overwritten by dijit, so I have to overwrite them again, which causes a sensible overhead.
In the template I write something like this:
<input id="idOfAnExistingDomNode" class="myCssClass" />
And to insert a FilteringSelect in that DOM node I have to write this:
var fieldSelect = new dijit.form.FilteringSelect({
store : jsonStore,
searchAttr : "caption",
labelAttr : "caption",
selectOnClick : true,
value : "Content"
}, "idOfAnExistingDomNode");
fieldSelect.domNode.className += " myCssClass";
The last line is necessary because myCssClass is overwritten during the creation of the FilteringSelect.
Is there any way to avoid this issue?
Or, perhaps, I'm trying to do this thing the wrong way? I'm not completely sure about that "velocity template" thing.
Note: Dojo version is 1.5 and no, sadly we can't upgrade it to newer versions.
Please forgive me for my TERRIBLE English.
Often one of the faster ways to instantiate widgets is to create them in a temporary div and then move that div onto the DOM. Have you tried profiling what exactly is slow in this instantiation? Part of me wonders if too much time is being spent waiting for data, as a few widgets + a grid with reasonable pagesize params shouldn't take long to load.
As for your class issue, it is strange that dojo is not mixing in the existing class. That said, you could do a lookup on the node first, get the class attribute, and then specify it as
the class attribute in your mixin object when creating the FilteringSelect. If you do so, be sure you wrap class in quotes or older IE's will reject it.
recently I found in one of my older projects (asp.net 4.0)
that I've been using this code
to set display Style-property To none
DDL_ChosenEmpl.Attributes.Add("style", "display:none");
lately I was using
DDL_ChosenEmpl.Style.Add("display", "none");
i would like to know
in any case such as - property already exist whether it's with different value or not , will any of them should be avoided ?
what are the main differences between both methods ?
Both does the same functionality as you have done. The thing is, in "Attributes" collection, you have a control's other attributes like "click", "dblclick", etc. You can use either way. I believe Microsoft has given the later part for user's convinience to make coding easy.