starred/WiFiManager

Fork 0

mirror of https://github.com/tzapu/WiFiManager.git synced 2026-04-28 09:35:49 +03:00

[GH-ISSUE #419] parameter implementation design #351

New issue

Open

opened 2026-02-28 01:24:53 +03:00 by kerem · 7 comments

kerem commented

2026-02-28 01:24:53 +03:00

Owner

Originally created by @tablatronix on GitHub (Sep 10, 2017).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/419

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.

Originally created by @tablatronix on GitHub (Sep 10, 2017). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/419 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.

kerem added the

Question

label

2026-02-28 01:24:53 +03:00

kerem commented

2026-02-28 01:24:54 +03:00

Author

Owner

@tzapu commented on GitHub (Sep 10, 2017):

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

@tzapu commented on GitHub (Sep 10, 2017): 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

kerem commented

2026-02-28 01:24:54 +03:00

Author

Owner

@tablatronix commented on GitHub (Sep 10, 2017):

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.

@tablatronix commented on GitHub (Sep 10, 2017): 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.

kerem commented

2026-02-28 01:24:54 +03:00

Author

Owner

@tzapu commented on GitHub (Sep 11, 2017):

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

@tzapu commented on GitHub (Sep 11, 2017): 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...

kerem commented

2026-02-28 01:24:54 +03:00

Author

Owner

@liebman commented on GitHub (Sep 12, 2017):

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);
    });

@liebman commented on GitHub (Sep 12, 2017): 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); }); ```

kerem commented

2026-02-28 01:24:54 +03:00

Author

Owner

@tablatronix commented on GitHub (Sep 12, 2017):

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

@tablatronix commented on GitHub (Sep 12, 2017): Would it make more sense to register callbacks for param saves? Or a single callback that recieves an id and object?

kerem commented

2026-02-28 01:24:54 +03:00

Author

Owner

@liebman commented on GitHub (Sep 12, 2017):

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.

@liebman commented on GitHub (Sep 12, 2017): 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.

kerem commented

2026-02-28 01:24:54 +03:00

Author

Owner

@liebman commented on GitHub (Sep 12, 2017):

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

@liebman commented on GitHub (Sep 12, 2017): Oh, and lets absolutely manage the list of params without the user being required to specify the max-size.