Smalltalk › Instantiations

Settings Framework design

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

jtuchel

Settings Framework design

Hi,

on the fogbugz site with Instantations' Design Documents that has been linked to before, there also is a Design Document for a new Settings Framework. I'd like to start a little discussion about a few thoughts I had while reading it. But let me start by saying that I am happy to see Instantiations is working on this, because it will help clean up the VAST IDE as well as provide users with a tool to manage and edit settings for add-ins to VAST or end user products.

I especially have some ideas about the idea of storing all settings in the abt.ini file and using an ini file in general

The file would be very long, and not everything that can be configured should be stored in this file. This is probably more a question of taste than a real technical argument. Also an exchange of some settings between machines or users would be harder. We'd need some export/import tools rather than just copying files.
The ini-file only allows simple key-value pairs and one level of nesting/organizing settings in stanzas. So at least in a second step I'd opt for a pluggable mechanism in which I can use an XML or JSON or completely self made settings serializer - this could also make exporting and spreading settings easier
Stanzas named after the Application they are valid for: Well, a feature can consist of multiple Applications and there may be reasons to keep the settings of these separate. I guess having the chance to group settings in deeper hierarchies that would help here. Application Names change over time, but maybe the name of a group of configuration parameters will still have the same purpose and name.
If I could chose from the screenshots for a settings editor, I'd vote for the eclipse editor. The tree also would allow for nested groups of settings, while a simple two-list editor is very limiting.
Settings should be typed. What I mean by that is that you should be able to define what kind of object you expect as a setting, so that a settings editor can provide appropriate widgets for editing. Like A Checkbox for Booleans, Listboxes for the selection of one or multiple entries from a range, A number rangem for a SpinBox, or a simple Text Input Field. Maybe that could even be extended to a means of providing custom settings editors. Typing a setting can also help validate settings and probably also migrate them for newer versions of a framework or an application

Just some raw, unfinished thoughts on this settings framework topic.

What do others think?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Marten Feldtmann-2

Aw: Settings Framework design

I hope, that the framework will not only support ONE ini file - but each application might set up different sources (a la connectors) to different resources offering ini values. Therefore I would like to see connections to databases, ini-text files, JSON oriented resources - and then application itselfs setup its ini-file connections ...

John O'Keefe-3

Re: Settings Framework design

In reply to this post by jtuchel

Joachim -

Well, at this point the design is still unfinished also :-)

To address your points:

Yes, the INI file could get long. However, given a Settings View organized as a tree-view, this doesn't seem like too big a problem to me. And I also recognize that not everything should/could be stored in the INI file -- but I want to put as much as I can there.
Yes, the key-value pairs within stanzas does imply some limitations. I will make the INIi reader/write pluggable, but I do not intend to supply any more advanced plug-ins with the framework (at least not before Phase 3 or 4).
By associating stanza names with app names, we can very easily access and apply settings for the apps. I mentioned that the framework would also support ad-hoc stanza names, but I think their use will not be common (I could be wrong here) and they will require a little more work on the part of the developer.
At the moment I'm not focusing on any particular editor appearance (since this is a Phase 2 item), but I am not planning on a two-list editor.
Settings are typed -- if the API write-up in the design document was finished you would see that. It is actually necessary since the framework parses the value based on this typing when reading the INI file.

John

jtuchel

Aw: Re: Settings Framework design

John,

Am Freitag, 27. Mai 2011 22:40:43 UTC+2 schrieb John O'Keefe:

Joachim -

Well, at this point the design is still unfinished also :-)

ouch. So I put my nose into the wrong document... ;-)

To address your points:

Yes, the INI file could get long. However, given a Settings View organized as a tree-view, this doesn't seem like too big a problem to me. And I also recognize that not everything should/could be stored in the INI file -- but I want to put as much as I can there.

Well, as long as there's a way to export a subset of settings (meaning one tree node and its children) and reimport it into another image, that's probably not an issue.

Yes, the key-value pairs within stanzas does imply some limitations. I will make the INIi reader/write pluggable, but I do not intend to supply any more advanced plug-ins with the framework (at least not before Phase 3 or 4).

I guess a documented framework which allows for plug-ins is a great start. I am well aware of the fact that asking for, say, XML or JSON as a settings file format, also asks for the respective code to be loaded into an image that uses the settings, so such features would be interesting for people who want to use the framework for their deployed apps.

By associating stanza names with app names, we can very easily access and apply settings for the apps. I mentioned that the framework would also support ad-hoc stanza names, but I think their use will not be common (I could be wrong here) and they will require a little more work on the part of the developer.

Again, if documented well, the default vs. extendable theme is great.

At the moment I'm not focusing on any particular editor appearance (since this is a Phase 2 item), but I am not planning on a two-list editor.

I am glad to hear that. Even though a well organized two-list editor with all settings gathered vs. today's multiple settings and preferences dialog would still be an improvement.

Settings are typed -- if the API write-up in the design document was finished you would see that. It is actually necessary since the framework parses the value based on this typing when reading the INI file.

So I was just too early. Sorry for that.

But let me finish by saying that I think it's great to see that you both are working on major improvements to VAST and also the open way of communicating your plans and asking for feedback. I hope you will be getting more feedback over time.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/LUduUVZZMWx1MklK.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

John O'Keefe-3

Re: Aw: Re: Settings Framework design

Joachim -

We are just getting our toes wet with exposing early designs. I guess one thing we should do is be more explicit about the state of any particular design document. We want to get this stuff out as early as possible, but that means that the design may not be fully fleshed out (and we need to say that).

I want to thank you and Marten and the others who are giving us valuable feedback. I know you understand that we are unlikely to be able to provide everything you want, at least in the first release of a feature, but we do try to make the designs flexible enough that they can be extended in the future.

John

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/cnhsVVg5b2ltRjhK.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.