Binding boolean (Property) to List operations in JavaFX - binding

I found JavaFX to be suprisingly expressive after getting over the fact that I had to redeclare every field as property so I am a little stumped and would like to know if there is a better, more idomatic way of binding a boolean to some more complex operation like adding and removing style classes.
In this example I have a project that maybe valid or not and I want the font color of the tab to indicate which it is. I am doing this by adding and removing the error style class:
val errorSwitch = { valid : Boolean ->
logger.debug {"errorSwitcher: $valid"}
if( valid) tab.styleClass.remove("error")
else tab.styleClass.add("error")
Unit
}
product.isValid.onChange (errorSwitch)
errorSwitch(product.isValid.value)
What I don't like here is that I have to call the function once myself to start with because "onChange" obviously does not trigger unless the isValid actually changes. It's a small thing but I am wondering if there isn't a better way with bindings because thats what I want: the presence of the error class should be bound to "isValid"

In TornadoFX the best way to achieve this is to use the toggleClass function, which will automatically add or remove a given class based on a boolean observable value. Therefore you can simply say:
tab.toggleClass(Styles.error, product.isValid)
This example requires you to use the Type Safe CSS feature of TornadoFX. Read more about Type Safe CSS in the guide :)

Related

Updating dynamically computed property in polymer.dart

I have a scenario where I have a property that is data-bound using polymer.dart, but it does not have its own backing field. Instead it is dynamically evaluated at run-time by logic which is dependent on a lot of other internal conditions. So when other logic dictates I want to tell the data-binding to update the value. In C#/XAML the NotifyPropertyChange does not require you to pass in old and new value so it is easy to solve this. But in polymer.dart we do need to pass old and new value always, which is not possible for a dynamically evaluated property (or at least not preferable for performance reasons). How would we handle this in polymer.dart?
Here is a pseudo example. The question is what I should put in the ??? fields?
class MyBoundClass extends Observable {
void run() {
... logic, sets values in several internal non-observable objects...
notifyPropertyChange(#status, ???, ???);
}
String get status {
result = ... logic, evaluates values from several internal non-observable objects...
return result;
}
}
I guess one solution would be to simply introduce another backing field in MyBoundClass. But what I really want is just to update the binding and I don't see why it required to pass the old value. It seems to me that if you just want to update the binding, the old value is not relevant?
Passing null as old value should do.

Is it possible to test whether a Dart List is growable?

Given a List, is it possible to test whether the list is growable?
Trying to set the length and catching an UnsupportedError seems like a solution (though it isn't clear what would happen if you just set the length to the same value). Any better solution?
There is no way to detect if a list is growable (short of using reflection to find the implementation type, which is brittle, won't work the same way in dart2js, and increases code size).
The only valid use-case we encountered was to have checks/asserts when a library returns a list. In all other cases a function/library tried to modify an argument without knowing if it was allowed to do that.
If a function/library can work destructively it should require a boolean (or similar) so that the callers can decide if their argument can be changed. The callee should never silently modify its inputs unless it is obvious (for example fillFoo(list)) or an argument tells it so (for instance computeSquares(list, inPlace: true)).
http://dartbug.com/13926 is still open, but I expect it to be closed tomorrow with status "NotPlanned".
It is possible using reflection (not straight-forward either).
I guess this isn't any better than catching the exception.
print(MirrorSystem.getName(reflect(new List.from([0,1,2], growable: true))
.type.simpleName) == ('_GrowableList'));
EDIT
It is discouraged to use the name of a symbol - see Converting a Symbol into a String

Delphi: TStringList.Contains?

Is there any integrated solution in Delphi 2007 to check whether a TStringList contains a part of a certain value?
e.g.:
List.AddObject('This is a string', customStringObject1);
List.AddObject('This is a mushroom', customStringObject2);
List.AddObject('Random stuff', customStringObject3);
Searching for "This is a" is supposed to deliver me "true", since the first two elements contain this partwise.
The only method i'm aware of so far is TStringList.find(string,integer), but this performs a complete string comparision, i.e. only searching for This is a string will return true.
Any suggestions?
Not integrated, but you can use the Pos function on the Text property:
Pos('This is a', List.Text)
And if you want it to be integrated, you can create a class helper for TStrings.
Not directly, no. You would have to either:
1) call Pos() on the Text property, which is not efficient if you have a lot of strings.
2) loop through the list manually, calling Pos() on each String. More efficient, but also more coding.
3) derive a new class from TStringList and override its virtual CompareStrings() method to compare strings however you want (the default implementation simple calls AnsiCompareStr() or AnsiCompareText(), depending on the CaseSensitive property). Return 0 if you find a match. You can then use the TStringList.Find() method, which calls CompareStrings() internally (be careful, so does TStringList.Sort(), but you can avoid that if you call TStringList.CustomSort() instead).

Using element to element binding in Silverlight 3?

I don't really see the need for element to element binding in Silverlight 3 if using MVVM. Won't having one property directly affect another proper cause that property to be untestable?
To me, it makes more sense to do a two way binding to a explicit property defined in the ViewModel.
I agree that the use of MVVM severely deflates the usefulness of element to element binding.
Still, if all you are doing is binding two elements using a ViewModel property... what can you test? You can test that setting a property in the ViewModel sends a PropertyChanged event... but thats about it. Only when something else cares about that value is it useful to test a property like that.
In the simple cases, I can see element2element binding being more efficient and less code.

Regarding F# Object Oriented Programming

There's this dichotomy in the way we can create classes in f# which really bothers me. I can create classes using either an implicit format or an explicit one. But some of the features that I want are only available for use with the implicit format and some are only available for use with the explicit format.
For example:
I can't use let inline* (or let alone) inside an explicitly defined class.
The only way (that I know) to define immutable public fields (not properties*) inside an implicitly defined class is the val bla : bla syntax.
But there's a redundancy here. Since I'll end up with two copy of the same immutable data, one private, one public (because in the implicit mode the constructor parameters persist throughout the class existence)
(Not so relevant) The need to use attributes for method overloading and for field's defaults is rather off putting.
Is there anyway I can work around this?
*For performance reasons
EDIT: Turns out I'm wrong about both points (Thanks Ganesh Sittampalam & MichaelGG).
While I can't use let inline in both implicit & explicit class definition, I can use member inline just fine, which I assume does the same thing.
Apparently with the latest F# there's no longer any redundancy since any parameters not used in the class body are local to the constructor.
Will be gone in the next F# release.
This might not help, but you can make members inline. "member inline private" works fine.
For let inline, you can work around by moving it outside the class and explicitly passing any values you need from inside the scope of the class when calling it. Since it'll be inlined, there'll be no performance penalty for doing this.

Resources