JSON based serialisation

[ghost]

This is a nice package.

I want to make the authorisation data driven. So then I can just load it up at runtime.

Then I can use that to drive the drawer menus, router endpoints etc.

What do you think ?. Is it something that is useful to you ?

[fkleon]

Thanks for your interest!

I'm not sure that serialisation support should actually be included in this library, but I'd certainly be interested in other opinions.

There are a few issues to be addressed when thinking about adding general purpose serialisation support:

• The Ability class is abstract, and makes no assumptions about members of implementing classes - they could contain values that are just not serialisable. If that freedom of design is not to be dropped, adding the serialisation logic in the Ability class would only be possible with heavy use of reflections, which is only feasible in Dart 2 by forcing subclasses to implement Reflectable.
• In the current design abilities are inherently a combination of data (e.g. the user they apply to) and functions (the actual conditions). The only values that can't be serialised easily within the library are Conditions, as they are just boolean-valued functions with one argument ("predicates"). Luckily these are transient members anyway and don't need to be serialised as they are supposed to be defined directly in the constructor of the implementing Ability object, and the deserialisation code would have access to the class definitions. In practice additionally some data in form of arguments is required to relate conditions to, such as the user in the example project. Also it is possible for implementing classes to add rules dynamically through other methods - again there is no assumption how an ability class might be implemented. The serialisation code needs to cater for that.

Those particular issues could be eliminated by imposing some restrictions on implementations of the Ability class. I personally think it's nice to have a library that makes minimal assumptions about how it is to be used though. Given that it might be easier to delegate the implementation of serialisation to the users of this library. By designing their Ability classes with serialisation in mind it is fairly easy to add serialisation on top with a minimal overhead, e.g. by using the json_serializable package to generate the serialisation code at build time.

There might be other points I haven't though about, but please let me know what you think.

[ghost]

Thanks for a thorough response.

The technical concerns make sense to me. Reflections definitely itly a no go.

It might make sense that I fork because of my use case.

I am building a system where the user only define html which gets rendered as flutter widgets. Links within the html get turned I to routing requests using the fluoro dart router. Menu is data driven too. So I needed a way of applying security to the routes in a data driven way.

On Sun, 19 Aug 2018, 08:36 Frederik Leonhardt, notifications@github.com wrote:

Thanks for your interest!

I'm not sure that serialisation support should actually be included in this library, but I'd certainly be interested in other opinions.

There are a few issues to be addressed when thinking about adding general purpose serialisation support:

• The Ability class is abstract, and makes no assumptions about members of implementing classes - they could contain values that are just not serialisable. If that freedom of design is not to be dropped, adding the serialisation logic in the Ability class would only be possible with heavy use of reflections, which is only feasible in Dart 2 by forcing subclasses to implement Reflectable.
• In the current design abilities are inherently a combination of data (e.g. the user they apply to) and functions (the actual conditions). The only values that can't be serialised easily within the library are Conditions, as they are just boolean-valued functions with one argument ("predicates"). Luckily these are transient members anyway and don't need to be serialised as they are supposed to be defined directly in the constructor of the implementing Ability object, and the deserialisation code would have access to the class definitions. In practice additionally some data in form of arguments is required to relate conditions to, such as the user in the example project. Also it is possible for implementing classes to add rules dynamically through other methods - again there is no assumption how an ability class might be implemented. The serialisation code needs to cater for that.

Those particular issues could be eliminated by imposing some restrictions on implementations of the Ability class. I personally think it's nice to have a library that makes minimal assumptions about how it is to be used though. Given that it might be easier to delegate the implementation of serialisation to the users of this library. By designing their Ability classes with serialisation in mind it is fairly easy to add serialisation on top with a minimal overhead, e.g. by using the json_serializable package to generate the serialisation code at build time.

There might be other points I haven't though about, but please let me know what you think.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fkleon/tintin/issues/2#issuecomment-414107202, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwsCjqghM4mfAn2Djy76XJBmTMbYnks5uSQdugaJpZM4WCiRU .