Re: [Vala] Use defined pathes inside a method
- From: Al Thomas <astavale yahoo co uk>
- To: vala-list <vala-list gnome org>
- Subject: Re: [Vala] Use defined pathes inside a method
- Date: Sat, 6 May 2017 15:39:08 +0000 (UTC)
From: Sascha Manns <Sascha Manns 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]