Wifimanager: parameter implementation design

Created on 10 Sep 2017  路  7Comments  路  Source: tzapu/WiFiManager

Am I the only one that doesn't really like the way parameters are implemented ?
I am not sure how I feel about the design pattern used, maye there was a reason, it just seems odd to me, not sure what it is, it just seems cumbersome.

Question

Most helpful comment

seems ok to me
breaking backwards compatibility on this should not be such a big thing, we could release it as 2.0
my line of thinking is that whoever got to the more advanced usage types, with params, would understand what needs fixing...

All 7 comments

hi, i don t like it much either, but i think it was originally a pull request, and above my C skill anyway so I went with it.

open to any other option

Ill think about it, obviously we want to keep backward now that it is there, maybe we can add procedural wrappers to make it easier to use, so you do not have to keep track of objects and refs in user code.

Just add parameter(ID, object)
getparameter(ID,key), or value only etc.

seems ok to me
breaking backwards compatibility on this should not be such a big thing, we could release it as 2.0
my line of thinking is that whoever got to the more advanced usage types, with params, would understand what needs fixing...

Just to add to the discussion, in one of my projects I needed to add more than 25 parameters and created a wrapper class to deal with much of the pain with registering them and what actions to take when they were changed via the form:

    ConfigParam tp_duration(wifi, "tp_duration", "Tick Pulse", config.tp_duration, 8, [](const char* result)
    {
        config.tp_duration = TimeUtils::parseSmallDuration(result);
        clk.writeTPDuration(config.tp_duration);
    });

Would it make more sense to register callbacks for param saves? Or a single callback that recieves an id and object?

I would prefer callbacks, one of my goals with the simple wrapper I created was to keep both the definition and action of the params close together. I would it was painful and error prone when the definition and registration of the params was separated from the actions. This made the code more readable and maintainable. If I needed to add/remove one or more params it was all in one place.

Oh, and lets absolutely manage the list of params without the user being required to specify the max-size.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

liebman picture liebman  路  5Comments

reynolga picture reynolga  路  9Comments

gjt211 picture gjt211  路  7Comments

santhoshnp picture santhoshnp  路  6Comments

Andreafoxalarm picture Andreafoxalarm  路  12Comments