I love skins in Flex 4 - they offer a really nice separation between logic and styling.
I was wondering how people use binding in skins. The easiest way is to just bind in the skin:
label="{ hostComponent.model.buttonLabel }"
you can also use 2 way bindings:
selectedItem="#{ hostComponent.model.selectedItem }"
but you could argue that this is logic so it should really be handled in the component. You don't really want to re-create all the bindings each time you create a new skin. That seems fragile and prone to creating bugs.
So what are the alternatives? Creating a bucket load of event listeners I suppose. The adobe observe and observeValues tags could be useful as well I suppose.
How do others handle this?
I think it's a good and interesting question. There are a couple of alternatives. I suppose you could inject the model into the skin and bind directly, but that seems wrong because I think the skin should be intimately connected with the component - if the component changes its reference to the model, it automatically changes in the skins. And anyway it only exaggerates the problem you mentioned.
You can create ids in the skin and operate on them from the model. For example
SKIN: label id="infoLabel"
COMPONENT: [SkinPart] var infoLabel:Label
creationComplete {
BindingUtils.bindProperty(this, 'infoLabel', model, 'infoLabel');
}
This solves your problem. No repetitive maintenance between skins of the same component. However using BindingUtils comes at a cost. Firstly it's not as evident what is bound to what - using the {} way is just so much more obvious. Secondly (I suppose this is actually just part of the first point) you might confuse less-able developers that have to read your code and figure out what's going on.
EDIT: This assumes your component is in AS3. If your component is in MXML, I guess you can just bind as you normally would in MXML.
Related
I've been working on the web for quite a long time and I saw the "best practices" evolve. I'm now fairly convinced separating HTML (Content), Javascript (Behavior) and CSS (UI) is the best thing to do.
A few months ago, I started using knockout.js . I did choose it among other similar frameworks like backbone or angular because a chapter in an MVC training I followed was about knockout, and the concept seduced me. Then after a quick comparison on the web it didn't look as a bad choice for my needs, and for a start.
But here's my problem : when I look at my HTML code now, after a few weeks of dev on a project, there's quite a lot of knockout bindings in it, and it makes me think a lot about the old times, when we (or at least I) used to put inline javascript event handling through onclick attribute and so on.
Therefore those 2 questions, which I'm not sure are 100% suited for SO, but I can't find any better StackExchange site to ask it :
Is using knockout (or the other frameworks as they all seem to basically work with the same pattern) contrary to the "separation rule" ? Or is it an acceptable small-step-out of this rule ? or is it even perfectly acceptable because it uses the "data-" attributes ?
In the case this would be a somehow bad practice, is there any possibility to do all the binding through a separate javascript file, using for example jQuery to select the controls and apply bindings to them ? If not possible in knockout, is it with another framework ? I must admit at the time I did my selection, I diddn't think about this kind of implications...
Thank you and sorry if this should be moved to another SE site.
I had the same initial reservations as you, but I have to say that having the bindings in the html and not hidden away in a JS file seems so much better to me, as the link between presentation and functionality is now completely obvious. It massively reduces the possibility of changing some HTML and breaking functionality because you weren't aware that someone had hooked up some javascript to an element using jQuery.
Also, as you point out, the use of the data-bind attribute does, I think, mean that it does adhere to the separation rule, though if you want to stick to it rigidly then make sure all bindings are to observables, computed or functions on your view model, don't use any code (i.e. a visible binding that checks the state of two observables). I'm not sure I'd take it that far though.
I guess everyone started to learn KnockoutJS have the same concerns.
IMHO, there must be some way that connects models(JS object) with views(HTML markup). Then we should have something that says:"When that button is clicked call this function with that arguments." or "Hide this element while you that JS array is empty" and so on. So how we can put/say/state that connection in a readable, reusable and clean way.
If you used another JS file to handle that connection, then you 'll have large lines of code just to put your connection logic and you need to know how to select the DOM element you are targeting. You 'll end up with massive code(probably lot of jQuery) just to make your HTML dynamic and alive(i bet most developers got into that many times). I haven't use other libraries or frameworks but i think they just make your massive code more organized.
On the other hand by KnockoutJS use Declarative Bindings, this is the link between models and views. It's more readable, easy to plug it in/out and it allow you to just focus on writing a good JS model object.
I guess to truly check separation think what if you sometime needed to change your model, how much changes you need to do to your view? and vice versa?
Adding to the rest of the answers, some tips:
Make sure there's no business logic in your bindings. Any logic (which should be minimal) should be "view logic": decisions that only affect how your view looks, not how it works. Deciding how many items to display per screen is view logic; deciding whether the user can add another item is business logic. It's perfectly OK to put view logic in your viewmodel rather than your view, and it's desirable if it involves lengthy expressions.
Keep "magic numbers" out of any view logic in your bindings. If it's a parameter that could be changed (e.g. number of weeks of results to show) as opposed to a true constant (e.g. number of days in a week), make it a property of your viewmodel and reference it in any expressions in your views.
I was wondering if it could be possible to create a databinding system in pure actionscript without using mx.binding.utils.
At least I would like to know what is the overhead of the databinding code and how exactly the ChangeWatcher knows when a property has been changed.
Thank you!
Check out the Diving in the Flex Data Binding Waters by Michael Labriola: http://www.ruffkutmedia.com/tutorials-diving-in-the-data-binding-waters-by-michael-labriola.htm (video) - slideshare here: http://www.slideshare.net/michael.labriola/diving-in-the-flex-data-binding-waters-presentation
There's a lot of work that goes on behind the scenes when you bind data, but he gives a really good explanation of how it works. It's a bit awkward to create something that works automatically unless you're passing through a "compile" phase where you add code.
You can also check out the as3 commons byecode project: http://www.as3commons.org/as3-commons-bytecode/index.html which should let you add code at runtime
The flex compiler actually compiles your MXML/AS3 to pure AS3 before it compiles it all to bytecode anyway. So at some stage in the compile process, data-binding is actually being implemented with ActionScript.
The problem is that Flex adds a bit of syntax specifically for data-binding. There is nothing stopping you from creating a data-binding system in AS3, but there are limitations, such as you would have to do it in an AS3 way.
I've created a number of skins for various components recently. Some of these were for Spark components and the default behavior of Flash Builder is to take the source code of the original skin and copy into your skin as a starting point.
Normally, I am 90% ok with the original skin, I just want to tweak or add one little thing. It seems to me that duplicating 3 pages of source code to do this is a bad idea. What do I do when I upgrade Flex SDKs? Do I have to go back through the source of all these original skins and (re)compare? This sounds like a disaster.
Is there a way I can create a new skin in MXML that inherits from the old skin? Can I do this via ActionScript?
If you upgrade your Flex SDK I don't think there should be any modification in the skinParts of components. Anyway if there were, you would have a compilation error if one of your implemented skinparts is not of the right type or if you miss a required skinPart. So I wouldn't worry if I were you :)
Another tip would be to use as much as possible CSS styling to avoid this kind of problems.
And no, I don't think you can inherit from a skin and modify its elements (but I'd be glad to be proved wrong).
I'm working on a project in Flash CS4/AS3 and I have a document class set up but I am wondering about using that, as opposed to frame-based scripting. Most of what I have seen so far deals with how to create them, but doesn't offer much about why or when to use them.
I know I can also pull in other classes beyond the document class but, again, why and when?
Could I get some input from you fine people out there on usage/best practice, etc?
Thanks
If this is just a simple demo or a movie, you can use the time line.
But if you're going to make a program, with classes, you should have a document class.
A document class is the main class of your programs. it's actually your initializer of all the program's processes and components, and it's simply more proper and similar to other programming languages.
Plus, it's in a different file, and it is easier to edit it this way.
Also, your doc-class will be a class and not just code in the air.. it also has auto-complete in CS5.
I've been writing in actionscript 3 using flex builder 3 for a couple of weeks now and never encountered the need to use anything like MXML. I code all layout and design in pure actionscript.
I am not sure why, but many people immediately expect me to have written a lot of MXML when I say that I'm using flex builder.
Is MXML really recommended? If so, why did I never encounter the need for it yet?
As MXML is compiled to ActionScript while building, there may be no need for MXML - everything can be coded in AS3.
However, I find that MXML is quicker to use in some scenarios - for example, composite components of the UI in an application.
If a composite component is a library-type component (a new type of generic widget - whether based on an existing control or completely custom), I use AS3 as I get finer control. The code for such controls will not change much over time, once a stable release is made.
If a composite component is a part of an application's UI which is more likely to change over time due to user-driven changes to the UI (e.g. application configuration panels) then MXML allows faster iterative development. This is the kind of change where you have to move controls around, change styling etc. in response to user or marketing feedback, or business-driven changes over time.