> From: Sascha Manns <sascha.ma...@mailbox.org> > Sent: Wednesday, 3 May 2017, 16:00 > Subject: Re: [Vala] Use defined pathes inside a method
> > interface and not the whole configuration object. > I prepared that config.vala [1]. > can't used because of it itn't instancable. But how can i work with such > pathes instead? > Also i added a metod which imports the settings from the gsettings > schema and connects this to its properties from the interface. Is the > implementation usable in that case? It would be great, that the > gsettings and the defined pathes are useable inside each other class. An interface is an abstraction, so you need a configuration object that implements the interface. Having one big interface that matches your configuration object just duplicates your effort. The suggestion was to break the interfaces into smaller parts so the configuration object implements multiple interfaces. For a little more detail see: https://martinfowler.com/bliki/HeaderInterface.html https://martinfowler.com/bliki/RoleInterface.html So you could have a FilePathsForSaving and a AuthorContactDetails interface that are both implemented by your configuration object. When you come to use them you only need a subset of the configuration object. So you could have a method: void save_my_work (Work work_object, FilePathsForSaving my_big_configuration_object) {...} The advantage is that each method only needs a subset of the data and it means you can feed alternative objects in, so long as they implement the same interface. That could be useful for testing individual components of your application. So if you want to write a test of the save_my_work() command then you can feed in paths in a temporary directory and check the relevant data is saved without having to construct a whole configuration object, just the FilePathsForSaving. An alternative would be to have smaller objects as fields of the configuration object. So instead of PublisherSettings having: public string firstname { get; set; } public string surname { get; set; } ... you could have: public AuthorContactDetails author_contact_details; and then the AuthorContactDetails object has properties for the name, etc. Your GSettings method should probably take the configuration object as an argument, e.g. : void modify_configuration_from_gsettings (ref PublisherSettings my_big_configuration_object) {...} this also gives you the flexibility to set the configuration from other user interfaces: void modify_configuration_from_command_line (ref PublisherSettings my_big_configuration_object, ref unowned string[] args) {...} If you need more ideas take a look at other projects, this is how Geary handles it: https://git.gnome.org/browse/geary/tree/src/client/application/geary-config.vala BTW, I don't think you want a new MainLoop in your GetGSettings function: https://github.com/saigkill/gnome-publisher/blob/master/src/config.vala#L82 All the best, Al _______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
