Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Create a better preferences/settings system #161

kylef opened this Issue · 5 comments

3 participants

Kyle Fuller Alexey Sokolov apmorton
Kyle Fuller

Once implemented, issue #158 along with full set/get for network preferences would be included in this implementation.

There should be some kind of list on CZNC, CUser, CIRCNetwork and CChan which include the values which can be set. *admin and *webadmin can be automatically generated from these values. These variable should be enclosed in some class such as CValue.

CValue will contain various virtual methods for checking if a string matches its type, descriptions, titles and any type of field to show in a webadmin. There can be various subclasses for specific types like strings, integers, etc.

Help will also be generated from these values.

Once this is implemented, there should be very little specific code to each "value". When adding new preferences, we should not need to add any code into *admin or *webadmin. There shouldn't be code added to the config read/write system either.

Extra points for allowing modules to use this system to close #125.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Alexey Sokolov

When adding new preferences, we should not need to add any code into *admin or *webadmin

Impossible. There can be specific settings, which would need additional stuff. For example, simple text setting "Timezone". But it also has a drop down list of available time zones...

Kyle Fuller

Not impossible, take a look at Django for example. There is a django admin application which can generate a complete admin interface from the ORM. We just need to provide a mechanism to have "choices" attached to the type of values.

Alexey Sokolov

In case of Timezone we need to provide "choices" mechanism, yeah. But what else mechanisms do we need to provide?
You can't really enumerate every such mechanism now, that you will satisfied with forever, without any modifications.


DarthGandalf, I believe you are over thinking this. the django admin is a great example. each field is a subclass of the generalized 'field' type. and each field subclass handles its own validation. so in your example, you would have a 'timezone' field subclass, which renders itself and validates its own input against whatever methods it needs. All the rest of the application needs to know is that it should call Value.validate() before saving anything. Each field type is also responsible for its own html elements (in django this is further abstracted into widgets, but that would be overkill in this case). So when rendering a webadmin form each field has a method called to return html for its own field.

Alexey Sokolov

Hm, ok. Good then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.