Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Create a better preferences/settings system #161

kylef opened this Issue Apr 4, 2012 · 5 comments


None yet
3 participants

kylef commented Apr 4, 2012

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.


DarthGandalf commented Apr 5, 2012

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...


kylef commented Apr 16, 2012

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.



DarthGandalf commented Apr 16, 2012

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.


apmorton commented Jun 14, 2012

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.


DarthGandalf commented Jun 14, 2012

Hm, ok. Good then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment