Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Simplify Binding Description Language #87
I personally do not like the binding description how it is done currently.
Can't we add something similar to the WPF Binding?
I would actually prefer:
What do you think about?
Linked to #62
If you want to experiment then I think (in vnext at least) you can just override the registered IMvxBindingDescriptionParser implementation.
Actually we have to think about what we have to declare in the binding description:
I'll think about a better solution and share my ideas as soon as I can life with them XD
More techie info for you.
So to replace the parser:
will need to become:
and you can then override:
with your own implementation in your own setup.cs file.
Current binding capability is:
Please note that default binding in Droid is generally set to TwoWay
I occasionally get asked about other fields in the binding - e.g. about CommandParameter - but nothing really solid on this.
Have made the changes to allow setup.cs override of the binding builder... a very simple binding builder might just be to support only Mode, Path, Converter, ConverterParameter (ignore Fallback).
We could then write a parser which took individual inputs like:
with some known delimiter - e.g. something like
That might then produce inputs strings like:
If you want a simple place to start experimenting then try using this file:
in the simple dialog binding sample - https://github.com/slodge/MvvmCross/tree/vnext/Sample%20-%20SimpleDialogBinding/SimpleDroid
Some of the suggestions I got (and gave) online yesterday included using text like:
Really, if we are breaking away from the XAML and JSON syntax then we are free to do whatever we like!
A few things to remember:
Enjoy - good luck!
Ok, current idea looks like this: (some samples)
First we do always have an assignment saying to which TargetProperty we
For properties we do already know the possible values you can remove the
Currently it is in a proof of concept state. As I'm not sure what kind of
Actually the way defining the ConverterParameter in brackets looks very
2012/12/22 Stuart Lodge email@example.com
From github bounced email:
All looks good to me :)
I especially like the look of things like:
On Mode, one thing I said wrong is what happens when no mode is provided.
When no Mode is provided then the Mode is Mode.Default - and what happens then depends on the Binding itself.
In Wpf most Mode.Default bindings are Mode.OneWay, but in mvx-Droid, many bindings are Mode.TwoWay - especially because I find I write many bugs in Wpf because of OneWay default
I'll be home again in 2 days. Will start playing with code then :)
After consideration, my preference is for:
e.g. for binding property Text to source Name we would use:
If you want to specify the binding mode, then use
If you want to bind to the whole source object then use
If you want to bind to subObjects, then use normal dot notation:
No idea when we'll ever code any of this... but I love the idea :)
referenced this issue
Jan 1, 2013
What do you mean by using Converters/ConverterParameter?
It would be cool to specify the ConverterParameter as a binding by itself.
would bind to PropertyX, using the Converter "ConverterXY" and the Value in PropertyY as a the parameter.
Another question is how we can pass static values. We could use a syntax like:
What do you mean by accepted datatypes?
I do not really like the *-solution for the whole object.
Another question is how to access specifiy items of a collection, may something like this:
Multibinding does not make that much sense in out use case as we can only bind to the ViewModel. Out of my opinion a proper designed ViewModel which clearly shows the Property's we want to bind to makes Multibindings obsolete.
DefaultValues will actually be the same as the FallbackValue. In WPF we do have the possibility to specify a FallbackValue when the binding is corrupt and a TargetValueNull-value when the property we bind to is null.
Ooops - sorry - doing a thousand things so never answered...
Agreed - but leave for a later change. bindings with multiple dependencies require some thought... it's a bigger change than just swapping the parser for a new one.
in the current json parser, static values are currently passed in to the value converters as objects (but Json.Net parses them as strings, bools, doubles
I think all I meant was the list of Types the parser can interpret in those static values (for converterparameter and for fallbackvalue) - JSON current handles strings, bools, doubles for us. I think WPF binding allows a similar set?
I'm happy to use something other than *
I choose * because there was no-way that could conflict with a property name :)
I don't like 'this' particularly - if you are writing 'this' inside the xml for an Android control then that kind of suggests 'this' is the android control - but actually what you want to mean by 'this' is the whole of the binding source object.
This can't be done in WPF binding? So we don't need to do it in ours? If someone really wants to do it, then they can use a valueconverter?
I'm happy to leave Multibinding to later - but I do think Multibinding can be useful (what I mean by multibinding is http://blogs.mscommunity.net/blogs/borissevo/archive/2009/01/20/wpf-trick-3-multibinding-and-stringformat.aspx)
Agreed - defaultValue was just me using the wrong name - fallbackvalue is what I use. I've only really used these for showing some default text while I'm waiting for an object to load. The code works, but if you don't want to expose these in your new syntax, then that's OK....
Sorry I didn't reply.... but really happy just to see us prototype some parsers and see what they look like... there is 'no one perfect design' - just diffferent shades of good :)
referenced this issue
Jan 16, 2013
got a prototype, will send it today evening... currently im skiing :)
Awesome stuff Stuart!
Just had a quick look to it and it looks quite fine to me!
But why did you introduce this "sections"?
local:MvxBind="Text Section.Title Converter=TheConverter, ConverterParamater=true, FallbackValue='Fred'; Click GoToCommand"
Do not like to write unnecessary braces ;-)
Additional it would be cool to have a kind of a short-form. Which means that I do not like to write "Converter" and even "ConverterParameter" all the time. I really liked the Converter(Section.Title, 'ConverterParameter').
I'm currently not sure whether i should like or dislike the possibility to Write "Text Section.Title" without a "=". I see that you can specify the Defaul-Binding-Mode in a very easy way, but it looks really unreadable to me... no idea :-P
How can I bind to the full object?
Is your Property-Parser included?
Currently you can use ; and , wherever you want to... so this is supported:
Not sure I like it either... but it is nice not to have to remember where
It does also provide some break-up of the line maybe making it more
Text Section.Title Converter=TheConverter; Click GoToCommand
Maybe a different syntax is needed to reflect the two-way binding?
TheConverter(Text Section.Title, "ConverterParameter");
This is still all open for discussion... plus there's no reason we have to
Note that there is also the ability to specify Mode the old way too
So either of:
Only change really is it allows (and it'll be a bit slower)
We need an online forum somehow to discuss these changes - and to vote on
Also need to do some speed measurements at some point....
Day job now though!
Currently leaning towards:
So examples might be:
Also wondering if this wouldn't be better as:
Also wondering if we should go for Path in the bracketed list too:
I give up... we'll just use syntax like Xaml....
Mode disappears... we're just going for:
with options like: