New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify Binding Description Language #87

Closed
sschoeb opened this Issue Dec 20, 2012 · 25 comments

Comments

Projects
None yet
2 participants
@sschoeb
Contributor

sschoeb commented Dec 20, 2012

I personally do not like the binding description how it is done currently.
To many ' and :. Just to complex to write it in a fast way

Can't we add something similar to the WPF Binding?

Instead of:
test:MvxBind="{'ItemSource':{'Path':'Customers'}}"

I would actually prefer:
test:MvxBind="ItemsSource, Path=Customers, Converter=XyConverter"

Event better:
test:MvxBind="ItemsSource=Customers Converter=XyConverter"

What do you think about?
Or is there any reason why you have chosen the json approach?

@sschoeb sschoeb closed this Dec 20, 2012

@sschoeb sschoeb reopened this Dec 20, 2012

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Dec 20, 2012

Contributor

Linked to #62

If you want to experiment then I think (in vnext at least) you can just override the registered IMvxBindingDescriptionParser implementation.

See:

Contributor

slodge commented Dec 20, 2012

Linked to #62

If you want to experiment then I think (in vnext at least) you can just override the registered IMvxBindingDescriptionParser implementation.

See:

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Dec 20, 2012

Contributor

And in any new implementation, I'd hope for something nicer than WPF's implementation - I don't get on with the {Binding Path=ThePath, Converter={StaticResource TheConverter}} at all ;)

Contributor

slodge commented Dec 20, 2012

And in any new implementation, I'd hope for something nicer than WPF's implementation - I don't get on with the {Binding Path=ThePath, Converter={StaticResource TheConverter}} at all ;)

@sschoeb

This comment has been minimized.

Show comment
Hide comment
@sschoeb

sschoeb Dec 20, 2012

Contributor

Actually we have to think about what we have to declare in the binding description:

  • PropertyName we want to Bind to
  • Property on The ViewModel we want to Bind
  • Converter
  • Binding Mode

Anything else?

I'll think about a better solution and share my ideas as soon as I can life with them XD

Contributor

sschoeb commented Dec 20, 2012

Actually we have to think about what we have to declare in the binding description:

  • PropertyName we want to Bind to
  • Property on The ViewModel we want to Bind
  • Converter
  • Binding Mode

Anything else?

I'll think about a better solution and share my ideas as soon as I can life with them XD

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Dec 20, 2012

Contributor

More techie info for you.

The IMvxBindingDescriptionParser is registered in IoC in https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Binding/MvxBaseBindingBuilder.cs

So to replace the parser:

  1. Write a new parser

  2. Inherit from https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Binding.Droid/MvxAndroidBindingBuilder.cs and override

    protected virtual void RegisterBindingParametersParser()
    {
        var parser = new MvxJsonBindingDescriptionParser();
        this.RegisterServiceInstance<IMvxBindingDescriptionParser>(parser);
    }
    
  3. In Setup.cs we'll need to do a little refactoring as it looks like I didn't make it easy to replace the binding building - sorry.

This:

   protected override void InitializeLastChance()
    {
        var bindingBuilder = new MvxAndroidBindingBuilder(FillTargetFactories, FillValueConverters, SetupViewTypeResolver);
        bindingBuilder.DoRegistration();

        base.InitializeLastChance();
    }

will need to become:

    protected override void InitializeLastChance()
    {
        var bindingBuilder = 
        bindingBuilder.DoRegistration();

        base.InitializeLastChance();
    }

   protected virtual MvxAndroidBindingBuilder CreateBindingBuilder()
   {
         return new MvxAndroidBindingBuilder(FillTargetFactories, FillValueConverters, SetupViewTypeResolver);
   }

and you can then override:

   protected virtual MvxAndroidBindingBuilder CreateBindingBuilder()

with your own implementation in your own setup.cs file.

Contributor

slodge commented Dec 20, 2012

More techie info for you.

The IMvxBindingDescriptionParser is registered in IoC in https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Binding/MvxBaseBindingBuilder.cs

So to replace the parser:

  1. Write a new parser

  2. Inherit from https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Binding.Droid/MvxAndroidBindingBuilder.cs and override

    protected virtual void RegisterBindingParametersParser()
    {
        var parser = new MvxJsonBindingDescriptionParser();
        this.RegisterServiceInstance<IMvxBindingDescriptionParser>(parser);
    }
    
  3. In Setup.cs we'll need to do a little refactoring as it looks like I didn't make it easy to replace the binding building - sorry.

This:

   protected override void InitializeLastChance()
    {
        var bindingBuilder = new MvxAndroidBindingBuilder(FillTargetFactories, FillValueConverters, SetupViewTypeResolver);
        bindingBuilder.DoRegistration();

        base.InitializeLastChance();
    }

will need to become:

    protected override void InitializeLastChance()
    {
        var bindingBuilder = 
        bindingBuilder.DoRegistration();

        base.InitializeLastChance();
    }

   protected virtual MvxAndroidBindingBuilder CreateBindingBuilder()
   {
         return new MvxAndroidBindingBuilder(FillTargetFactories, FillValueConverters, SetupViewTypeResolver);
   }

and you can then override:

   protected virtual MvxAndroidBindingBuilder CreateBindingBuilder()

with your own implementation in your own setup.cs file.

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Dec 20, 2012

Contributor

Current binding capability is:

https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Binding/Interfaces/MvxSerializableBindingDescription.cs

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.

Contributor

slodge commented Dec 20, 2012

Current binding capability is:

https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Binding/Interfaces/MvxSerializableBindingDescription.cs

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.

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Dec 20, 2012

Contributor

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:

   Name=[optional: Mode] Path [optional: Converter] [optional: ConverterParameter]

with some known delimiter - e.g. something like ;

That might then produce inputs strings like:

 test:MvxBind="ItemsSource=Customers"

or

 test:MvxBind="ItemsSource=SubObject.Customers MyConverter"

or

 test:MvxBind="ItemsSource=SubObject.Customers MyConverter;ItemClick=ItemSelectedCommand"
Contributor

slodge commented Dec 20, 2012

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:

   Name=[optional: Mode] Path [optional: Converter] [optional: ConverterParameter]

with some known delimiter - e.g. something like ;

That might then produce inputs strings like:

 test:MvxBind="ItemsSource=Customers"

or

 test:MvxBind="ItemsSource=SubObject.Customers MyConverter"

or

 test:MvxBind="ItemsSource=SubObject.Customers MyConverter;ItemClick=ItemSelectedCommand"
@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Dec 21, 2012

Contributor

Linking to #63 too

Contributor

slodge commented Dec 21, 2012

Linking to #63 too

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Dec 22, 2012

Contributor

If you want a simple place to start experimenting then try using this file:

https://gist.github.com/4358552

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:

 one way:

     Target <= Source

 two way

     Target <=> Source

 two way with a converter

     Target <=> Converter(Source, Parameter)

 two way with a fallback value:

     Target <=> Source | Fallback

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:

  1. Source can sometimes be the whole object - so {'Path':''} in the current syntax means bind to the object not to the any property
  2. Property chaining is important - e.g. source paths of Source.SubSource.Property
  3. All special characters need escaping - this is one of the things JSON gave us for free :)

Enjoy - good luck!

Contributor

slodge commented Dec 22, 2012

If you want a simple place to start experimenting then try using this file:

https://gist.github.com/4358552

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:

 one way:

     Target <= Source

 two way

     Target <=> Source

 two way with a converter

     Target <=> Converter(Source, Parameter)

 two way with a fallback value:

     Target <=> Source | Fallback

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:

  1. Source can sometimes be the whole object - so {'Path':''} in the current syntax means bind to the object not to the any property
  2. Property chaining is important - e.g. source paths of Source.SubSource.Property
  3. All special characters need escaping - this is one of the things JSON gave us for free :)

Enjoy - good luck!

@sschoeb

This comment has been minimized.

Show comment
Hide comment
@sschoeb

sschoeb Dec 22, 2012

Contributor

Ok, current idea looks like this: (some samples)
Property=Path
Property=Path OneWay
Property=Path Mode=OneWay
Property=Path Mode=OneWay Converter=MyOwnConverter
Property=Path Mode=OneWay Converter=MyOwnConverter
ConverterParameter=MyOwnConverterParameter
Property=Path OneWay MyOwnConverter
ConverterParameter=MyOwnConverterParameter
Property<=Path
Property=>Path

First we do always have an assignment saying to which TargetProperty we
want do bind which Path.
Then you can add different additional properties using the syntax
"property=value". This means you can add Converter, Mode,
ConverterParameter, etc. using this way.

For properties we do already know the possible values you can remove the
first part. This means you can Write just "OneWay" or the Converter-Name
which would also be recognized correctly as long as they are unique (naming
a converter "OneWay" would crash the parser XD)

Currently it is in a proof of concept state. As I'm not sure what kind of
binding we want to support in the binding itself.
It would be cool to have the possibility to specify a ConverterParameter as
a binding itself.
Probably I've to think a bit more about all of this :S

Actually the way defining the ConverterParameter in brackets looks very
good to me, depending on the ConverterParameter-Question we should go a way
like this...

2012/12/22 Stuart Lodge notifications@github.com

If you want a simple place to start experimenting then try using this file:

https://gist.github.com/4358552

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:

one way:

 Target <= Source

two way

 Target <=> Source

two way with a converter

 Target <=> Converter(Source, Parameter)

two way with a fallback value:

 Target <=> Source | Fallback

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:

  1. Source can sometimes be the whole object - so {'Path':''} in the
    current syntax means bind to the object not to the any property
  2. Property chaining is important - e.g. source paths of
    Source.SubSource.Property
  3. All special characters need escaping - this is one of the things
    JSON gave us for free :)

Enjoy - good luck!


Reply to this email directly or view it on GitHubhttps://github.com/MvvmCross/MvvmCross/issues/87#issuecomment-11636471.

Contributor

sschoeb commented Dec 22, 2012

Ok, current idea looks like this: (some samples)
Property=Path
Property=Path OneWay
Property=Path Mode=OneWay
Property=Path Mode=OneWay Converter=MyOwnConverter
Property=Path Mode=OneWay Converter=MyOwnConverter
ConverterParameter=MyOwnConverterParameter
Property=Path OneWay MyOwnConverter
ConverterParameter=MyOwnConverterParameter
Property<=Path
Property=>Path

First we do always have an assignment saying to which TargetProperty we
want do bind which Path.
Then you can add different additional properties using the syntax
"property=value". This means you can add Converter, Mode,
ConverterParameter, etc. using this way.

For properties we do already know the possible values you can remove the
first part. This means you can Write just "OneWay" or the Converter-Name
which would also be recognized correctly as long as they are unique (naming
a converter "OneWay" would crash the parser XD)

Currently it is in a proof of concept state. As I'm not sure what kind of
binding we want to support in the binding itself.
It would be cool to have the possibility to specify a ConverterParameter as
a binding itself.
Probably I've to think a bit more about all of this :S

Actually the way defining the ConverterParameter in brackets looks very
good to me, depending on the ConverterParameter-Question we should go a way
like this...

2012/12/22 Stuart Lodge notifications@github.com

If you want a simple place to start experimenting then try using this file:

https://gist.github.com/4358552

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:

one way:

 Target <= Source

two way

 Target <=> Source

two way with a converter

 Target <=> Converter(Source, Parameter)

two way with a fallback value:

 Target <=> Source | Fallback

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:

  1. Source can sometimes be the whole object - so {'Path':''} in the
    current syntax means bind to the object not to the any property
  2. Property chaining is important - e.g. source paths of
    Source.SubSource.Property
  3. All special characters need escaping - this is one of the things
    JSON gave us for free :)

Enjoy - good luck!


Reply to this email directly or view it on GitHubhttps://github.com/MvvmCross/MvvmCross/issues/87#issuecomment-11636471.

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Dec 31, 2012

Contributor

From github bounced email:

//-------------

All looks good to me :)

I especially like the look of things like:

Property<=Path

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 :)

Tchuss!

Stuart

Contributor

slodge commented Dec 31, 2012

From github bounced email:

//-------------

All looks good to me :)

I especially like the look of things like:

Property<=Path

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 :)

Tchuss!

Stuart

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Dec 31, 2012

Contributor

After consideration, my preference is for:

Default binding

     Property=Path

e.g. for binding property Text to source Name we would use:

     Text=Name

The = here means use the default binding mode - so this would be one way for text labels and two way for text boxes.

If you want to specify the binding mode, then use

  • <= one way
  • => one way to source
  • <=> two way
  • <1= one time (rarely used)

If you want to bind to the whole source object then use * - e.g.

     Text=*

If you want to bind to subObjects, then use normal dot notation:

     Text=Customer.Address.City

Still TODO:

  • using Converters?
  • using ConverterParameters?
  • providing default values?
  • escaping characters?
  • quoting strings?
  • accepted datatypes?

And... advanced:

No idea when we'll ever code any of this... but I love the idea :)

Stuart

Contributor

slodge commented Dec 31, 2012

After consideration, my preference is for:

Default binding

     Property=Path

e.g. for binding property Text to source Name we would use:

     Text=Name

The = here means use the default binding mode - so this would be one way for text labels and two way for text boxes.

If you want to specify the binding mode, then use

  • <= one way
  • => one way to source
  • <=> two way
  • <1= one time (rarely used)

If you want to bind to the whole source object then use * - e.g.

     Text=*

If you want to bind to subObjects, then use normal dot notation:

     Text=Customer.Address.City

Still TODO:

  • using Converters?
  • using ConverterParameters?
  • providing default values?
  • escaping characters?
  • quoting strings?
  • accepted datatypes?

And... advanced:

No idea when we'll ever code any of this... but I love the idea :)

Stuart

@sschoeb

This comment has been minimized.

Show comment
Hide comment
@sschoeb

sschoeb Jan 7, 2013

Contributor

What do you mean by using Converters/ConverterParameter?
-> Just specify the syntax like ConverterXY(source, param)

It would be cool to specify the ConverterParameter as a binding by itself.
This would mean that the following:

ConverterXY(PropertyX, PropertyY)

would bind to PropertyX, using the Converter "ConverterXY" and the Value in PropertyY as a the parameter.
This means that we now have another dependency in the binding. As soon a PropertyChanged occures in the PropertyY we have to re-evaluate the binding.

Another question is how we can pass static values. We could use a syntax like:
ConverterXY(PropertyX, {StaticValue})

What do you mean by accepted datatypes?

I do not really like the *-solution for the whole object.
I would more prefere a solution like:
Target=this

Another question is how to access specifiy items of a collection, may something like this:
Target=Property[0]

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.
This could change when we also have the possibility to other UI-Elements specified in the XML.

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.
Actually I've never ever needed one of those. How important are this values?
I currently think a solution like this would do it:
Target=Property FallbackValue=StaticValue
Is this FallbackValue the same as FallbackValue or TargetValueNUll?
Should this be a static value? (I think yes)

Contributor

sschoeb commented Jan 7, 2013

What do you mean by using Converters/ConverterParameter?
-> Just specify the syntax like ConverterXY(source, param)

It would be cool to specify the ConverterParameter as a binding by itself.
This would mean that the following:

ConverterXY(PropertyX, PropertyY)

would bind to PropertyX, using the Converter "ConverterXY" and the Value in PropertyY as a the parameter.
This means that we now have another dependency in the binding. As soon a PropertyChanged occures in the PropertyY we have to re-evaluate the binding.

Another question is how we can pass static values. We could use a syntax like:
ConverterXY(PropertyX, {StaticValue})

What do you mean by accepted datatypes?

I do not really like the *-solution for the whole object.
I would more prefere a solution like:
Target=this

Another question is how to access specifiy items of a collection, may something like this:
Target=Property[0]

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.
This could change when we also have the possibility to other UI-Elements specified in the XML.

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.
Actually I've never ever needed one of those. How important are this values?
I currently think a solution like this would do it:
Target=Property FallbackValue=StaticValue
Is this FallbackValue the same as FallbackValue or TargetValueNUll?
Should this be a static value? (I think yes)

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Jan 12, 2013

Contributor

Ooops - sorry - doing a thousand things so never answered...

It would be cool to specify the ConverterParameter as a binding by itself.

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.

Another question is how we can pass static values. We could use a syntax like:
ConverterXY(PropertyX, {StaticValue})

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

What do you mean by accepted datatypes?

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 do not really like the *-solution for the whole object.
I would more prefere a solution like:
Target=this

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.

Another question is how to access specifiy items of a collection, may something like this: Target=Property[0]

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?

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.
This could change when we also have the possibility to other UI-Elements specified in the XML.

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)

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.
Actually I've never ever needed one of those. How important are this values?
I currently think a solution like this would do it:
Target=Property FallbackValue=StaticValue
Is this FallbackValue the same as FallbackValue or TargetValueNUll?
Should this be a static value? (I think yes)

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 :)

Stuart

Contributor

slodge commented Jan 12, 2013

Ooops - sorry - doing a thousand things so never answered...

It would be cool to specify the ConverterParameter as a binding by itself.

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.

Another question is how we can pass static values. We could use a syntax like:
ConverterXY(PropertyX, {StaticValue})

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

What do you mean by accepted datatypes?

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 do not really like the *-solution for the whole object.
I would more prefere a solution like:
Target=this

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.

Another question is how to access specifiy items of a collection, may something like this: Target=Property[0]

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?

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.
This could change when we also have the possibility to other UI-Elements specified in the XML.

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)

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.
Actually I've never ever needed one of those. How important are this values?
I currently think a solution like this would do it:
Target=Property FallbackValue=StaticValue
Is this FallbackValue the same as FallbackValue or TargetValueNUll?
Should this be a static value? (I think yes)

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 :)

Stuart

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Jan 19, 2013

Contributor

Hi again :)

Are there any code prototypes yet? If not, then I may code one up... It's been a month (and even longer since #62) and I kind of want to use this in my code :)

Stuart

Contributor

slodge commented Jan 19, 2013

Hi again :)

Are there any code prototypes yet? If not, then I may code one up... It's been a month (and even longer since #62) and I kind of want to use this in my code :)

Stuart

@sschoeb

This comment has been minimized.

Show comment
Hide comment
@sschoeb

sschoeb Jan 19, 2013

Contributor

got a prototype, will send it today evening... currently im skiing :)
Am 19.01.2013 09:40 schrieb "Stuart Lodge" notifications@github.com:

Hi again :)

Are there any code prototypes yet? If not, then I may code one up... It's
been a month (and even longer since #62#62)
and I kind of want to use this in my code :)

Stuart


Reply to this email directly or view it on GitHubhttps://github.com/MvvmCross/MvvmCross/issues/87#issuecomment-12452197.

Contributor

sschoeb commented Jan 19, 2013

got a prototype, will send it today evening... currently im skiing :)
Am 19.01.2013 09:40 schrieb "Stuart Lodge" notifications@github.com:

Hi again :)

Are there any code prototypes yet? If not, then I may code one up... It's
been a month (and even longer since #62#62)
and I kind of want to use this in my code :)

Stuart


Reply to this email directly or view it on GitHubhttps://github.com/MvvmCross/MvvmCross/issues/87#issuecomment-12452197.

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Jan 19, 2013

Contributor

Skiing? Now I'm jealous :)

If it helps, I've built a tokeniser/parser (build night before yesterday for #110)

Contributor

slodge commented Jan 19, 2013

Skiing? Now I'm jealous :)

If it helps, I've built a tokeniser/parser (build night before yesterday for #110)

@sschoeb

This comment has been minimized.

Show comment
Hide comment
@sschoeb

sschoeb Jan 21, 2013

Contributor

Awesome stuff Stuart!

Just had a quick look to it and it looks quite fine to me!

But why did you introduce this "sections"?
Do we really need them?

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?

Contributor

sschoeb commented Jan 21, 2013

Awesome stuff Stuart!

Just had a quick look to it and it looks quite fine to me!

But why did you introduce this "sections"?
Do we really need them?

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?

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Jan 21, 2013

Contributor

Thanks

Just had a quick look to it and it looks quite fine to me!

But why did you introduce this "sections"?
Do we really need them?

local:MvxBind="Text Section.Title Converter=TheConverter,
ConverterParamater=true, FallbackValue='Fred'; Click GoToCommand"

Current reason for the sections is to separate the 'options' from the next
item.

Currently you can use ; and , wherever you want to... so this is supported:

    Text Section.Title (Converter=TheConverter; ConverterParameter="Life"),
Click GoToCommand

Not sure I like it either... but it is nice not to have to remember where
you use ; vs ,

It does also provide some break-up of the line maybe making it more
readable? Maybe... (maybe not?)

Text Section.Title Converter=TheConverter; Click GoToCommand
Converter=Thing; Fill Level Converter=L2C
Text Section.Title (Converter=TheConverter); Click GoToCommand
(Converter=Thing);
Fill Level (Converter=L2C)

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').

  1. I ran out of time - and it was easier to code when the ordering was
    always Target Source (Options) :)
  2. I don't really know if the syntax reflects the two-way native of
    Converters?

Maybe a different syntax is needed to reflect the two-way binding?
Something like

TheConverter(Text Section.Title, "ConverterParameter");

This is still all open for discussion... plus there's no reason we have to
have only one binding syntax. It's all done using IoC....

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

Yeah - I know.... but if you are declaring war on unneeded syntax, then
removing the '=' felt obvious too.

Note that there is also the ability to specify Mode the old way too

How can I bind to the full object?

By leaving it blank (same as Windows), or by using a .

So either of:

   Text (Converter=TheConverter); Click GoToCommand
   Text . (Converter=TheConverter); Click GoToCommand

Is your Property-Parser included?

Yeah - it's there in the Binding project.

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
syntax.... There is going to be a lot of personal opinion in this!

Also need to do some speed measurements at some point....

Day job now though!

Contributor

slodge commented Jan 21, 2013

Thanks

Just had a quick look to it and it looks quite fine to me!

But why did you introduce this "sections"?
Do we really need them?

local:MvxBind="Text Section.Title Converter=TheConverter,
ConverterParamater=true, FallbackValue='Fred'; Click GoToCommand"

Current reason for the sections is to separate the 'options' from the next
item.

Currently you can use ; and , wherever you want to... so this is supported:

    Text Section.Title (Converter=TheConverter; ConverterParameter="Life"),
Click GoToCommand

Not sure I like it either... but it is nice not to have to remember where
you use ; vs ,

It does also provide some break-up of the line maybe making it more
readable? Maybe... (maybe not?)

Text Section.Title Converter=TheConverter; Click GoToCommand
Converter=Thing; Fill Level Converter=L2C
Text Section.Title (Converter=TheConverter); Click GoToCommand
(Converter=Thing);
Fill Level (Converter=L2C)

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').

  1. I ran out of time - and it was easier to code when the ordering was
    always Target Source (Options) :)
  2. I don't really know if the syntax reflects the two-way native of
    Converters?

Maybe a different syntax is needed to reflect the two-way binding?
Something like

TheConverter(Text Section.Title, "ConverterParameter");

This is still all open for discussion... plus there's no reason we have to
have only one binding syntax. It's all done using IoC....

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

Yeah - I know.... but if you are declaring war on unneeded syntax, then
removing the '=' felt obvious too.

Note that there is also the ability to specify Mode the old way too

How can I bind to the full object?

By leaving it blank (same as Windows), or by using a .

So either of:

   Text (Converter=TheConverter); Click GoToCommand
   Text . (Converter=TheConverter); Click GoToCommand

Is your Property-Parser included?

Yeah - it's there in the Binding project.

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
syntax.... There is going to be a lot of personal opinion in this!

Also need to do some speed measurements at some point....

Day job now though!

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Jan 21, 2013

Contributor

Have switched in the prototype Swiss binding for Twittersearch

See 5a3cfab for Droid
and 30d66b6 for Touch

This isn't final official syntax.... just experimenting...

Contributor

slodge commented Jan 21, 2013

Have switched in the prototype Swiss binding for Twittersearch

See 5a3cfab for Droid
and 30d66b6 for Touch

This isn't final official syntax.... just experimenting...

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Jan 22, 2013

Contributor

I'm wondering what else we can use instead of < and >

These things look good, but they're rubbish inside Android axml as you have to escape them :/

Contributor

slodge commented Jan 22, 2013

I'm wondering what else we can use instead of < and >

These things look good, but they're rubbish inside Android axml as you have to escape them :/

@sschoeb

This comment has been minimized.

Show comment
Hide comment
@sschoeb

sschoeb Jan 23, 2013

Contributor
Property{Value
Property}Value
Property=Value
Property Value

like it as easy as possible :-)

Contributor

sschoeb commented Jan 23, 2013

Property{Value
Property}Value
Property=Value
Property Value

like it as easy as possible :-)

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Jan 23, 2013

Contributor

I don't like using ( or ) as they are already used...

Maybe { and }

Or maybe we just drop down to using Mode=XXX for when the user specifies the mode (this is rare anyway?)

Stuart

Contributor

slodge commented Jan 23, 2013

I don't like using ( or ) as they are already used...

Maybe { and }

Or maybe we just drop down to using Mode=XXX for when the user specifies the mode (this is rare anyway?)

Stuart

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Jan 24, 2013

Contributor

Currently leaning towards:

*Target* *BindingMode* *SourcePath*, Convert(*ConverterName*, *ConverterParameter*), Fallback(*FallbackValue*)

So examples might be:

Text Customer.Name
Text TwoWay Customer.Name
Stars OneTime App.Rating, Convert(RatingToStars, 5), Fallback(0)

Also wondering if this wouldn't be better as:

*Target* *SourcePath*, Mode(*BindingMode*), *Convert(*ConverterName*, *ConverterParameter*), Fallback(*FallbackValue*)

e.g.

Target App.Rating, Mode(OneTime), Convert(RatingToStars, 5), Fallback(0)

Also wondering if we should go for Path in the bracketed list too:

*Target* Path(*SourcePath*), Mode(*BindingMode*), *Convert(*ConverterName*, *ConverterParameter*), Fallback(*FallbackValue*)

e.g.

Target Path(App.Rating), Mode(OneTime), Convert(RatingToStars, 5), Fallback(0)
Contributor

slodge commented Jan 24, 2013

Currently leaning towards:

*Target* *BindingMode* *SourcePath*, Convert(*ConverterName*, *ConverterParameter*), Fallback(*FallbackValue*)

So examples might be:

Text Customer.Name
Text TwoWay Customer.Name
Stars OneTime App.Rating, Convert(RatingToStars, 5), Fallback(0)

Also wondering if this wouldn't be better as:

*Target* *SourcePath*, Mode(*BindingMode*), *Convert(*ConverterName*, *ConverterParameter*), Fallback(*FallbackValue*)

e.g.

Target App.Rating, Mode(OneTime), Convert(RatingToStars, 5), Fallback(0)

Also wondering if we should go for Path in the bracketed list too:

*Target* Path(*SourcePath*), Mode(*BindingMode*), *Convert(*ConverterName*, *ConverterParameter*), Fallback(*FallbackValue*)

e.g.

Target Path(App.Rating), Mode(OneTime), Convert(RatingToStars, 5), Fallback(0)
@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Jan 24, 2013

Contributor

I give up... we'll just use syntax like Xaml....

Mode disappears... we're just going for:

    TargetName SourcePath, Mode=TwoWay, ConverterParameter='One', FallbackValue=1.23

with options like:

   TargetName ConverterParameter='One', FallbackValue=1.23

and:

  TargetName Path=SourcePath, ConverterParameter='One', FallbackValue=1.23
Contributor

slodge commented Jan 24, 2013

I give up... we'll just use syntax like Xaml....

Mode disappears... we're just going for:

    TargetName SourcePath, Mode=TwoWay, ConverterParameter='One', FallbackValue=1.23

with options like:

   TargetName ConverterParameter='One', FallbackValue=1.23

and:

  TargetName Path=SourcePath, ConverterParameter='One', FallbackValue=1.23
@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Jan 31, 2013

Contributor

Closing... although some documentation and blog posts are needed... I'll do them eventually - or maybe others will :)

Contributor

slodge commented Jan 31, 2013

Closing... although some documentation and blog posts are needed... I'll do them eventually - or maybe others will :)

@slodge slodge closed this Jan 31, 2013

martijn00 added a commit to martijn00/MvvmCross that referenced this issue Dec 8, 2016

Merge pull request #87 from Giorgi/master
Return tasks from network plugin methods instead of accepting callbacks

kjeremy pushed a commit to kjeremy/MvvmCross that referenced this issue Dec 11, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment