Do they both do the same?
Or is there a difference in the behaviour?
SuppressAccessDeniedRedirectInScope is a class that implements IDisposable. The constructor stores the original value of CatchAccessDeniedException and sets the value to false to suppress the automatic redirect within the using scope. The Dispose method restores the original value of CatchAccessDeniedException.
Related
How is setted the property descriptor for the built-in method? For example for isPrototypeOf? I did not find such a place in the specification. Rather found, but there is no description of the attribute [[Value]]. It sounds like this:
"Every other data property is described in clauses 18 through 26 and
in Annex B.2 has the attributes {[[Writable]]: true, [[Enumerable] ]:
false, [[Configurable]]: true} unless otherwise specified"
Now we know what the other attributes will have, but we do not know what value will be set in [[Value]]. You can say that the value in [[Value]] will be set to the function object and you will be right. However, I want to know by specification where this is the place where for built-in properties is set [[Value]]
However, I want to know by specification where this is the place where for built-in properties is set [[Value]]
The specification doesn't have algorithmic steps for initializing the global objects, which makes sense since they are expected to exist before execution of any code actually begins.
Instead of simply states what structure should exist, so for instance in 19.2.3 Properties of the Function Prototype Object, it simply states
19.2.3.1 Function.prototype.apply ( thisArg, argArray )
in the header with the expectation that it is clear that it means the apply function is a property of the %FunctionPrototype% global object. Given that, there are only two types of properties,
Accessor properties
Data properties
Data properties are explicitly simple properties that contain a value. Function.prototype.apply doesn't have get or set prefix, or use an ## prefix), which means that this statement is specifying a data string-keyed data property. By definition, this means that it is clear that the [[Value]] is the function object itself, because there is nowhere else to put it, and [[Value]] is the clear correct choice.
The section you linked in 17 ECMAScript Standard Built-in Objects states
Every other data property described in clauses 18 through 26 and in Annex B.2 has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } unless otherwise specified.
is just filling in the rest of the data property fields, since it wouldn't make sense to repeat them for every single method.
(This may be too localized an issue but I will try to generalize it)
Question: If a property setteris marked as Bindable, will it not get called if the new value is the same as the old value?
I am seeing the above behavior in a legacy project I have inherited: the setter is not getting called. If I don't declare the setter as Bindable then the setter is called no matter what the new value is.
Can anyone confirm that the above is the way things are designed to work with Binding?
This project uses Binding all over the place and there are no comments in the code so it is hard to tell what the dependencies are and which parts of the code depend on particular bindings. I'm trying to avoid making major changes but I also don't want to waste time trying to work around something which should be refactored.
The property is bound:
[Bindable]
protected var _source:AolMediaFile;
The setter is bound:
[Bindable]
public function set source(file:AolMediaFile):void{
_source = file;
// do some stuff with file
}
The setter should only get called if the event source is [Bindable]. Data binding is basically a chain of events dispatched from source to target in a variety of scenarios. When you declare your property or setter as [Bindable], that will basically change nothing in the behaviour in terms of side effects, as events are dispatched and listeners are generated. For example:
<your:Component source="{any.source.aolMediaFile}" />
Only when any, source and aolMediaFile are declared [Bindable], source would be invoked. Having source declared as a [Bindable] property is only interesting, if a second component would be depending on your component's state
<your:Component id="yourComponent" source="{any.source.aolMediaFile}" />
<s:TextField text="{yourComponent.source}" />
If you would want to bind to a property of AolMediaFile, then the class or the specific property has to be be [Bindable] as well.
Usually the compiler prints warnings, if bindings can't be generated:
warning: unable to bind to property 'source' on class 'Object'
(class is not an IEventDispatcher)
So check the source object, which are the source's host object's dependency and the compiler warnings.
So digging around here a bit more I came across this question: Flex: Help me understand data Binding on getters and setters which describes the code generated by declaring a setter or getter Bindable
So apparently in the generated code there is a check to see if the value is different:
public function set name(value:String)
{
if (_name == value)
return;
_name = value;
dispatchEvent(new Event("nameChanged"));
}
Ok, so this might be me being pendantic but I need to know the best way to do something:
(This is psudocode, not actual code. Actual code is huge)
I basically have in my package a class that goes like this:
internal class charsys extends DisplayObject {
Bunch of Variables
a few functions
}
I another class which I intend to add to the timeline I want to create a function like this:
public class charlist {
var list:Array = new Array();
var clock:Timer = new Timer(6000);
var temp:charsys;
function addObj(MC:DisplayObject, otherprops:int) {
temp=MC;
temp.props = otherprops;
list.push(temp)
}
function moveabout(e: event) {
stuff to move the items in list
}
function charlist() {
stuff to initialize the timers and handle them.
}
}
So the question is, is my method of populating this array a valid method of doing it, is there an easier way, can they inherit like this and do I even need to pass the objects like I am?
(Still writing the package, don't know if it works at all)
Yes, you can pass an object into a function, but you should be careful of what you are planning to do with that object inside that function. Say, if you are planning to pass only charsys objects, you write the function header as such:
function addObj(MC:charsys, otherprops:int) {
Note, the type is directly put into the function header. This way Flash compiler will be able to do many things.
First, it will query the function body for whether it refers to valid properties of a passed instance. Say, your charsys object does not have a props property, but has a prop property, this typing error will be immediately caught and reported. Also if that props is, for example, an int, and you are trying to assign a String value to it, you will again be notified.
Second, wherever you use that function, Flash compiler will statically check if an instance of correct type charsys is passed into the function, so if there is no charsys or its subclass, a compilation error is thrown.
And third, this helps YOU to learn how to provide correct types for functions, and not rely on dynamic classes like MovieClip, which can have a property of nearly any name assigned to anything, and this property's existence is not checked at compile time, possibly introducing nasty bugs with NaNs appearing from nowhere, or some elements not being displayed, etc.
About common usage of such methods - they can indeed be used to create/manage a group of similar objects of one class, to the extent of altering every possible property of them based on their corresponding values. While default values for properties are occasionally needed, these functions can be used to slightly (or not so slightly) alter them based on extra information. For example, I have a function that generates a ready-to-place TextField object, complete with formatting and altered default settings (multiline=true etc), which is then aligned and placed as I need it to be. You cannot alter default values in the TextField class, so you can use such a function to tailor a new text field object to your needs.
Hope this helps.
This would work, I think I would assign values to the properties of the charsys object before passing it into the add method though, rather than passing the properties and having a different class do the property assignment. If you have some common properties they could either have defaults in charsys class definition or you could set literals in the addObj method.
I have some confusion on what we call "binding" as ?
Is it :
1) Change in [Bindable] Model which leads to an automatic change in View ( bound to that model )
OR
2) Change in View and then an automatic change in the [Bindable] Model ( the View is bound with )
Thanks
The typical use of data binding in Flex is to bind some model object to a view object (#1).
In Flex 4, two way binding was introduced. This does both #1 and #2. That is any change made in the model is reflected in the view. But also, any change made to the value in the view updates the model value.
To use two way binding, add the # symbol to the binding expression in the view:
<s:TextInput text="#{model.someValue}" />
Note that when you make something Bindable, the mxml compiler generates a setter method for your Bindable variable, which dispatches an event anytime the variable changes. The mxml compiler then adds event listeners for this event to the view objects that are bound to the variable. So technically, any object (whether it is a view, model, controller, or something else) can be bound to a variable, as long as it can receive the event.
I have an interface named PropertyFilter which used to take a Propertyand decide if accepts it or not. And the world was good.
But now the interface changed, so that implementations may choose to add additional Propertys. For example a Customer property might get expanded into Name and Address properties.
I think it is obvious this is not a Filter anymore, but how would you call such a thing?
To clarify: the so called filter is pretty much a method with the signature
Property -> List<Property>
With an empty List denoting not accepting the Property, a List with exactly the input Property denoting accepting the property and a List with new Properties (possibly including the original one) denoting an expansion.
PropertyChecker
PropertyValidator
PropertyDistillator
PropertyAccreditor
...
Do you already have a name for the method you mention ? It might help us find a proper name for the interface as well.
I'm not really sure what your new function does. If it still returns a boolean, then another name for a function which returns a boolean value is a "predicate".
If it takes a Customer and decomposes it (perhaps you have one function which takes a Customer and returns a Name, and another which returns an Address), then I might call them "accessors". This term is often used to describe a member function of an object, but I think it could apply here, too.
If Customer has a Name and and Address, the it is no longer a property, but an entity.
The Customer property could be a reference to a Customer entity, in which case the semantic convention for your interface still apply.
I would add a method named validate to Property with the signature:
PropertyFilter -> Bool
The default implementation of validate simply passes this (the Property) to the filter and returns the result:
def validate (filter: PropertyFilter) = filter (this)
As a compound property, Customer overrides validate, implementing it in terms of its composite properties:
override def validate (filter: PropertyFilter) = name.validate (filter) && address.validate (filter)
This way, each Property can describe how to apply any given PropertyFilter to itself. I think you should avoid the List expansion approach.